15:00:35 <sgallagh> #startmeeting Server Technical Specification Working Session (2014-02-27)
15:00:36 <zodbot> Meeting started Thu Feb 27 15:00:35 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:41 <sgallagh> #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr
15:00:41 <zodbot> Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta
15:00:47 <sgallagh> #topic roll call
15:01:05 * nirik is here, but trying to put out fires of the day so might not be 100% here.
15:01:17 <sgallagh> .hellomynameis sgallagh
15:01:18 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:57 <tuanta> .hellomynameis tuanta
15:02:59 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
15:03:09 <sgallagh> tuanta: glad you could make it.
15:03:38 <tuanta> Hello everyone :)
15:04:28 * sgallagh is concerned that people may have lied on the whenisgood...
15:06:02 <simo> I didn't :)
15:06:07 <nirik> or they could just be running late.
15:06:10 <sgallagh> Welcome, simo
15:06:12 <simo> just late to the party as usual :/
15:06:36 * simo a little bit immersed into a IETF DNSSEC vs local resolvers discussion
15:06:50 <sgallagh> Ick, sorry to hear that
15:07:22 * mizmo here
15:07:29 <sgallagh> Hello mizmo
15:07:35 <mizmo> hey
15:07:45 <mizmo> i have to run at 10:30 tho :(
15:07:46 <sgallagh> Ok, mizmo makes quorum, so I suppose we can get started?
15:08:20 <sgallagh> Ok, let's hope someone else joins in the next 20 minutes, I guess
15:08:37 <tuanta> Yes
15:08:48 <sgallagh> #topic Supported Architectures
15:09:27 <sgallagh> Some of the Products are considered dropping support for particular architectures.
15:10:02 <nirik> what do we mean by 'support' here tho? just not produce images/test on/deal with bugs on?
15:10:25 <sgallagh> Produce images for, I think.
15:10:26 <simo> sgallagh: we have only 3 primary arches
15:10:36 <simo> is one of them problematic for any of the products ?
15:10:47 <sgallagh> ARM is problematic for Workstation
15:10:50 <simo> why ?
15:11:14 <sgallagh> 32-bit x86 and 32-bit ARM may be problematic for us, depending on the FS choice.
15:11:23 <simo> workstation is the only product that really makes sense for arm32 ...
15:11:35 <sgallagh> simo: ARM devices are almost exclusively closed-source binary video
15:11:46 <simo> if they cut it, we could as well demote arm arch from primary
15:12:02 <simo> sgallagh: llvmpipe too expensive there ?
15:12:03 <sgallagh> If they support it, it would not be on the default desktop
15:12:16 <simo> ah wait of course it is, gnome uses a ton of GL these days even in the classic mode
15:12:18 <sgallagh> Yeah, the performance is unacceptably bad, I'm told
15:12:31 <nirik> I personally would be happy dropping x86 32bit, but since we aren't doing that, and since we need multilib anyhow, I'd propose we just support all the primary arches for now.
15:12:50 <simo> nirik: for server I do not see any problem supporting all arches
15:12:50 <sgallagh> nirik: I'd be willing to entertain dropping 32-bit as an installable image
15:12:58 <simo> arm 32 is a pita for developers, but a good one
15:13:01 <simo> catches bugs
15:13:02 <sgallagh> Yes, we'd need to support the runtime, but not the kernel
15:13:22 <simo> sgallagh: I would leave that up to kernel devs
15:13:28 <nirik> sgallagh: yeah, I guess I could be ok with that too. I think there might be some screaming, but it does reduce testing/releng/etc load.
15:13:31 <simo> they have to produce images for arm anyway
15:13:36 <sgallagh> simo: I'm actually parroting something jwb said yesterday, there :)
15:13:43 <simo> I see
15:13:57 <simo> but if arm is problematic for workstation and server
15:14:05 * jwb reads back
15:14:07 <sgallagh> Well, I'm not sure about server
15:14:08 <simo> and clearly not useful for cloud (no viert for arm)
15:14:18 <simo> then what use do we have for arm ?
15:14:45 <sgallagh> The only open question about armv7hl on Server is with regards to XFS
15:14:46 <simo> sgallagh: I thought we were discussing arches for the server ?
15:14:50 <nirik> 32bit arm soc's could make fine servers ?
15:15:05 <jwb> simo, there are ARM chips that do virt
15:15:10 <sgallagh> If we decided to go with ext4 (or make an exception for armv7hl), then that's still on the table
15:15:10 <nirik> sure ram is limited, but life is trade offs
15:15:11 <simo> nirik: I think they would but I thought sgallagh said otherwise
15:15:25 <sgallagh> There's no performance data for XFS that I was able to find readily available in the last day
15:15:25 <simo> jwb: yes I know but not that common :)
15:15:49 <simo> jwb: are there issues with xfs on arm ?
15:15:55 <simo> sgallagh: ^
15:16:02 <sgallagh> simo: Last I heard, it was a lack of information, rather than known issues.
15:16:17 <simo> then I would not wrap my head around it now
15:16:19 <jwb> i've no idea on that.  i think chris murphy emailed the XFS list and they mostly didn't know either
15:16:31 * nirik nods.
15:16:41 <nirik> so, perhaps we should just stick to ext4 for default for now.
15:16:55 <simo> xfs comes from mips which had different endianes and if memory does not fail m spectacularly also alignment issues
15:16:56 <sgallagh> I'd like to see us include ARM support if at all possible.
15:17:14 <simo> so I wouldn't be surprised if it just worked mostly fine
15:17:21 <simo> and any bug wqe find I am sure xfs people will be happy to fix
15:17:27 <simo> seem like actually a good thing to do
15:17:46 <mizmo> so let's make a proposal?
15:18:01 <simo> jwb: do you see it as a spectacularly bad idea ?
15:18:14 <jwb> simo, having XFS as a default in server?
15:18:16 <simo> nirik: I would really like xfs for server
15:18:17 <sgallagh> Perhaps we can go with ARM on XFS, with an option to scrap it for ext4 in an emergency?
15:18:31 <simo> jwb: yeah keeping in mind some unknowns on ARM
15:18:53 <simo> sgallagh: right we can always fallback to ext4 if we find out it explodes in fireworks
15:18:59 <nirik> perhaps we should ask arm folks for more input?
15:18:59 <jwb> not spectacularly bad, no.  though i wonder if you run into issues booting from XFS on ARM boards
15:19:05 <jwb> nirik, i think that would be good
15:19:40 <jwb> i forget exactly how u-boot pokes around on storage to find the kernel and such
15:19:45 <simo> nirik: sgallagh: jwb: so ok to say tentively all arches, xfs by default, with fallback plan of sticking to ext4 in case of major ARM issues with XFS ?
15:19:50 <sgallagh> jwb: Well, when we get to that topic, I was thinking about suggesting that /boot remain ext4
15:20:01 <sgallagh> But that's a discussion for the next line of conversation
15:20:30 <nirik> simo: I think thats fine if arm folks are ok with it, I think we should ping their list and see if there's any big "oh no!" :)
15:20:31 <jwb> so you'll have 3 filesystems required to just boot the machine.  good job ;)
15:20:34 <simo> sgallagh: jwb: we have similar issue with cloud wg, so perhaps boot on etxt4 is another possible fallback plan
15:20:40 <nirik> sgallagh: ? why?
15:20:40 <sgallagh> Proposal: Fedora Server will support ix86, x86_64 and armv7hl architectures on the XFS filesystem.
15:20:53 <simo> jwb: 3 ?
15:20:54 <sgallagh> nirik: Well, my next agenda item was going to be "partitioning and LVM"
15:21:04 <nirik> also, are we talking lvm2 / xfs?
15:21:08 <nirik> ah ha.
15:21:11 <simo> sgallagh: +1 to all arches + xfs
15:21:17 <jwb> simo, ext4 /boot, FAT /boot/efi/, XFS /
15:21:31 <simo> jwb: ah right, FAT (/me pukes a little)
15:21:35 <jwb> admittedly FAT only plays into UEFI machines... which is going to be most soon
15:22:39 <simo> jwb: let's put /boot on FAT too
15:22:41 * simo runs
15:22:52 <simo> >silence<
15:22:54 <sgallagh> simo: More like smoldering rage ;-)
15:22:55 <sgallagh> Anyway, votes on the proposal?
15:22:55 * simo runs AND ducks
15:22:56 <simo> sgallagh: +1
15:23:11 <nirik> sure, +1 (with the proviso that we revisit if this is a big problem for arm)
15:23:22 <sgallagh> I think that's generally assumed
15:23:36 <sgallagh> No decision is immune from being overturned
15:23:38 <tuanta> +1 too
15:24:07 <sgallagh> +1 to my own proposal, FWIW
15:24:21 <sgallagh> mizmo: ?
15:25:08 <sgallagh> Did we lose you early?
15:25:14 <mizmo> sgallagh, +1
15:25:14 <simo> adamw`: ?
15:25:55 <sgallagh> #agreed Fedora Server will support ix86, x86_64 and armv7hl architectures on the XFS filesystem (+5, 0, -0)
15:26:04 <sgallagh> #topic Partitioning and LVM
15:26:30 <simo> sgallagh: do you have a proposal already ? or is it open discussion ?
15:26:46 <sgallagh> Okay, first off:
15:27:11 <sgallagh> I'd like to suggest that, in keeping with QA's concerns, we should have only one default in the guided path.
15:27:35 <sgallagh> I.e. eliminate the drop-down allowing LVM, plain, partitions, etc.
15:28:14 <sgallagh> You should either get the recommended version or go down the custom path (and good luck to you)
15:28:37 <mizmo> hrm
15:28:56 <mitr> makes sense to me
15:28:56 <mizmo> so, anaconda was originally done that way and we added the drop down based on usabiltiy testing feedback
15:29:09 <sgallagh> My proposal for the recommended version was going to be that we create a raw /boot partition on either XFS or ext4 a / partition on LVM-XFS and a swap partition
15:29:31 <mitr> mizmo: usability for what purpose?  a server?
15:29:32 <sgallagh> I don't know if separate /home is useful in the default setup for a server
15:29:38 <mizmo> mitr, yep they were rhel sys admins
15:29:49 <nirik> sgallagh: possibly /srv instead. ;)
15:30:00 <sgallagh> nirik: That's worth discussing
15:30:26 <mitr> sgallagh: Do you mean a swap LV?
15:30:28 <mizmo> i really strongly recommend against imposing any design changes to anaconda without first talking to the anaconda guys because we have made a lot of changes based on both usability testing results and customer feedback
15:30:39 <sgallagh> mitr: Yes, that was unclear.
15:30:42 * mizmo turns into a pumpkin
15:31:11 <sgallagh> Crap, bad timing :(
15:31:18 <simo> sgallagh: swap ?
15:31:24 <simo> what for ?
15:31:38 <nirik> so, perhaps we make this less detailed for now? ie, 'work with anaconda team to identify any server specific changes that would be acceptable to both of us' ?
15:32:10 <mitr> nirik: that's kind of the default
15:32:15 <nirik> true.
15:32:37 <mitr> simo: allowing you to page out some anonymous memory in long-running little-used processes, and have more useful page cache?  (I have no idea if the numbers support this theory)
15:33:36 <simo> mitr: with current sizes of memory and disk speeds, swap is usually more harmful than useful
15:33:43 <sgallagh> I usually think of it in terms of a backup plan for memory leaks. Performance degrades but you don't have down-time from the OOM killer
15:33:51 <simo> but it may make sense sitll on memory starved machines like arm
15:34:10 <simo> sgallagh: when perf degrades to that point you wish it would oom
15:34:13 <mitr> I do think we want to strongly recommend a single generally useful default.  If anaconda has data to the effect that Server users would want flexibility, that needs to be considered (... either by giving users the choice, or by resolving the concerns that make them ask for that choice if possible)
15:34:14 <simo> trust me, been there
15:34:41 <simo> I think server people should have a top notch custom partitioning experience
15:34:49 <simo> and we should only provide a reasonable default indeed
15:34:52 <sgallagh> mitr: I'd like to know how much of that came out of the fact that Anaconda had two Fedora releases where the custom partitioning was terrible
15:35:21 <sgallagh> Now that custom is more or less fixed, is it still useful to have four "guided" paths?
15:35:26 <simo> as for the rest I agree with /boot + / on LVM
15:35:35 <simo> I would agree on separate volume for /srv too
15:35:55 <simo> and even swap (can we make it conditional to machine having, say, <= 8GB of RAM ?)
15:35:57 <mitr> sgallagh: I'd blame some of that on having to deal with LVM for people that haven't felt a need for it ("Just put / in a single partition over the disk)
15:36:23 <sgallagh> simo: That's a question for the anaconda folks, I suppose
15:36:27 <simo> yup
15:36:36 <mitr> //srv is important, but difficult to choose a good default
15:36:42 <simo> well they already size it base on the amount of RAM IIRC
15:36:45 <mitr> (I do wish we could rely on btrfs)
15:37:12 <simo> mitr: yes the problem with sizing is difficult
15:37:12 <sgallagh> mitr: Not an option, straight from the horse's mouth, I'm afraid
15:37:23 <mitr> sgallagh: I know
15:37:36 <simo> the main issue indeed being you can not shrink xfs
15:37:40 <mitr> Next best, thinp - is it usable for a default?
15:37:53 <simo> so if the default installmakes a volume "too big" that's it
15:38:41 <sgallagh> simo: Shrinking a filesystem is rarely a good idea in any case...
15:39:51 <sgallagh> mitr: I actually ran into Mike Snitzer yesterday and had a conversation about that
15:40:05 <sgallagh> From a reliability perspective, it's in good shape at this point.
15:40:16 <simo> so I think even for servers the default install we might just have to make a big / by default ?
15:40:26 <simo> or should we just leave space unpartitioned, ask ?
15:40:28 <simo> hard
15:40:38 <sgallagh> Performance-wise, they've got a couple bugs in the allocator right now that, under the right conditions (lots of parallel writes) will fragment the FS fairly badly.
15:40:58 <nirik> in the end we can only set defaults/recommend a best practice... there's just so much different use cases/hw out there...
15:41:11 <simo> sgallagh: what is in good shape ?
15:41:27 <sgallagh> simo: mitr asked about lvm thinp
15:41:32 <simo> ah
15:41:38 <jwb> lvm thinp or dm-thinp?
15:41:44 <sgallagh> lvm thinp
15:41:48 <jwb> huh
15:42:20 <simo> is thinp something we need to care about right now ?
15:42:27 <sgallagh> My impression was that this fragmentation issue is something they're working hard to fix in the next few months, so that may not be an issue.
15:42:46 <sgallagh> simo: It's a valid option for default layout
15:42:53 <mitr> simo: For the default GUI install (i.e. people who don't already know what they want), a single / would probably lead to least surprises.  OTOH there are the "best practices" for /var/log and /tmp on separate partition and the like.... IMHO mostly workarounds for other platform problems, and without a good way for us to choose a size.
15:43:00 <sgallagh> It's a workaround for the shrinking bit
15:43:32 <mitr> And it makes it at all practical to use snaphots (without pre-allocating an unknown percentage of the drive for them)
15:43:44 <sgallagh> Right
15:44:22 <sgallagh> As an aside, /var/log is a case I forgot to consider. It's often useful to have that separate to avoid runaway logs taking up your entire available space
15:45:21 <mitr> Purely in theory, that should be done by quotas or by sending everything through a single daemon managing the space... neither of which we have.  Still, what size to recommend?
15:45:28 <simo> mitr: ah you made me remember
15:45:40 <simo> I prpoose we put /tmp on a real disk and *not* on tmpfs
15:45:43 <nirik> well, journald wouldn't fill up the space. ;)
15:45:58 <mitr> Perhaps we could actually just arbitrarily decide on 1 GB, and strongly recommend and stear users towards forwarding all logs to a dedicated host - but again, cart before the horse
15:46:07 <jwb> sgallagh, what was your reasoning for using ext4 for /boot again?
15:46:08 <mitr> nirik: And so many servers do their own logs.
15:46:08 * nirik is -1 to seperate /var/lgo
15:46:26 <nirik> mitr: sure, many have central log hosts too.
15:46:28 <simo> separate /var/log makes little sense indeed
15:46:33 <simo> (by default)
15:46:41 <sgallagh> jwb: Mostly to stay in sync with the Cloud product (and so they can "upgrade" to Server without being in a different layour)
15:47:03 <jwb> ah
15:47:38 <simo> I would really liek a comment on /tmp on actual disk, and not tmpfs
15:47:44 <simo> I feel strongly about this for server cases
15:47:47 <sgallagh> simo: +1 on non-tmpfs
15:47:56 <mitr> +1 as well
15:48:02 * nirik doesn't feel strongly, +0
15:48:19 <mitr> (Again, having a per-directory instead of per-user quotas would be rather beneficial here)
15:48:23 <sgallagh> I don't think that should really be in question. It's known to break popular servers like MySQL (dunno if that applies to MariaDB still)
15:48:54 <nirik> thats news to me...
15:49:10 <nirik> anyhow, making it not tmpfs for server seems like a ok default.
15:49:26 <sgallagh> nirik: It was one of the main things people screamed about when we made this cahnges
15:49:33 <sgallagh> *gah, can't type today
15:49:57 <nirik> sgallagh: I just recall the 'oh, but I put iso images there' yelling. Anyhow, off topic, lets continue
15:50:24 <sgallagh> nirik: MySQL would put a LOT of temp data directly in /tmp
15:50:35 <sgallagh> Often causing the system to go into swap.
15:50:37 <mitr> Can we put this into meeting minutes if there is consensus, so that it isn't completely lost?
15:50:44 <sgallagh> mitr: You're a chair :)
15:50:57 <adamw> morning
15:51:10 <mitr> #info By default, /tmp should be on disk, not a tmpfs
15:51:11 <simo> nirik: not 'I' but firefox
15:51:12 * nirik looks at his completely working mariadb-server with /tmp tmpfs. Ok, whatever. ;)
15:51:20 <nirik> hey adamw
15:51:20 <simo> (iso images in /tmp)
15:51:43 <adamw> sorry i'm late!
15:51:47 <simo> but in general servers processes can create big temprary files and stealing memory to do that makes no sense
15:51:55 <adamw> what are we on?
15:51:56 <sgallagh> nirik: Like I said, MariaDB may be smarter about this.
15:51:57 <simo> the kernel already uses the page cache to make things fast
15:52:36 * adamw would be slightly concerned about varying from other Fedoras in the case of /tmp
15:52:47 <adamw> but if there's a consensus, i won't fight it.
15:53:00 <simo> nirik: stealing memory (or having to swap) for temporary files makes no sense (esp for applications that keeps the files for a long period of time)
15:53:21 <nirik> lets move on? since we already decided this? rehashing it seems a poor use of our time.
15:53:27 <sgallagh> ok
15:53:30 <simo> adamw: I think it is wrong for other products too, but not my department :)
15:53:43 <sgallagh> So on the rest of the partitioning topic, I think we agreed to take it to the anaconda folks to discuss?
15:53:56 <simo> so I guess the only thing left is about default partions/sizes ?
15:54:18 <sgallagh> #action sgallagh to talk with anaconda devs about guided vs. custom partition changes
15:54:26 <sgallagh> (To keep it on the minutes)
15:54:27 <simo> sgallagh: so proposal is /boot->ext4 rest on LVM inclusing swap ?
15:54:39 <nirik> How about: /boot gets 500mb or whatever, / gets the rest up to the size it normally makes a /home, if it would normally do that it instead leaves that unallocated.
15:54:51 <simo> and / and whatever other functional partions are on XFS
15:54:52 <mitr> sgallagh: 1) do we eliminate the option or give choice - talk to anaconda 2) do we want LVM by default - I propose to agree on "yes" 3) thinp by default - not sure who to ask about
15:55:15 <sgallagh> simo: That is what I was proposing in a nutshell, yes.
15:55:23 <nirik> I think we should just provide defaults, not mess with choices.
15:55:24 <simo> sgallagh: ok make it formal so we can vote
15:55:26 <adamw> um. I don't believe the default partition *layout* is necessarily easily configurable between products at the anaconda level. i don't believe that's a chunk that's been made 'product-dependent'. it may be wise to check if it is or can be made so before making plans
15:55:33 <simo> nirik: I agree
15:55:50 <simo> the default should be ok for someone that want's to 'test' fedora server
15:55:54 <nirik> adamw: yeah, we need to talk to anaconda folks for sure.
15:55:57 <adamw> but in theory i don't mind that idea
15:56:02 <sgallagh> #info For anaconda discussions: 1) do we eliminate the option or give choice - talk to anaconda, 2) do we want LVM by default, 3) thinp by default
15:56:08 <simo> anyone that install for real will have their own preferences, so we should have a very good custom spoke
15:56:19 <simo> and leave it to the domain expert (the admin install his own server)
15:56:22 <nirik> 2) +1, 3) +0... if it's ready fine...
15:56:33 <mitr> and 4) default partition splits and sizes
15:56:49 <sgallagh> adamw: In conversations I've had earlier today, it's been generally accepted that each Product will have its own media and will have to customize Anaconda to some extent
15:57:04 <sgallagh> I will discuss with the anaconda folks what that will take.
15:57:04 <simo> I do not understand thinp by default
15:57:27 <adamw> 1) no choice on guided path, 2) +1, 3) depends on if we have a practical *use* for it
15:57:29 <simo> what does it entail ?
15:57:43 <simo> uhm I have another idea
15:57:47 <sgallagh> simo: It *should* appear to the end user to be more or less identical to the plain LVM approach
15:57:48 <simo> probably a bad one :)
15:57:52 <adamw> sgallagh: it's the "to some extent" that I'm talking about. from my knowledge of the anaconda codebase, some parts are going to be much easier to configure than others.
15:58:02 <sgallagh> Except it doesn't allocate until it needs to and it makes snapshotting a breeze
15:58:23 <simo> should server roles, 'somehow' suggest the best partitioning ?
15:58:24 <sgallagh> adamw: Right, which is why I'm going to talk to them and find out what parts are feasible.
15:58:27 <mitr> simo: Essentially another block-allocating layer of indirection, avoiding the need to pre-allocate limited partitions sizes where you can run out of a partition before the disk is actually full
15:58:38 <sgallagh> simo: Chicken/egg problem.
15:58:40 <simo> ie freeipa puts data in /var/lib/dirsrv
15:59:02 <simo> so it will require watever partion host the directory to have enough space ?
15:59:31 <sgallagh> At least in the current Anaconda design, software choices and layout do not interact
15:59:52 <mitr> simo: The easy win would probably be to claim /srv/fedora or something like that, and use it for most data (so that e.g. the admin could put /srv on a SAN and treat the local disk as cattle).  Some roles might want to suggest a specific layout (block size/alighment, RAID config, and the like?) but chicken-egg makes that difficult.
15:59:53 <sgallagh> I suspect it would be difficult (at best) to have one spoke affect another
15:59:59 <nirik> simo: that makes me think of a even more crazy idea... ;)
16:00:41 <mitr> sgallagh: That's already happening for network -> installation source -> package set
16:00:45 <adamw> sgallagh: roger
16:00:48 <nirik> simo: default have unallocated lvm space over whatever needed for /... then when installing the roles make their fs from unallocated lvm space. :)
16:01:02 <simo> I just wanted to put out there our *supported* roles may want to dictate what our default partition schme is to some degree
16:01:11 <sgallagh> mitr: Sorry, I don't follow
16:01:16 <nirik> mitr: yeah, although we are not supposed to put anything in /srv by default...
16:01:23 <mitr> nirik: That... really needs thinp to avoid annying users with "but I have enough free space!"
16:01:54 <adamw> sgallagh: it's not really difficult to have one spoke affect another. that's part of the reason for the hub/spoke design. but it's not used as much in practice atm as was maybe considered during design
16:01:57 <simo> nirik: not a bad idea actually, though complex, probably an idea to tuck away for fedora 22 or 23
16:02:00 <nirik> well, it would be a nice win to have each roles files and data in a lv, so we can do snapshots, etc... but this is all getting way way handwavy
16:02:16 <mitr> nirik: The FHS would support us doing this, I think; this is primarily a Fedora decision.
16:02:42 <mitr> sgallagh: Those 3 spokes affect each other (in that order)
16:02:45 <simo> mitr: not for f21 IMHO
16:02:52 <simo> will require too much changes to packaging
16:03:05 <nirik> mitr: https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal
16:03:15 <adamw> if we have a solid plan to do it in future, we may want to consider using thinp by default for f21 so people who start with f21 can easily add the feature in future
16:03:31 <simo> adamw: I am worried about thinp
16:03:43 <mitr> simo: Right, probably not F21.
16:03:47 <simo> doesn;t it allow to overallocate space and then cause filesystems to crap out really badly
16:03:48 <sgallagh> I'm less worried about thinp than I was before talking to Mike yesterday.
16:03:49 <simo> ?
16:03:52 <adamw> but i'd want some kind of assurance from a domain expert that it was ready.
16:04:19 <mitr> Same here; I like the idea but don't know that much about production-readiness
16:04:57 <sgallagh> adamw: I can get him to quote it here, but Mike (upstream maintainer of LVM thinp) did say explicitly that he thought it was ready to be the default for F21 if we want it
16:05:08 <mitr> nirik: I don't think that is reading FHS correctly; it is taking away control from _programs_ (not distributions), and at the same time claiming that /srv should be the default location.
16:05:36 <nirik> mitr: take it up with FPC. There was a very long drawn out battle about this.
16:05:45 <mitr> nirik: Not this week :)
16:06:05 <nirik> I'm fine trying thinp... if it fails us we can always punt, right?
16:06:36 <sgallagh> simo: To answer your question about overcommit: that is *possible*, but we can be smarter about it in the default partitioning
16:07:01 <sgallagh> Really, it's more a problem that the standard tools (df, etc.) don't know how to report thinp partitions sanely
16:07:02 <mitr> sgallagh: If the default layout is setup to not allow using all space, we don't really benefit from thinp
16:07:46 <sgallagh> mitr: I meant that we shouldn't have e.g. / and /src both claiming 100% of the pool
16:07:53 <sgallagh> *srv
16:07:58 <mitr> sgallagh: that's what I mean
16:08:00 <simo> sgallagh: ok for me it is +1 to just one default config, +1 to LVM, -1 to thinp
16:08:16 <mitr> Can we perhaps agree on wanting to go in that direction, but only doing so after we are encountered that both the implementation and the related tooling is ready enough?
16:08:58 <mitr> ss/encountered/reasonably satisfied/, no idea what I was thinking
16:09:12 <sgallagh> I'm +1 to one default config, +1 to LVM and +1 to thinp. I think we can work out the details by the time F21 ships.
16:09:33 * nirik is +1/+1/+1 too (man, so positive today!)
16:09:41 <adamw> yeah, i'm fine with thinp or not-thinp being an implementation detail
16:10:00 <mitr> +1, +1, +0.5
16:10:17 <adamw> doesn't 0.5 round up to 1? :P
16:10:21 <sgallagh> yes
16:10:31 <sgallagh> adamw: Formal vote?
16:10:41 <adamw> i think i did it already
16:10:50 <sgallagh> Where?
16:10:57 <adamw> 1) no choice on guided path, 2) +1, 3) depends on if we have a practical *use* for it
16:11:11 <sgallagh> Ah, thanks. So 0/+1/0 ?
16:11:20 <adamw> no, +1/+1/0
16:11:28 <adamw> "no choice on guided path" = "one default config"
16:11:47 <sgallagh> ah, sorry.
16:11:55 <sgallagh> I parsed that as "no opinion"
16:12:16 <adamw> btw, to give a bit of backstory: "<sgallagh> 07:34:51> mitr: I'd like to know how much of that came out of the fact that Anaconda had two Fedora releases where the custom partitioning was terrible"
16:13:04 <adamw> almost none, really. the 'raw partitions vs. LVM' choice was inherited from pre-newUI. btrfs was added on the basis that it'd be the default Real Soon Now so we should give it exposure for testing. LVM thinp was added last release as a Change and since by then we'd thoroughly lost the concept of 'no choice on guided path', it just got stuck into the dropdown without anyone thinking too hard about it.
16:13:22 <sgallagh> By my count, we're agreed on one default config using LVM. But there's no consensus among present members on thinp.
16:14:15 <sgallagh> adamw: Thanks for the input
16:14:21 <adamw> i don't think fesco is going to be too bummed out that we haven't chosen about thinp yet?
16:14:33 <adamw> i think we could just leave it TBD
16:14:42 <sgallagh> #agreed Fedora Server would prefer a single choice for the guided storage setup (+5, 0, 0)
16:14:45 <adamw> do some testing, talk to some folks
16:15:11 <sgallagh> #agreed Fedora Server would prefer the use of LVM backing the non-/boot partitions (+5, 0, 0)
16:15:26 <sgallagh> #info No consensus was reached on the topic of LVM thin-provisioning
16:15:50 <adamw> did we decide *what* single choice we'd like?
16:15:53 <adamw> xfs-on-LVM?
16:15:56 <simo> adamw: yes
16:15:59 <sgallagh> Yes, just prior to your arrival
16:16:04 <adamw> OK, thanks. was scrolling back.
16:16:12 <sgallagh> probably ext4 for /boot, XFS-on-LVM for everything else
16:16:39 <jwb> that still seems weird to me, even taking cloud into account
16:16:44 <adamw> yup, just saw it. cool. thanks. sorry to be a diva, this topic is close to my heart ;)
16:16:49 <sgallagh> (And FAT for /boot/efi because "reasons")
16:16:51 <simo> jwb: the ext4 thing ?
16:16:59 <adamw> sgallagh: you mean UEFI FAT, not FAT. ;)
16:17:01 <jwb> simo, yes
16:17:04 <simo> I wonder really, would FAT for /boot be bad ?
16:17:05 * adamw has a spec and he's not afraid to use it
16:17:22 <sgallagh> adamw: A spec for what?
16:17:27 <pjones-> simo: we need permissions to work
16:17:29 <adamw> sgallagh: UEFI. sorry, side alley./
16:17:39 <simo> pjones-: isn;t it root-only anyway >
16:17:45 <sgallagh> np
16:18:21 <pjones-> simo: permissions wind up being the ones of / in the fs not of the mountpoint
16:18:29 <pjones-> simo: so no, not if you make it fat.
16:18:30 <adamw> not to throw a grenade into the mix, but do we want to consider what we'd *like* default behaviour on the guided path in the case of multiple disks to be?
16:18:51 <simo> pjones-: IIRC you could define the default perm at mount time, but I may be mistaken
16:19:01 <pjones-> maybe so, but it'd be one more thing that could go wrong
16:19:10 <pjones-> and, you know, also potentially lawsuit bait
16:19:18 <jwb> also, you'd still wind up with two mounts
16:19:21 <pjones-> yes.
16:19:24 <mitr> Also, doesn't FAT prohibit leading dot in file names?  Because we have such files in /boot
16:19:27 <jwb> because using the ESP as /boot is... bad
16:19:28 <simo> pjones-: sure, and I am not really proposing it, just wondering, it would reduce the FSs to support to 2
16:19:29 <adamw> also, none of this seems particularly server-specific.
16:19:34 <simo> and FAT is universally available
16:19:35 <jwb> adamw, true!
16:19:42 <pjones-> Right so there's about 5 pretty decent reasons
16:20:09 <pjones-> mitr: vfat will let you get away with that
16:20:28 <jwb> sgallagh, anyway, i didn't mean to derail things again.  i just find forcing ext4 for /boot on the chance that someone wants to turn a Cloud instance into Server to be... maybe not worth the additional complexity
16:20:33 <pjones-> just fwiw I don't think there's currently a problem with making /boot xfs
16:20:39 * adamw has the look on his face of a man who expected to set off an atomic explosion and instead got a gun with a flag saying BANG
16:20:49 <jwb> pjones-, the reasoning is for Cloud, which can't boot from xfs because syslinux
16:20:50 <mitr> adamw: multiple disks... hm.... just disable the guided path?  There's really no way to guess whether the user wanted RAID 0, RAID 1, or dedicated partition allocations
16:20:57 <pjones-> jwb: ah, fair.
16:21:02 <jwb> forcing commonality because of a lack of commonality!
16:21:27 <adamw> mitr: that's the question, yeah. disabling guided in that case is an interesting approach, actually. hadn't thought of that.
16:21:32 <sgallagh> Right, one of the stated goals of Cloud is to be trivially upgradeable to Server as well
16:21:52 <sgallagh> But I'm not immovable on this point.
16:21:59 <simo> mitr: uhmmm disabling no
16:22:01 <jwb> is the reasoning behind that in the Cloud PRD?
16:22:04 <mitr> Do we actually have any XFS-specific features that we would want to use on /boot, or any reason to expect the FS difference to matter?  If not, we could just use XFS for everything, and leave Cloud to test ext4 /boot.
16:22:05 <sgallagh> If people prefer XFS in /boot, I'm happy to vote 0
16:22:11 <sgallagh> jwb: I believe so, yes
16:22:15 <simo> would be better to just piuck one disk
16:22:18 <sgallagh> jwb: Wait, behind which part?
16:22:24 <simo> if user doesn't like the pick they go custom
16:22:27 <jwb> sgallagh, trivially upgradable to servier
16:22:29 <jwb> er, server
16:22:43 <adamw> simo: in current anaconda you get to pick which disks you want to use on both paths
16:22:44 <sgallagh> I think so. I'd have to reread
16:22:55 <sgallagh> I know it's stated as a goal
16:22:55 <jwb> i'll go looking
16:23:05 <adamw> simo: but on guided, if you pick multiple disks, anaconda decides what to do with them. currently with our agreed default I believe it'd just span both disks with a big VG
16:23:06 <simo> adamw: then problem solved ?
16:23:07 <mitr> simo: Hm, using one disk only would actually make sense as well.  (OTOH our post-install partitioning GUI is nonexistent... cockpit?)
16:23:07 <sgallagh> I.e. be able to convert a cow to a cat.
16:23:26 <adamw> simo: the question is what we want to happen if you pick more than one disk, and then let anaconda do partitioning for you
16:23:28 <sgallagh> adamw: I think that's pretty reasonable
16:23:46 <sgallagh> If you want something else, there's always custom
16:23:53 * nirik would personally never setup a machine like that, but dunno if there's any good guided we could do there.
16:24:01 <simo> adamw: ok I think we can table this for later, I would said raid1 if disks are of identical size
16:24:12 <simo> and they are 2 and .... -> rat hole
16:24:13 <adamw> i was guessing server might have a case to go with a raid-1 layout by default...yeah
16:24:22 <jwb> sgallagh, the feature doesn't seem to imply a full transition to whatever server chooses as defaults fwiw
16:24:26 <adamw> but okay, if it's too much to think about :P
16:24:40 <jwb> sgallagh, it reads more to me like "install the rest of the packages to make it Server"
16:24:51 <sgallagh> jwb: No, it doesn't. My *preference* was for us to not have two ways to install Server by default that end up in different states.
16:25:05 <sgallagh> But that's a preference, not a mandate
16:25:05 <simo> adamw: well the way I create servers I have LVM + XFS on RAID1 on 2 identical disks by default
16:25:05 <jwb> ah
16:25:08 <simo> adamw: optionally I attach a jbod on /srv
16:25:27 <simo> so if you want to mirror *my way* of doing things as the default I will be more than happy :)
16:25:35 <jwb> sgallagh, but again... you aren't installing Server by default in that case.  you're installing Cloud and then changing your mind ;)
16:25:48 <sgallagh> simo: If they're of identical size, one is still going to have /boot making it smaller...
16:25:51 <jwb> anyway, i think i should shut up.  i'm not being helpful
16:26:01 <sgallagh> jwb: No, that is helpful.
16:26:05 * nirik goes to get more coffee.
16:26:11 <simo> sgallagh: I put a copy of boot on the other for recovery
16:26:22 <sgallagh> simo:  :)
16:26:46 <simo> seriously
16:26:48 <adamw> i think it works out simplest to have the same FS for /boot on all three products if possible, even if that's not the same as what they're using for the rest of the system.
16:26:53 <adamw> and it sounds like ext4 is better for that.
16:26:56 <simo> what good is a raid1 system if boot is only on one disk ?
16:27:11 <simo> adamw: +1
16:27:42 <adamw> 'all xfs' sounds simpler *in our context*, but it means project wide we wind up with more complexity in anaconda and in testing.
16:27:55 <simo> indeed
16:28:02 <pjones-> adamw: there are pretty solid use cases for 1-disk machines that might fall under "server".  I.e. the reason you see ATMs in pairs but they don't have RAID in them.
16:28:09 <simo> sounds to me we should almost defer /boot to [base]
16:28:31 <simo> pjones-: we never said otherwise
16:28:52 <pjones-> I... wasn't attempting to contradict anything you or he had said.
16:29:02 <simo> pjones-: the q. was: what should be the default partitioning *if* the server has 2 disks
16:29:07 <adamw> pjones-: I just wanted to make sure server WG thought about the multi-disk case *as well*
16:29:15 <pjones-> Fair enough.
16:29:50 <simo> my answer was: propose raid 1 if they are of equal size, drop to custom or pick 'one' otherwise
16:31:13 <sgallagh> Let's consider this an implementation detail to sort out later.
16:32:02 <adamw> fair enough. just be thinking about it
16:32:21 <adamw> and don't ask for too much complexity unless you want dlehman showing up at your door with a large rusty ax :)
16:32:25 <sgallagh> #info Keep in mind the multiple-disk installation case.
16:34:08 <sgallagh> Ok, we're at 90 minutes already. Do we want to keep going today, or perhaps just suggest an agenda for tomorrow?
16:34:41 <adamw> what else do we have to decide?
16:34:43 <sgallagh> (an agenda for the next topic is not a bad idea either)
16:35:12 <sgallagh> There are some questions on the list around firewall and such
16:35:35 <adamw> yeah, it got long and shaggy, i was hoping we had an agenda...
16:35:36 <sgallagh> Basically anything in the thread I started about comparison with the Workstation Tech Spec
16:36:04 <sgallagh> Sorry, I'm a bit disorganized this week.
16:36:11 <adamw> we could vote on firewall and put that to bed. I'm basically +1 the desktop spec: firewalld by default.
16:37:20 <simo> given a lot of people feel strongly about firewall and I am the one that made the controversial questions I am +1 as well
16:37:24 <nirik> I think firewalld needs work, but it's the best way forward at this time. +1
16:37:36 <sgallagh> Ditto, +1
16:37:44 <simo> so unless someone else is agains tI guess we can quickly get to consensus on firewall by default
16:37:51 <mitr> +1 to firewalld as well
16:38:04 <simo> tbh I find that I was more secure before firewalld
16:38:18 <sgallagh> #agreed Fedora Server will enable firewalld by default (+5, 0, 0)
16:38:20 <simo> as I could manually and quickly add an iptables rule when needed
16:38:26 <simo> now I find myself stopping it
16:38:35 <sgallagh> firewall-cmd --add-port 389/tcp --persistent
16:38:35 <sgallagh> Done
16:38:36 <simo> but that's probably because I do not know how to deal with firewalld
16:38:39 <nirik> you still can with firewalld-cmd... just takes a bit of learning
16:38:49 <adamw> nirik: it takes a hell of a lot less learning than iptables does.
16:38:55 <nirik> indeed.
16:38:58 <simo> nirik: right, will do first time it is not a devel machine :)
16:39:12 <nirik> and it will also not hopefully change when we switch to nftables, etc.
16:39:25 <adamw> it must be slightly galling to realize you spent your requisite years of mountaintop training and chicken sacrifices to learn iptables only to find someone now wrote a *sane* firewall interface, but for those of us who didn't, it's great. ;)
16:39:43 <simo> adamw: my problme is that I know iptables in and out, I started my career building firewalls on iptables :)
16:40:05 <sgallagh> #undo
16:40:05 <zodbot> Removing item from minutes: AGREED by sgallagh at 16:38:18 : Fedora Server will enable firewalld by default (+5, 0, 0)
16:40:09 <sgallagh> #topic Firewall
16:40:11 <sgallagh> #agreed Fedora Server will enable firewalld by default (+5, 0, 0)
16:40:18 <sgallagh> #topic Server Desktop
16:40:40 <simo> hot waters :)
16:40:42 <sgallagh> notting noted on the list that RHT has stats that says 20% of RHEL servers have a desktop installed
16:40:48 <sgallagh> Is this something we care about?
16:41:05 <sgallagh> Proposal: We explicitly punt on a server desktop in Fedora 21
16:41:06 <sgallagh> +1
16:41:06 <simo> some people are uncomfortable with console only
16:41:12 <simo> -1
16:41:22 <sgallagh> Right, but we also hope to have Cockpit available by then.
16:41:41 <adamw> desktop role? :)
16:41:50 <nirik> well, what are we trying to decide here? if our defaults will have a desktop installed ?
16:41:54 <simo> can we have firefox that launches cockpit by default as graphics :-P
16:41:56 * simo ducks
16:41:57 <sgallagh> (There's nothing stopping people from installing the yum group manually, I just don't think we need to make a point of it)
16:42:12 <sgallagh> simo: That has come up, and it's not a bad idea once we get to a server desktop
16:42:36 <sgallagh> nirik: More whether we have a 'headless' vs. 'graphical' install option, I think
16:42:40 <simo> I was thinking we'd want anacond to have a non-selected 'add graphical interface' option
16:42:49 <sgallagh> My proposal is basically that our F21 install is headless only
16:42:52 <sgallagh> And work on that for F22
16:43:00 <mitr> sgallagh: I would consider enabling cockpit and punting on a desktop as a tightly coupled decision.  Punting on a desktop without providing any non-CLI option is a step backwards.
16:43:09 <adamw> i'
16:43:21 <mitr> ("would consider" isn't "am decided to vote for" yet)
16:43:24 <adamw> i'm finding it hard to conceptualize as we don't know precisely what our 'package selection' step in anaconda is going to look like, i guess
16:43:56 <adamw> but if we have something broadly like the current one, it would seem pretty trivial to have 'graphical desktop' as an optional package group (right hand side) for whatever Role you pick as the primary group (left hand side)
16:43:57 <nirik> yeah, me too, but I am largely with the idea that we don't have a default/supported DE as part of the server product.
16:44:00 <mitr> simo: If the user is using a non-headless anaconda, installing a non-headless system would be a more natural default
16:44:06 <simo> if we have an option I think we should have a barebones graphical display if the user wnats
16:44:08 <adamw> and have it non-selected by default
16:44:28 <simo> non-selected is perfectly fine
16:44:48 <sgallagh> Feel free to issue a proposal
16:44:51 <simo> I just do not think that preventing a graphical display on install is a good idea
16:45:05 <nirik> there's nothing saying we are preventing anything is there?
16:45:16 <sgallagh> Keeping in mind our ARM aspirations as well, we probably want to go with LXDE or XFCE if we want this to be uniform
16:45:18 <nirik> just not that we ship with/support/test a DE install
16:45:27 <adamw> proposal: Fedora Server will not install a graphical desktop by default, but will do nothing to conflict with having one installed and may make one available as a non-default install time choice
16:45:39 <sgallagh> adamw: +1
16:45:51 <simo> proposal: make available at install time the option to install the simplest desktop we have available as fedora packages, headless by default though
16:45:52 <nirik> sure, +1.
16:46:09 <nirik> simo: ratpoison?  :)
16:46:16 <sgallagh> simo: Supplementary to adamw's proposal?
16:46:22 <mitr> Proposal: GUI install of Server will install a GUI.  If technically possible, we will reuse Workstation's desktop technology; and we won't commit to testing anything beyond the ability to log in and start a terminal.
16:46:31 <simo> nirik: ok need better wording than 'simplest'
16:46:59 <mitr> We really should split the question of a default and the question of what to install :)
16:47:03 <adamw> -1 to mitr, i commonly do GUI installs of servers in VMs, doesn't mean I want a GUI on the server.
16:47:09 <sgallagh> mitr: Workstation isn't going to be supporting ARM, as I understand. Their default choice will be GNOME, which doesn't work on ARM yet.
16:47:23 <sgallagh> Do we want to say "GNOME for x86* and headless only for ARM"?
16:47:24 <simo> -1 to mitr proposal too
16:47:45 <simo> sgallagh: no I want to say *healdess by default*
16:48:00 <simo> sgallagh: but anaconda provides you with an option to install the GIU
16:48:00 <sgallagh> Headless by default is fine. I agree with that
16:48:02 <simo> *GUI
16:48:15 <simo> and we test one combination that works reasonably well on all arches
16:48:16 <mitr> sgallagh: The architecture difference isn't likely to be indicative of an use case difference going forward.
16:48:36 <sgallagh> But if we have an option to install a GUI, do we A) go with whatever is the Workstation default B) pick one that works on all arches or C) Pick a different one for ARM?
16:48:37 <simo> and that will be the one anaconda install when you select "add graphical interface" or whatever it will call it
16:48:53 <adamw> GNOME on a server does feel somewhat odd, but i really don't want to add anything to the release-blocking desktop set. so i'd say 1) KDE, 2) GNOME, 3) something else but we don't block on it at all.
16:48:54 <nirik> If someone wants a DE on their server thats great, but I don't think we should provide a specific one or promise to test it, etc.
16:49:01 <mitr> Using non-GNOME would actually require us to get someone to test the non-GNOME desktop; is anybody doing it?
16:49:02 <simo> sgallagh: the workstation default will probably be overkill for the server anyway
16:49:04 <adamw> or, yeah, just give you a laundry list.
16:49:12 <adamw> mitr: we test KDE at present.
16:49:20 <adamw> other desktops have no testing guarantee.
16:49:47 <simo> adamw: well we should not guarantee much on a server anyway
16:49:52 <mitr> adamw: So KDE instead of XFCE?  That's where I was going, but it would be kind of surprising :)
16:50:03 <adamw> simo: even 'log in and run a terminal' is something of a testing load. we've had fun with the DMs for Xfce and LXDE before.
16:50:04 <sgallagh> So IMHO, I think we come back to "Go for headless-only on F21 and see where we are in F22 for sharing the Workstation choice"
16:50:04 <nirik> and actually ratpoison is a good choice. ;) many servers don't have mice attached.;)
16:50:05 <simo> adamw: only that you can login and run firefox/cockpit and a terminal
16:50:07 <sgallagh> That will be best supported
16:50:12 <adamw> (hell, we had a nasty bug with KDE for F21.)
16:50:56 <simo> gnome classic ? :)
16:51:06 <sgallagh> simo: Still doesn't work on ARM
16:51:08 * adamw is fine with headless by default for F21
16:51:10 <adamw> focus time
16:51:14 <simo> ok
16:51:23 <sgallagh> I'm hoping that by F22, LLVMpipe will be in better shape
16:51:27 <adamw> we can provide some guidance 'we've thought about desktops but we're punting it to f22, you can do a 'yum groupinstall whatever' if you want one
16:51:35 <sgallagh> And we can just adopt GNOME or GNOME Classic for this
16:51:44 <sgallagh> adamw: +1
16:51:47 <nirik> adamw: +1
16:51:47 <simo> sgallagh: cpus won't magically become much more powerful :)
16:51:56 <adamw> sgallagh: the thing with llvmpipe is that it just isn't ever going to be *fast* - yeah, as simo says. but eh
16:51:57 <sgallagh> simo: No, but optimizations may
16:52:07 <simo> nope
16:52:12 <simo> but who cares
16:52:19 <simo> we are deferring apparently anwya
16:52:28 <sgallagh> I think we have plenty on our plate for this release anyway.
16:52:55 <sgallagh> As adamw says, we can advise them to do a yum groupinstall if they need a desktop
16:52:58 <simo> I just would like it to be easy to add onw of the available DEs at install time I do not even care we officially QA it
16:53:16 <sgallagh> adamw: Is that an option, or would QA rebel at such an idea?
16:53:23 <nirik> were we limiting the install choices in the server install?
16:53:45 <sgallagh> nirik: Wasn't that the plan of record?
16:54:06 * nirik was picturing a server roles spoke for server roles, and normal groups for package install? or was I misremembering
16:54:10 <simo> sgallagh: I thought we'd limit variation in the default install, not prevent installing packages
16:54:11 <sgallagh> That the install would be pretty much just the standard package set with the option to install some Roles
16:54:19 <nirik> ok
16:54:38 <sgallagh> Maybe we never touched on the standard package install piece.
16:54:56 <simo> I think the issue here is that we should make it clear the default is headless, and if you do not go and choose a DE from the package lists you won't get one
16:54:59 <nirik> and packages/groups not available in ks either?
16:55:10 <nirik> that would make the server install media a lot less flexable.
16:55:14 <sgallagh> nirik: Kickstart should have full control
16:55:36 <nirik> simo: sure.
16:55:47 <simo> sgallagh: I do not see why we should remove option to add packages/groups at install time
16:56:00 <adamw> sgallagh: we'd be very unhappy with the idea of undertaking that any desktops outside GNOME/KDE will *work* at all.
16:56:12 <adamw> sgallagh: as far as QA is concerned you can *offer* as many as you like if there's no guarantee that they're going to work.
16:56:25 <sgallagh> adamw: Ok
16:56:34 <adamw> with my generalist/server WG hat on again I think it's kind of bad to offer a choice we don't stand behind, or at least that would have to be well messaged.
16:56:47 <adamw> (but then, current Fedora does it, sooo....)
16:56:52 <nirik> simo: me either. ;) Have our defaults, let folks go from there if they want to go off the tested path
16:56:53 <andreasn_> so the 20% number for Desktops installed, is that mainly because CLI is just too hard in some cases? Was there any data on this?
16:57:18 <sgallagh> andreasn_: I don't have anything further on it.
16:57:24 <adamw> basically, with a QA hat on I'm OK with headless by default, or using GNOME or KDE in any way, or offering any other desktop but not guaranteeing any functionality for it (unless server WG is very happy about taking on the testing itself).
16:57:38 <simo> andreasn_: some people are not born on consoles, and they just prefer to do everything on the server including firefox/whatever
16:57:58 <sgallagh> #topic Software Installation
16:58:24 <andreasn_> simo, yeah. Ideally that can be done via the web admin ui (Cockpit) to cover that case
16:58:41 <sgallagh> What about the case where we're on the offline install media?
16:58:51 <andreasn_> (and sorry for repeating anything that's been said already), and also, oops, new topic
16:58:53 <simo> what about that >
16:58:53 <sgallagh> In that case, there's not going to be access to any packages not part of the base or roles
16:59:04 <nirik> sgallagh: another thing to ask anaconda folks. ;)
16:59:09 <simo> sgallagh: then too bad :)
16:59:27 <sgallagh> Sure, I just wanted to note that.
16:59:31 <nirik> if we have local repo foo and no net, can anaconda display only those things in foo and install them ok? or does it need more?
17:00:14 <sgallagh> Proposal: Available packages will be shown based on the selected install source. Fedora Server will not restrict any from being installed, but does not commit to supporting anything not part of the Roles.
17:00:23 <mitr> nirik: I think it's basically able to work with any soet of repos, including the set of "the only repo on the local DVD"
17:00:44 <sgallagh> I think it needs to be able to retrieve a comps.xml from the repos
17:00:51 * adamw has to split time with another meeting at this point
17:00:51 <sgallagh> If it can do that, it will display the appropriate choices.
17:00:54 <adamw> poke me if there's a vote
17:01:03 <sgallagh> adamw: I just submitted one above
17:01:05 <mitr> sgallagh: right, I forgot about comps.
17:01:05 <nirik> sgallagh: +1
17:01:06 <simo> I need to go as well
17:01:10 <simo> sgallagh: +1
17:01:28 <abadger1999> Ya'll almost done?
17:01:32 * spot looks around
17:01:33 <sgallagh> We'll finish this vote and resume tomorrow
17:01:40 <sgallagh> abadger1999: Yeah, sorry. Ran a little over.
17:01:46 <abadger1999> No worries.
17:01:47 * spot gets the broom
17:01:52 <mitr> sgallagh: 1. is kind of default; 2 ... do we want to mention best-effort for (some?) server packages that are not yet a role?  Arguably that's also implied.
17:02:05 <sgallagh> mitr: Let's leave that for tomorrow
17:02:26 <simo> sgallagh: I think we need to close shop anyway ?
17:02:36 <simo> spot: do you have a meeting her enow ?
17:02:37 <sgallagh> Yeah, I was just hoping to get enough votes.
17:02:47 <spot> simo: yep.
17:02:49 <simo> ok
17:02:50 <sgallagh> adamw: can you vote and we'll close out?
17:02:54 <simo> sgallagh: please close down
17:02:59 <sgallagh> Ok
17:03:00 <adamw> sure, one sec
17:03:23 <adamw> i can be +1 to that, but as part of the whole 'product focus' thing i'd quite like there to be a solid emphasis on 'pick a role and move on'
17:03:28 <sgallagh> #agreed Available packages will be shown based on the selected install source. Fedora Server will not restrict any from being installed, but does not commit to supporting anything not part of the Roles. (+5, 0, 0)
17:03:33 <sgallagh> #endmeeting