15:00:35 #startmeeting Server Technical Specification Working Session (2014-02-27) 15:00:36 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:41 #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr 15:00:41 Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta 15:00:47 #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 .hellomynameis sgallagh 15:01:18 sgallagh: sgallagh 'Stephen Gallagher' 15:02:57 .hellomynameis tuanta 15:02:59 tuanta: tuanta 'Truong Anh Tuan' 15:03:09 tuanta: glad you could make it. 15:03:38 Hello everyone :) 15:04:28 * sgallagh is concerned that people may have lied on the whenisgood... 15:06:02 I didn't :) 15:06:07 or they could just be running late. 15:06:10 Welcome, simo 15:06:12 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 Ick, sorry to hear that 15:07:22 * mizmo here 15:07:29 Hello mizmo 15:07:35 hey 15:07:45 i have to run at 10:30 tho :( 15:07:46 Ok, mizmo makes quorum, so I suppose we can get started? 15:08:20 Ok, let's hope someone else joins in the next 20 minutes, I guess 15:08:37 Yes 15:08:48 #topic Supported Architectures 15:09:27 Some of the Products are considered dropping support for particular architectures. 15:10:02 what do we mean by 'support' here tho? just not produce images/test on/deal with bugs on? 15:10:25 Produce images for, I think. 15:10:26 sgallagh: we have only 3 primary arches 15:10:36 is one of them problematic for any of the products ? 15:10:47 ARM is problematic for Workstation 15:10:50 why ? 15:11:14 32-bit x86 and 32-bit ARM may be problematic for us, depending on the FS choice. 15:11:23 workstation is the only product that really makes sense for arm32 ... 15:11:35 simo: ARM devices are almost exclusively closed-source binary video 15:11:46 if they cut it, we could as well demote arm arch from primary 15:12:02 sgallagh: llvmpipe too expensive there ? 15:12:03 If they support it, it would not be on the default desktop 15:12:16 ah wait of course it is, gnome uses a ton of GL these days even in the classic mode 15:12:18 Yeah, the performance is unacceptably bad, I'm told 15:12:31 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 nirik: for server I do not see any problem supporting all arches 15:12:50 nirik: I'd be willing to entertain dropping 32-bit as an installable image 15:12:58 arm 32 is a pita for developers, but a good one 15:13:01 catches bugs 15:13:02 Yes, we'd need to support the runtime, but not the kernel 15:13:22 sgallagh: I would leave that up to kernel devs 15:13:28 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 they have to produce images for arm anyway 15:13:36 simo: I'm actually parroting something jwb said yesterday, there :) 15:13:43 I see 15:13:57 but if arm is problematic for workstation and server 15:14:05 * jwb reads back 15:14:07 Well, I'm not sure about server 15:14:08 and clearly not useful for cloud (no viert for arm) 15:14:18 then what use do we have for arm ? 15:14:45 The only open question about armv7hl on Server is with regards to XFS 15:14:46 sgallagh: I thought we were discussing arches for the server ? 15:14:50 32bit arm soc's could make fine servers ? 15:15:05 simo, there are ARM chips that do virt 15:15:10 If we decided to go with ext4 (or make an exception for armv7hl), then that's still on the table 15:15:10 sure ram is limited, but life is trade offs 15:15:11 nirik: I think they would but I thought sgallagh said otherwise 15:15:25 There's no performance data for XFS that I was able to find readily available in the last day 15:15:25 jwb: yes I know but not that common :) 15:15:49 jwb: are there issues with xfs on arm ? 15:15:55 sgallagh: ^ 15:16:02 simo: Last I heard, it was a lack of information, rather than known issues. 15:16:17 then I would not wrap my head around it now 15:16:19 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 so, perhaps we should just stick to ext4 for default for now. 15:16:55 xfs comes from mips which had different endianes and if memory does not fail m spectacularly also alignment issues 15:16:56 I'd like to see us include ARM support if at all possible. 15:17:14 so I wouldn't be surprised if it just worked mostly fine 15:17:21 and any bug wqe find I am sure xfs people will be happy to fix 15:17:27 seem like actually a good thing to do 15:17:46 so let's make a proposal? 15:18:01 jwb: do you see it as a spectacularly bad idea ? 15:18:14 simo, having XFS as a default in server? 15:18:16 nirik: I would really like xfs for server 15:18:17 Perhaps we can go with ARM on XFS, with an option to scrap it for ext4 in an emergency? 15:18:31 jwb: yeah keeping in mind some unknowns on ARM 15:18:53 sgallagh: right we can always fallback to ext4 if we find out it explodes in fireworks 15:18:59 perhaps we should ask arm folks for more input? 15:18:59 not spectacularly bad, no. though i wonder if you run into issues booting from XFS on ARM boards 15:19:05 nirik, i think that would be good 15:19:40 i forget exactly how u-boot pokes around on storage to find the kernel and such 15:19:45 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 jwb: Well, when we get to that topic, I was thinking about suggesting that /boot remain ext4 15:20:01 But that's a discussion for the next line of conversation 15:20:30 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 so you'll have 3 filesystems required to just boot the machine. good job ;) 15:20:34 sgallagh: jwb: we have similar issue with cloud wg, so perhaps boot on etxt4 is another possible fallback plan 15:20:40 sgallagh: ? why? 15:20:40 Proposal: Fedora Server will support ix86, x86_64 and armv7hl architectures on the XFS filesystem. 15:20:53 jwb: 3 ? 15:20:54 nirik: Well, my next agenda item was going to be "partitioning and LVM" 15:21:04 also, are we talking lvm2 / xfs? 15:21:08 ah ha. 15:21:11 sgallagh: +1 to all arches + xfs 15:21:17 simo, ext4 /boot, FAT /boot/efi/, XFS / 15:21:31 jwb: ah right, FAT (/me pukes a little) 15:21:35 admittedly FAT only plays into UEFI machines... which is going to be most soon 15:22:39 jwb: let's put /boot on FAT too 15:22:41 * simo runs 15:22:52 >silence< 15:22:54 simo: More like smoldering rage ;-) 15:22:55 Anyway, votes on the proposal? 15:22:55 * simo runs AND ducks 15:22:56 sgallagh: +1 15:23:11 sure, +1 (with the proviso that we revisit if this is a big problem for arm) 15:23:22 I think that's generally assumed 15:23:36 No decision is immune from being overturned 15:23:38 +1 too 15:24:07 +1 to my own proposal, FWIW 15:24:21 mizmo: ? 15:25:08 Did we lose you early? 15:25:14 sgallagh, +1 15:25:14 adamw`: ? 15:25:55 #agreed Fedora Server will support ix86, x86_64 and armv7hl architectures on the XFS filesystem (+5, 0, -0) 15:26:04 #topic Partitioning and LVM 15:26:30 sgallagh: do you have a proposal already ? or is it open discussion ? 15:26:46 Okay, first off: 15:27:11 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 I.e. eliminate the drop-down allowing LVM, plain, partitions, etc. 15:28:14 You should either get the recommended version or go down the custom path (and good luck to you) 15:28:37 hrm 15:28:56 makes sense to me 15:28:56 so, anaconda was originally done that way and we added the drop down based on usabiltiy testing feedback 15:29:09 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 mizmo: usability for what purpose? a server? 15:29:32 I don't know if separate /home is useful in the default setup for a server 15:29:38 mitr, yep they were rhel sys admins 15:29:49 sgallagh: possibly /srv instead. ;) 15:30:00 nirik: That's worth discussing 15:30:26 sgallagh: Do you mean a swap LV? 15:30:28 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 mitr: Yes, that was unclear. 15:30:42 * mizmo turns into a pumpkin 15:31:11 Crap, bad timing :( 15:31:18 sgallagh: swap ? 15:31:24 what for ? 15:31:38 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 nirik: that's kind of the default 15:32:15 true. 15:32:37 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 mitr: with current sizes of memory and disk speeds, swap is usually more harmful than useful 15:33:43 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 but it may make sense sitll on memory starved machines like arm 15:34:10 sgallagh: when perf degrades to that point you wish it would oom 15:34:13 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 trust me, been there 15:34:41 I think server people should have a top notch custom partitioning experience 15:34:49 and we should only provide a reasonable default indeed 15:34:52 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 Now that custom is more or less fixed, is it still useful to have four "guided" paths? 15:35:26 as for the rest I agree with /boot + / on LVM 15:35:35 I would agree on separate volume for /srv too 15:35:55 and even swap (can we make it conditional to machine having, say, <= 8GB of RAM ?) 15:35:57 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 simo: That's a question for the anaconda folks, I suppose 15:36:27 yup 15:36:36 //srv is important, but difficult to choose a good default 15:36:42 well they already size it base on the amount of RAM IIRC 15:36:45 (I do wish we could rely on btrfs) 15:37:12 mitr: yes the problem with sizing is difficult 15:37:12 mitr: Not an option, straight from the horse's mouth, I'm afraid 15:37:23 sgallagh: I know 15:37:36 the main issue indeed being you can not shrink xfs 15:37:40 Next best, thinp - is it usable for a default? 15:37:53 so if the default installmakes a volume "too big" that's it 15:38:41 simo: Shrinking a filesystem is rarely a good idea in any case... 15:39:51 mitr: I actually ran into Mike Snitzer yesterday and had a conversation about that 15:40:05 From a reliability perspective, it's in good shape at this point. 15:40:16 so I think even for servers the default install we might just have to make a big / by default ? 15:40:26 or should we just leave space unpartitioned, ask ? 15:40:28 hard 15:40:38 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 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 sgallagh: what is in good shape ? 15:41:27 simo: mitr asked about lvm thinp 15:41:32 ah 15:41:38 lvm thinp or dm-thinp? 15:41:44 lvm thinp 15:41:48 huh 15:42:20 is thinp something we need to care about right now ? 15:42:27 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 simo: It's a valid option for default layout 15:42:53 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 It's a workaround for the shrinking bit 15:43:32 And it makes it at all practical to use snaphots (without pre-allocating an unknown percentage of the drive for them) 15:43:44 Right 15:44:22 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 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 mitr: ah you made me remember 15:45:40 I prpoose we put /tmp on a real disk and *not* on tmpfs 15:45:43 well, journald wouldn't fill up the space. ;) 15:45:58 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 sgallagh, what was your reasoning for using ext4 for /boot again? 15:46:08 nirik: And so many servers do their own logs. 15:46:08 * nirik is -1 to seperate /var/lgo 15:46:26 mitr: sure, many have central log hosts too. 15:46:28 separate /var/log makes little sense indeed 15:46:33 (by default) 15:46:41 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 ah 15:47:38 I would really liek a comment on /tmp on actual disk, and not tmpfs 15:47:44 I feel strongly about this for server cases 15:47:47 simo: +1 on non-tmpfs 15:47:56 +1 as well 15:48:02 * nirik doesn't feel strongly, +0 15:48:19 (Again, having a per-directory instead of per-user quotas would be rather beneficial here) 15:48:23 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 thats news to me... 15:49:10 anyhow, making it not tmpfs for server seems like a ok default. 15:49:26 nirik: It was one of the main things people screamed about when we made this cahnges 15:49:33 *gah, can't type today 15:49:57 sgallagh: I just recall the 'oh, but I put iso images there' yelling. Anyhow, off topic, lets continue 15:50:24 nirik: MySQL would put a LOT of temp data directly in /tmp 15:50:35 Often causing the system to go into swap. 15:50:37 Can we put this into meeting minutes if there is consensus, so that it isn't completely lost? 15:50:44 mitr: You're a chair :) 15:50:57 morning 15:51:10 #info By default, /tmp should be on disk, not a tmpfs 15:51:11 nirik: not 'I' but firefox 15:51:12 * nirik looks at his completely working mariadb-server with /tmp tmpfs. Ok, whatever. ;) 15:51:20 hey adamw 15:51:20 (iso images in /tmp) 15:51:43 sorry i'm late! 15:51:47 but in general servers processes can create big temprary files and stealing memory to do that makes no sense 15:51:55 what are we on? 15:51:56 nirik: Like I said, MariaDB may be smarter about this. 15:51:57 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 but if there's a consensus, i won't fight it. 15:53:00 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 lets move on? since we already decided this? rehashing it seems a poor use of our time. 15:53:27 ok 15:53:30 adamw: I think it is wrong for other products too, but not my department :) 15:53:43 So on the rest of the partitioning topic, I think we agreed to take it to the anaconda folks to discuss? 15:53:56 so I guess the only thing left is about default partions/sizes ? 15:54:18 #action sgallagh to talk with anaconda devs about guided vs. custom partition changes 15:54:26 (To keep it on the minutes) 15:54:27 sgallagh: so proposal is /boot->ext4 rest on LVM inclusing swap ? 15:54:39 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 and / and whatever other functional partions are on XFS 15:54:52 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 simo: That is what I was proposing in a nutshell, yes. 15:55:23 I think we should just provide defaults, not mess with choices. 15:55:24 sgallagh: ok make it formal so we can vote 15:55:26 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 nirik: I agree 15:55:50 the default should be ok for someone that want's to 'test' fedora server 15:55:54 adamw: yeah, we need to talk to anaconda folks for sure. 15:55:57 but in theory i don't mind that idea 15:56:02 #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 anyone that install for real will have their own preferences, so we should have a very good custom spoke 15:56:19 and leave it to the domain expert (the admin install his own server) 15:56:22 2) +1, 3) +0... if it's ready fine... 15:56:33 and 4) default partition splits and sizes 15:56:49 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 I will discuss with the anaconda folks what that will take. 15:57:04 I do not understand thinp by default 15:57:27 1) no choice on guided path, 2) +1, 3) depends on if we have a practical *use* for it 15:57:29 what does it entail ? 15:57:43 uhm I have another idea 15:57:47 simo: It *should* appear to the end user to be more or less identical to the plain LVM approach 15:57:48 probably a bad one :) 15:57:52 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 Except it doesn't allocate until it needs to and it makes snapshotting a breeze 15:58:23 should server roles, 'somehow' suggest the best partitioning ? 15:58:24 adamw: Right, which is why I'm going to talk to them and find out what parts are feasible. 15:58:27 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 simo: Chicken/egg problem. 15:58:40 ie freeipa puts data in /var/lib/dirsrv 15:59:02 so it will require watever partion host the directory to have enough space ? 15:59:31 At least in the current Anaconda design, software choices and layout do not interact 15:59:52 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 I suspect it would be difficult (at best) to have one spoke affect another 15:59:59 simo: that makes me think of a even more crazy idea... ;) 16:00:41 sgallagh: That's already happening for network -> installation source -> package set 16:00:45 sgallagh: roger 16:00:48 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 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 mitr: Sorry, I don't follow 16:01:16 mitr: yeah, although we are not supposed to put anything in /srv by default... 16:01:23 nirik: That... really needs thinp to avoid annying users with "but I have enough free space!" 16:01:54 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 nirik: not a bad idea actually, though complex, probably an idea to tuck away for fedora 22 or 23 16:02:00 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 nirik: The FHS would support us doing this, I think; this is primarily a Fedora decision. 16:02:42 sgallagh: Those 3 spokes affect each other (in that order) 16:02:45 mitr: not for f21 IMHO 16:02:52 will require too much changes to packaging 16:03:05 mitr: https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal 16:03:15 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 adamw: I am worried about thinp 16:03:43 simo: Right, probably not F21. 16:03:47 doesn;t it allow to overallocate space and then cause filesystems to crap out really badly 16:03:48 I'm less worried about thinp than I was before talking to Mike yesterday. 16:03:49 ? 16:03:52 but i'd want some kind of assurance from a domain expert that it was ready. 16:04:19 Same here; I like the idea but don't know that much about production-readiness 16:04:57 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 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 mitr: take it up with FPC. There was a very long drawn out battle about this. 16:05:45 nirik: Not this week :) 16:06:05 I'm fine trying thinp... if it fails us we can always punt, right? 16:06:36 simo: To answer your question about overcommit: that is *possible*, but we can be smarter about it in the default partitioning 16:07:01 Really, it's more a problem that the standard tools (df, etc.) don't know how to report thinp partitions sanely 16:07:02 sgallagh: If the default layout is setup to not allow using all space, we don't really benefit from thinp 16:07:46 mitr: I meant that we shouldn't have e.g. / and /src both claiming 100% of the pool 16:07:53 *srv 16:07:58 sgallagh: that's what I mean 16:08:00 sgallagh: ok for me it is +1 to just one default config, +1 to LVM, -1 to thinp 16:08:16 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 ss/encountered/reasonably satisfied/, no idea what I was thinking 16:09:12 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 yeah, i'm fine with thinp or not-thinp being an implementation detail 16:10:00 +1, +1, +0.5 16:10:17 doesn't 0.5 round up to 1? :P 16:10:21 yes 16:10:31 adamw: Formal vote? 16:10:41 i think i did it already 16:10:50 Where? 16:10:57 1) no choice on guided path, 2) +1, 3) depends on if we have a practical *use* for it 16:11:11 Ah, thanks. So 0/+1/0 ? 16:11:20 no, +1/+1/0 16:11:28 "no choice on guided path" = "one default config" 16:11:47 ah, sorry. 16:11:55 I parsed that as "no opinion" 16:12:16 btw, to give a bit of backstory: " 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 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 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 adamw: Thanks for the input 16:14:21 i don't think fesco is going to be too bummed out that we haven't chosen about thinp yet? 16:14:33 i think we could just leave it TBD 16:14:42 #agreed Fedora Server would prefer a single choice for the guided storage setup (+5, 0, 0) 16:14:45 do some testing, talk to some folks 16:15:11 #agreed Fedora Server would prefer the use of LVM backing the non-/boot partitions (+5, 0, 0) 16:15:26 #info No consensus was reached on the topic of LVM thin-provisioning 16:15:50 did we decide *what* single choice we'd like? 16:15:53 xfs-on-LVM? 16:15:56 adamw: yes 16:15:59 Yes, just prior to your arrival 16:16:04 OK, thanks. was scrolling back. 16:16:12 probably ext4 for /boot, XFS-on-LVM for everything else 16:16:39 that still seems weird to me, even taking cloud into account 16:16:44 yup, just saw it. cool. thanks. sorry to be a diva, this topic is close to my heart ;) 16:16:49 (And FAT for /boot/efi because "reasons") 16:16:51 jwb: the ext4 thing ? 16:16:59 sgallagh: you mean UEFI FAT, not FAT. ;) 16:17:01 simo, yes 16:17:04 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 adamw: A spec for what? 16:17:27 simo: we need permissions to work 16:17:29 sgallagh: UEFI. sorry, side alley./ 16:17:39 pjones-: isn;t it root-only anyway > 16:17:45 np 16:18:21 simo: permissions wind up being the ones of / in the fs not of the mountpoint 16:18:29 simo: so no, not if you make it fat. 16:18:30 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 pjones-: IIRC you could define the default perm at mount time, but I may be mistaken 16:19:01 maybe so, but it'd be one more thing that could go wrong 16:19:10 and, you know, also potentially lawsuit bait 16:19:18 also, you'd still wind up with two mounts 16:19:21 yes. 16:19:24 Also, doesn't FAT prohibit leading dot in file names? Because we have such files in /boot 16:19:27 because using the ESP as /boot is... bad 16:19:28 pjones-: sure, and I am not really proposing it, just wondering, it would reduce the FSs to support to 2 16:19:29 also, none of this seems particularly server-specific. 16:19:34 and FAT is universally available 16:19:35 adamw, true! 16:19:42 Right so there's about 5 pretty decent reasons 16:20:09 mitr: vfat will let you get away with that 16:20:28 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 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 pjones-, the reasoning is for Cloud, which can't boot from xfs because syslinux 16:20:50 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 jwb: ah, fair. 16:21:02 forcing commonality because of a lack of commonality! 16:21:27 mitr: that's the question, yeah. disabling guided in that case is an interesting approach, actually. hadn't thought of that. 16:21:32 Right, one of the stated goals of Cloud is to be trivially upgradeable to Server as well 16:21:52 But I'm not immovable on this point. 16:21:59 mitr: uhmmm disabling no 16:22:01 is the reasoning behind that in the Cloud PRD? 16:22:04 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 If people prefer XFS in /boot, I'm happy to vote 0 16:22:11 jwb: I believe so, yes 16:22:15 would be better to just piuck one disk 16:22:18 jwb: Wait, behind which part? 16:22:24 if user doesn't like the pick they go custom 16:22:27 sgallagh, trivially upgradable to servier 16:22:29 er, server 16:22:43 simo: in current anaconda you get to pick which disks you want to use on both paths 16:22:44 I think so. I'd have to reread 16:22:55 I know it's stated as a goal 16:22:55 i'll go looking 16:23:05 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 adamw: then problem solved ? 16:23:07 simo: Hm, using one disk only would actually make sense as well. (OTOH our post-install partitioning GUI is nonexistent... cockpit?) 16:23:07 I.e. be able to convert a cow to a cat. 16:23:26 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 adamw: I think that's pretty reasonable 16:23:46 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 adamw: ok I think we can table this for later, I would said raid1 if disks are of identical size 16:24:12 and they are 2 and .... -> rat hole 16:24:13 i was guessing server might have a case to go with a raid-1 layout by default...yeah 16:24:22 sgallagh, the feature doesn't seem to imply a full transition to whatever server chooses as defaults fwiw 16:24:26 but okay, if it's too much to think about :P 16:24:40 sgallagh, it reads more to me like "install the rest of the packages to make it Server" 16:24:51 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 But that's a preference, not a mandate 16:25:05 adamw: well the way I create servers I have LVM + XFS on RAID1 on 2 identical disks by default 16:25:05 ah 16:25:08 adamw: optionally I attach a jbod on /srv 16:25:27 so if you want to mirror *my way* of doing things as the default I will be more than happy :) 16:25:35 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 simo: If they're of identical size, one is still going to have /boot making it smaller... 16:25:51 anyway, i think i should shut up. i'm not being helpful 16:26:01 jwb: No, that is helpful. 16:26:05 * nirik goes to get more coffee. 16:26:11 sgallagh: I put a copy of boot on the other for recovery 16:26:22 simo: :) 16:26:46 seriously 16:26:48 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 and it sounds like ext4 is better for that. 16:26:56 what good is a raid1 system if boot is only on one disk ? 16:27:11 adamw: +1 16:27:42 '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 indeed 16:28:02 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 sounds to me we should almost defer /boot to [base] 16:28:31 pjones-: we never said otherwise 16:28:52 I... wasn't attempting to contradict anything you or he had said. 16:29:02 pjones-: the q. was: what should be the default partitioning *if* the server has 2 disks 16:29:07 pjones-: I just wanted to make sure server WG thought about the multi-disk case *as well* 16:29:15 Fair enough. 16:29:50 my answer was: propose raid 1 if they are of equal size, drop to custom or pick 'one' otherwise 16:31:13 Let's consider this an implementation detail to sort out later. 16:32:02 fair enough. just be thinking about it 16:32:21 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 #info Keep in mind the multiple-disk installation case. 16:34:08 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 what else do we have to decide? 16:34:43 (an agenda for the next topic is not a bad idea either) 16:35:12 There are some questions on the list around firewall and such 16:35:35 yeah, it got long and shaggy, i was hoping we had an agenda... 16:35:36 Basically anything in the thread I started about comparison with the Workstation Tech Spec 16:36:04 Sorry, I'm a bit disorganized this week. 16:36:11 we could vote on firewall and put that to bed. I'm basically +1 the desktop spec: firewalld by default. 16:37:20 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 I think firewalld needs work, but it's the best way forward at this time. +1 16:37:36 Ditto, +1 16:37:44 so unless someone else is agains tI guess we can quickly get to consensus on firewall by default 16:37:51 +1 to firewalld as well 16:38:04 tbh I find that I was more secure before firewalld 16:38:18 #agreed Fedora Server will enable firewalld by default (+5, 0, 0) 16:38:20 as I could manually and quickly add an iptables rule when needed 16:38:26 now I find myself stopping it 16:38:35 firewall-cmd --add-port 389/tcp --persistent 16:38:35 Done 16:38:36 but that's probably because I do not know how to deal with firewalld 16:38:39 you still can with firewalld-cmd... just takes a bit of learning 16:38:49 nirik: it takes a hell of a lot less learning than iptables does. 16:38:55 indeed. 16:38:58 nirik: right, will do first time it is not a devel machine :) 16:39:12 and it will also not hopefully change when we switch to nftables, etc. 16:39:25 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 adamw: my problme is that I know iptables in and out, I started my career building firewalls on iptables :) 16:40:05 #undo 16:40:05 Removing item from minutes: AGREED by sgallagh at 16:38:18 : Fedora Server will enable firewalld by default (+5, 0, 0) 16:40:09 #topic Firewall 16:40:11 #agreed Fedora Server will enable firewalld by default (+5, 0, 0) 16:40:18 #topic Server Desktop 16:40:40 hot waters :) 16:40:42 notting noted on the list that RHT has stats that says 20% of RHEL servers have a desktop installed 16:40:48 Is this something we care about? 16:41:05 Proposal: We explicitly punt on a server desktop in Fedora 21 16:41:06 +1 16:41:06 some people are uncomfortable with console only 16:41:12 -1 16:41:22 Right, but we also hope to have Cockpit available by then. 16:41:41 desktop role? :) 16:41:50 well, what are we trying to decide here? if our defaults will have a desktop installed ? 16:41:54 can we have firefox that launches cockpit by default as graphics :-P 16:41:56 * simo ducks 16:41:57 (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 simo: That has come up, and it's not a bad idea once we get to a server desktop 16:42:36 nirik: More whether we have a 'headless' vs. 'graphical' install option, I think 16:42:40 I was thinking we'd want anacond to have a non-selected 'add graphical interface' option 16:42:49 My proposal is basically that our F21 install is headless only 16:42:52 And work on that for F22 16:43:00 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 i' 16:43:21 ("would consider" isn't "am decided to vote for" yet) 16:43:24 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 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 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 simo: If the user is using a non-headless anaconda, installing a non-headless system would be a more natural default 16:44:06 if we have an option I think we should have a barebones graphical display if the user wnats 16:44:08 and have it non-selected by default 16:44:28 non-selected is perfectly fine 16:44:48 Feel free to issue a proposal 16:44:51 I just do not think that preventing a graphical display on install is a good idea 16:45:05 there's nothing saying we are preventing anything is there? 16:45:16 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 just not that we ship with/support/test a DE install 16:45:27 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 adamw: +1 16:45:51 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 sure, +1. 16:46:09 simo: ratpoison? :) 16:46:16 simo: Supplementary to adamw's proposal? 16:46:22 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 nirik: ok need better wording than 'simplest' 16:46:59 We really should split the question of a default and the question of what to install :) 16:47:03 -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 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 Do we want to say "GNOME for x86* and headless only for ARM"? 16:47:24 -1 to mitr proposal too 16:47:45 sgallagh: no I want to say *healdess by default* 16:48:00 sgallagh: but anaconda provides you with an option to install the GIU 16:48:00 Headless by default is fine. I agree with that 16:48:02 *GUI 16:48:15 and we test one combination that works reasonably well on all arches 16:48:16 sgallagh: The architecture difference isn't likely to be indicative of an use case difference going forward. 16:48:36 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 and that will be the one anaconda install when you select "add graphical interface" or whatever it will call it 16:48:53 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 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 Using non-GNOME would actually require us to get someone to test the non-GNOME desktop; is anybody doing it? 16:49:02 sgallagh: the workstation default will probably be overkill for the server anyway 16:49:04 or, yeah, just give you a laundry list. 16:49:12 mitr: we test KDE at present. 16:49:20 other desktops have no testing guarantee. 16:49:47 adamw: well we should not guarantee much on a server anyway 16:49:52 adamw: So KDE instead of XFCE? That's where I was going, but it would be kind of surprising :) 16:50:03 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 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 and actually ratpoison is a good choice. ;) many servers don't have mice attached.;) 16:50:05 adamw: only that you can login and run firefox/cockpit and a terminal 16:50:07 That will be best supported 16:50:12 (hell, we had a nasty bug with KDE for F21.) 16:50:56 gnome classic ? :) 16:51:06 simo: Still doesn't work on ARM 16:51:08 * adamw is fine with headless by default for F21 16:51:10 focus time 16:51:14 ok 16:51:23 I'm hoping that by F22, LLVMpipe will be in better shape 16:51:27 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 And we can just adopt GNOME or GNOME Classic for this 16:51:44 adamw: +1 16:51:47 adamw: +1 16:51:47 sgallagh: cpus won't magically become much more powerful :) 16:51:56 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 simo: No, but optimizations may 16:52:07 nope 16:52:12 but who cares 16:52:19 we are deferring apparently anwya 16:52:28 I think we have plenty on our plate for this release anyway. 16:52:55 As adamw says, we can advise them to do a yum groupinstall if they need a desktop 16:52:58 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 adamw: Is that an option, or would QA rebel at such an idea? 16:53:23 were we limiting the install choices in the server install? 16:53:45 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 sgallagh: I thought we'd limit variation in the default install, not prevent installing packages 16:54:11 That the install would be pretty much just the standard package set with the option to install some Roles 16:54:19 ok 16:54:38 Maybe we never touched on the standard package install piece. 16:54:56 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 and packages/groups not available in ks either? 16:55:10 that would make the server install media a lot less flexable. 16:55:14 nirik: Kickstart should have full control 16:55:36 simo: sure. 16:55:47 sgallagh: I do not see why we should remove option to add packages/groups at install time 16:56:00 sgallagh: we'd be very unhappy with the idea of undertaking that any desktops outside GNOME/KDE will *work* at all. 16:56:12 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 adamw: Ok 16:56:34 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 (but then, current Fedora does it, sooo....) 16:56:52 simo: me either. ;) Have our defaults, let folks go from there if they want to go off the tested path 16:56:53 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 andreasn_: I don't have anything further on it. 16:57:24 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 andreasn_: some people are not born on consoles, and they just prefer to do everything on the server including firefox/whatever 16:57:58 #topic Software Installation 16:58:24 simo, yeah. Ideally that can be done via the web admin ui (Cockpit) to cover that case 16:58:41 What about the case where we're on the offline install media? 16:58:51 (and sorry for repeating anything that's been said already), and also, oops, new topic 16:58:53 what about that > 16:58:53 In that case, there's not going to be access to any packages not part of the base or roles 16:59:04 sgallagh: another thing to ask anaconda folks. ;) 16:59:09 sgallagh: then too bad :) 16:59:27 Sure, I just wanted to note that. 16:59:31 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 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 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 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 If it can do that, it will display the appropriate choices. 17:00:54 poke me if there's a vote 17:01:03 adamw: I just submitted one above 17:01:05 sgallagh: right, I forgot about comps. 17:01:05 sgallagh: +1 17:01:06 I need to go as well 17:01:10 sgallagh: +1 17:01:28 Ya'll almost done? 17:01:32 * spot looks around 17:01:33 We'll finish this vote and resume tomorrow 17:01:40 abadger1999: Yeah, sorry. Ran a little over. 17:01:46 No worries. 17:01:47 * spot gets the broom 17:01:52 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 mitr: Let's leave that for tomorrow 17:02:26 sgallagh: I think we need to close shop anyway ? 17:02:36 spot: do you have a meeting her enow ? 17:02:37 Yeah, I was just hoping to get enough votes. 17:02:47 simo: yep. 17:02:49 ok 17:02:50 adamw: can you vote and we'll close out? 17:02:54 sgallagh: please close down 17:02:59 Ok 17:03:00 sure, one sec 17:03:23 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 #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 #endmeeting