13:00:22 <stickster> #startmeeting Workstation WG
13:00:22 <zodbot> Meeting started Mon Aug 27 13:00:22 2018 UTC.
13:00:22 <zodbot> This meeting is logged and archived in a public location.
13:00:22 <zodbot> The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:22 <zodbot> The meeting name has been set to 'workstation_wg'
13:00:27 <stickster> #meetingname workstation
13:00:27 <zodbot> The meeting name has been set to 'workstation'
13:00:28 <mclasen> .hello mclasen
13:00:29 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
13:00:32 <stickster> #topic Roll call
13:00:36 <rdieter> .hello rdieter
13:00:37 <stickster> .hello pfrields
13:00:38 <zodbot> rdieter: rdieter 'Rex Dieter' <rdieter@gmail.com>
13:00:41 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
13:01:27 * stickster is on a new laptop this morning which just arrived on Friday night, sorry for any delays while I get kinks worked out.
13:01:35 <ryanlerch> .hello ryanlerch
13:01:36 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com>
13:02:20 <stickster> #chair mclasen rdieter ryanlerch mcatanzaro
13:02:20 <zodbot> Current chairs: mcatanzaro mclasen rdieter ryanlerch stickster
13:02:31 <mclasen> ryanlerch: hey, did you see my interview email ?
13:03:25 <stickster> #info Agenda is on Pagure
13:03:28 <stickster> #link https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting
13:03:38 * cschalle hi
13:03:46 <stickster> Hmm, we really should get the oldest stuff out of the way first
13:03:48 <stickster> #chair cschalle
13:03:48 <zodbot> Current chairs: cschalle mcatanzaro mclasen rdieter ryanlerch stickster
13:03:58 <stickster> #link https://pagure.io/fedora-workstation/issues?status=Open&order_key=date_created&order=asc&tags=meeting
13:04:17 <stickster> #chair juhp[m]
13:04:17 <zodbot> Current chairs: cschalle juhp[m] mcatanzaro mclasen rdieter ryanlerch stickster
13:04:19 <ryanlerch> mclasen: sorry r slowness, was on PTO! i will bring up the builder interview at the next magazine meeting!
13:04:27 <ryanlerch> it looks perfect, TBH
13:04:38 <mclasen> cool, thanks
13:04:45 <stickster> Anyone seen otaylor or kalev?
13:05:03 <stickster> We can go ahead in any case, quorum clearly
13:05:18 <stickster> #topic Drop Workstation install tree?
13:05:20 <stickster> #link https://pagure.io/fedora-workstation/issue/45
13:06:17 <mclasen> mcatanzaro sends regrets, he refuses to register on freenode
13:07:15 <stickster> 🤔
13:07:43 <stickster> whatevs
13:07:59 <stickster> So who can give a summary/update on this ticket?
13:08:39 <cschalle> so looking at the ticket, the question that comes to my mind is that I assume we want to allow people to install through things like PXE boot, does this ticket affect that?
13:09:06 <stickster> cschalle: AFAICT, it's possible for people to do that by passing an installclass to Anaconda at the boot line.
13:09:06 <mclasen> yes, thats what the initial comment says
13:09:27 <stickster> I haven't tried -- just going by what the ticket seems to incicate.
13:09:33 <mclasen> oh no, sorry. misread
13:10:27 * stickster assumes people are reading
13:12:17 * mclasen basically has no opinion on this, and would have expected releng to press the issue if it is something that needs to change
13:12:55 <stickster> OK, and from the related releng issue, https://pagure.io/releng/issue/7403 -- it doesn't look like the installclass thing works yet
13:13:20 <ryanlerch> getting data on the popularity of install methods is difficult too, i presume?
13:13:28 <stickster> yes
13:13:47 <stickster> Here's the thing, killing off this task would save time in composes, which we know to be a universal problem
13:14:30 <stickster> I think we need someone to walk through the implications of killing off the tree, socialize it, and then do it
13:14:34 <rdieter> So, I'd greatly prefer that installclass working be considered a prereq
13:14:42 <stickster> rdieter: that seems reasonable to me
13:15:02 <rdieter> having been one who has used netinstall's extensively in prior lifetimes...
13:15:08 <cschalle> sorry for sounding ignorant, but to further clarify things for myself, is network install and network boot related? or are they two different technologies for different usecases
13:15:12 <stickster> Has anyone here discussed with Anaconda team to see how big a deal that change is?
13:16:14 <stickster> cschalle: somewhat related, in that they basically use similar codepaths... in network boot case you pull and mount the anaconda env from the net, vs. having it on an ISO already
13:16:25 <stickster> not sure if that's what you were asking.
13:16:48 <stickster> The network boot (PXE) case is very useful for classrooms, anywhere you have to do many installs
13:16:57 <cschalle> stickster, I guess I was asking if we need network install to enable network boot, or if one could network boot the live image
13:17:28 <stickster> cschalle: I think the latter would be a highly fragile case
13:17:59 <stickster> you'd have to grab the whole, what, 1.4GB+?
13:18:32 <stickster> I was thinking of network boot == PXE, for purposes of installing only
13:18:42 * cschalle should try the network boot option inside RH to see exactly what it does these days, haven't used it in years
13:18:56 <stickster> All right, I don't want to gring on this forever, what's the next thing to do here? how about this:
13:19:04 <stickster> #action stickster check with anaconda team to see how big the installclass change is
13:19:13 <cschalle> +1
13:20:11 <stickster> #topic VSCode repo
13:20:12 <stickster> #link https://pagure.io/fedora-workstation/issue/52
13:20:19 <stickster> cschalle: I think this is yours
13:21:26 <cschalle> ah yes, so I did exchange a few emails with some devs at Microsoft, but I was not able to get any clear commitment or interest in working with us atm
13:22:17 <cschalle> I will try to push again using a different channel, but I am not convinced we will get anywhere with this anytime soon
13:22:46 <stickster> Hmm, that doesn't sound as promising then -- but to be honest their installation as-is is not too difficult anyway
13:23:07 * stickster has started using VSCode here to see what the cool kids are doing and it's pretty darn nice
13:23:13 * mclasen points out that VSCode is available on flathub
13:23:40 <stickster> true, although it lags in updates a bit -- probably no different than any other repo, though, and I don't think it's usually more than a few days diff
13:24:07 <stickster> which is why it would be awesome if MS provided a flatpak :-)
13:24:47 <stickster> cschalle: Should we put this issue on back burner then?
13:24:53 <cschalle> yeah, I think so
13:25:07 * stickster would say, this really depends on them. And if no further progress in, say, 30 days, we close the issue
13:25:56 <cschalle> yeah, lets make that our plan of record
13:26:06 <stickster> done
13:26:21 <stickster> #action cschalle continue working on relationship building, if no progress in 30 days we'll close cantfix
13:26:58 <stickster> #topic Default disk partitioning layout for Workstation
13:27:00 <stickster> #link https://pagure.io/fedora-workstation/issue/54
13:29:30 <stickster> So this is an interesting one. I admit I've been a big LVM fan for a while, but it's too complicated for any "normal" person to use confidently.
13:30:20 <mclasen> there's several suggestions in that ticket
13:30:20 <stickster> And since there's been no developer effort to make tools to simplify that for workstation cases, it's not really any better now than ~4 years ago
13:30:23 <rdieter> So, one first baby step would be to nix separate /home .  Other proposals included no-LVM and use-swapfile-instead-of-swap-partition
13:31:27 <rdieter> (I'm generally in favor of all these)
13:31:30 <misc> mhh, someone should test if the system boot fine with / full if we let the user the possibility to fill it more easily
13:32:09 <rdieter> misc: "reserved" space should be a good safety measure against that
13:32:25 <stickster> rdieter: that's still 1% on a standard ext4, right?
13:32:30 <rdieter> should at least boot, can't speak for logging in successfully though
13:32:37 <rdieter> stickster: good question
13:34:02 <stickster> holy crap, it's like 5%
13:34:22 * stickster just checked his brand new partition here. Which BTW is about 250G, so about 12.5G reserved
13:34:29 <misc> rdieter: unless automatic update start to download and fill that 5%
13:34:50 <stickster> oh right, that's probably root owned
13:35:03 <misc> (but separate /home may not fix that, just make it less likely to happenà
13:35:23 <stickster> if we did keep separate /home, it's probably *more* likely to be a problem
13:35:33 <stickster> because / will be relatively smaller and thus easier to fill the reserve
13:35:40 <misc> yeah
13:35:48 <rdieter> <nod>
13:36:05 <misc> I guess the real solution would rather be more flexible partition, or rather, stop using partition as a quota systems and use proper quotas
13:37:29 <misc> cause that's IMHO half of the issue, we want to have a way to reserve space for some software, in a way that users can't interfer too much, without limiting the users
13:38:45 <stickster> So is there any prevailing opinion here about whether eliminating /home would cause *more* problems than we already have from default partition sizing?
13:39:41 * stickster notes, we do have a helpful disk-space warning right now
13:40:53 <stickster> hellloooooo
13:41:10 * mclasen is fine with single-partition layout by default
13:42:02 <mclasen> and also in favor of a swap file
13:42:02 <stickster> I feel like, especially with the warnings in place, and the large reserve space as well as hugely growing disks, eliminating separate /home is a fairly un-radical move
13:42:09 <misc> also, on the topic of lvm removal, I do not know how much it would impact docker storage, since thin partitionning, did requires device mapper and lvm, if I remember correctly (to be verified)
13:42:56 <misc> (which would matter if we want to push more docker container, but maybe that's not a priority)
13:43:59 <stickster> Hmm
13:44:04 <stickster> That's a big deal for developers
13:44:09 <mclasen> switching to  a single partition does not prevent us from using dm and lvm
13:44:20 <stickster> (I doubt podman is significantly different on that?)
13:44:38 <stickster> Yeah, you could always rely on the user to leave themselves space for it
13:45:01 <mclasen> wait, leave space for it ?
13:45:30 <misc> you would need space for a new partition, so yeah, taht's not ideal :/
13:45:33 <stickster> mclasen: well, you could do it multiple ways. Leave unpartitioned space, or simply use a loopback mounted block device backed by a big file.
13:45:39 <stickster> misc: ^
13:45:48 <stickster> which I'm guessing is the same case for swap
13:46:00 <misc> stickster: I think loopback had bad perf for device mapper :/
13:46:04 <stickster> oh, ugh
13:46:15 <misc> that's the flexible solution, so maybe for dev, that's ok
13:46:40 <mclasen> so, if container storage needs something carved out, does the partitioning ui in anaconda, know about that ?
13:46:59 <stickster> where does that go, /var/lib/docker right?
13:47:21 <misc> guess it should be checked with someone who is up to date on that
13:47:23 <stickster> so no, there's no built-in knowledge about it -- just like /var/lib/libvirt you have to separate it out if you want to reserve space for it
13:48:49 * mclasen thinks thats suboptimal
13:49:00 <misc> yeah :/
13:49:29 <stickster> /var/lib/docker/volumes is where those volumes live, apparently
13:50:12 <stickster> Well, in the single / fs case (no separate stuff) it's "catch as catch can"
13:50:30 <stickster> "got space on the disk? go for it"
13:51:54 <stickster> So what do we want to do next with this ticket?
13:52:14 <misc> having 1 single partition would also help for hardlink, not sure if flatpak can use that, or want to use that for dedup
13:53:19 * stickster notices clock ticking down
13:54:03 <mclasen> misc: ostree only hardlinks inside a single repo, and those never cross partition boundaries, so it doesn't
13:54:42 <mclasen> misc: to do more dedup, we would have to do what endless does and keep the OS and apps in a single repo
13:55:06 <misc> mclasen: I had more in mind between user and system repo for flatpak
13:55:19 <misc> but I didn't dig in details
13:55:20 <stickster> #info Lots of discussion about pros/cons of separate vs. combined /home
13:56:33 <stickster> I don't hear a clear decision or consensus here, and a couple people haven't spoken.
13:56:40 <mclasen> the main point I take away from this is that we need something in anaconda ui about reserving space for contaners and vm images
13:56:56 <stickster> Do we, though?
13:57:00 <mclasen> regardless of /home partition or not
13:57:25 <stickster> actually
13:57:27 <mclasen> I thought we said that if you don't reserve it, you don't have space for containers ?
13:57:47 <mclasen> more research needed on that, then ?
13:57:54 <stickster> well, it's not that you don't have space. you just don't get whatever the benefits are misc mentioned about thin provisioning
13:58:34 <stickster> but... come to think of it, there's also like /var/lib/pgsql, /var/lib/mysql.... so conceivably we could look at just having a separate /var/lib
13:58:43 <stickster> (on demand that is, i.e. with an option as mclasen said)
13:59:04 <stickster> who wants to look further into this for next time?
13:59:29 <stickster> well hell, I'm already doing the other anaconda thing, might as well ask about this too
13:59:36 <misc> I suspect separate /var/lib is not supported by systemd, not more than separate /var
13:59:46 <stickster> misc: in what sense?
14:00:03 <stickster> OHHH
14:00:07 <stickster> right, /var/lib/systemd. *sigh
14:00:16 <misc> stickster: there is bootstrapping issue, like you need /var to be mounted to run systemd, and systemd is need to mount it, something like that
14:00:32 <stickster> Not talking about /var though, just /var/lib
14:00:48 <stickster> however, that's where systemd puts things too... /var/lib/systemd :-(
14:01:05 <stickster> #action stickster talk to Anaconda folks about possibility of separate container/virt/sql/etc. space
14:01:09 <stickster> OK, we're overtime
14:01:10 <mclasen> this seems to be a turnaround - we started discussing less partitions, now we add more ?
14:01:36 <stickster> mclasen: well, trading them off -- eliminate separate /home, but have an *option* for a separate space for developer type things
14:01:55 <stickster> which seems perfectly rational and still solves the problem Jiri mentioned in ticket
14:02:09 * stickster closing meeting -- we'll carry on in #fedora-workstation
14:02:13 <mclasen> didn't we say that the developer type things use unpartitioned space with lvm ?
14:02:27 <stickster> still has to be mounted though
14:02:32 <stickster> #endmeeting