15:00:20 #startmeeting Server SIG Weekly Meeting (2016-03-22) 15:00:20 Meeting started Tue Mar 22 15:00:20 2016 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:20 The meeting name has been set to 'server_sig_weekly_meeting_(2016-03-22)' 15:00:20 #meetingname ServerSIG 15:00:20 The meeting name has been set to 'serversig' 15:00:20 #chair sgallagh mizmo nirik stefw adamw simo danofsatx mhayden jds2001 15:00:20 #topic roll call 15:00:20 Current chairs: adamw danofsatx jds2001 mhayden mizmo nirik sgallagh simo stefw 15:00:28 .hello sgallagh 15:00:29 sgallagh: sgallagh 'Stephen Gallagher' 15:00:33 .hello jstanley 15:00:34 jds2001: jstanley 'Jon Stanley' 15:02:15 * nirik is double booked today, will try and pay attention, but we will see. 15:02:33 Well, so far it's not looking good for quorum. 15:03:05 .hello mizmo 15:03:06 mizmo: Sorry, but you don't exist 15:03:14 bleh 15:03:17 we're only 2 minutes in :) 15:03:19 .hello duffy 15:03:20 mizmo: duffy 'Máirín Duffy' 15:03:44 jds2001: Some part of me still expects people to be remotely on-time. I know I should know better by now 15:04:17 sorry i'm late :) 15:04:21 .hello adamwill 15:04:22 adamw: adamwill 'Adam Williamson' 15:04:52 OK, that's quorum at least 15:05:07 #topic Agenda 15:05:07 #info Agenda Topic: Default guided partitioning scheme 15:05:07 #info Agenda Topic: Fedora 24 Talking Points 15:05:07 #info Agenda Topic: Upcoming Open WG Seat 15:05:17 sgallagh: at my previous employer we had "goldman standard time" 15:05:26 it ran about 10 minutes behind local time :) 15:05:32 I'm home with a sick child today, so if I vanish temporarily, please be kind :) 15:06:06 Any other topics for the meeting this week? 15:06:32 .hello simo 15:06:33 simo: simo 'Simo Sorce' 15:07:07 OK. then let's proceed 15:07:14 #topic Default guided partitioning scheme 15:07:42 I sent this to the list after the meeting last week, but it really didn't get discussed. 15:09:06 #link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/D7ZK7SILYDYAATRFS6BFWZQWS6KSRGDG/ 15:09:12 ^^ is the current proposal 15:09:29 did you check with anaconda that this is technically feasible? 15:09:57 adamw: I didn't have to: it matches how the Atomic installer works. except with slightly different min/max numbers 15:10:05 OK 15:10:25 how's the Cockpit tooling for dealing with LVM? 15:11:29 adamw: It's functional for the "create new lv" and "extend existing lv+fs" cases 15:11:40 It couild maybe use some UX love, but it's functional 15:11:45 okay 15:12:12 sgallagh: can it create new lv+fs+mount that+put it in /etc/fstab? 15:12:20 since that's the real admin workflow. 15:12:20 i guess i'm fine with the change in principle, but i'd be worried about the possibility it gets thrown in then not messaged/documented very well 15:12:47 so if we're gonna do it i'd want there to be a solid plan for getting it properly promoted and documented 15:12:55 adamw: That's a fair point. If we make this change, we definitely need to advertise and document it 15:13:04 /me hands adamw a coke 15:14:13 sgallagh: how is swap calculated today ? 15:14:14 /me goes to check on the mount thing 15:14:25 I'm pretty sure it works. but I haven't tried it myself 15:14:28 for a laptop it makes sense to have swap == or bigger than RAM so you can do hybernate 15:14:31 simo: "magic" 15:14:39 but on a server a lot of swap is actually bad 15:14:48 i think it's something like 2x RAM up to a certain level, then 1.5x, then it's ceilinged somewhere 15:14:49 simo: Anaconda folks have a magic algorithm for determining swap usage 15:15:00 as your machine will grind for a lot longer before getting an OOM event on runaway services 15:15:06 It's the same algorithm used for RHEL systems 15:15:10 I always wanted to change it for the server edition 15:15:35 sgallagh: RHEL was insane for a time too :) 15:15:40 I actually had a conversation with the Anaconda folks about htis recently 15:15:40 but because the installer was the same for workstation and server I didn't propose 15:15:45 * jds2001 isnt sure of the current state 15:15:55 They don't like how the swap autogeneration works because it happens at an inopportune place 15:16:12 sgallagh: I plan to talk to a linuxVM kernel engineer I know to have his opinion on optimal swap size 15:16:15 Where it can only draw from space available when Anaconda starts (and nothing that is freed by the user as part of the install process) 15:17:20 we're kind of in the weeds here folks 15:17:25 We *do* have the option of modifying the swap defaults if we want to. 15:17:36 sgallagh: with your proposal if I have a 1TiB drive I get a 15GiB partition and then ~1TiB assigned to a volume group, not free but not allocated to a volume either 15:17:37 But I'd suggest that's a separate proposal 15:17:40 is that correct ? 15:17:55 simo: correct 15:18:02 simo: Not allocated to a logical volume, yes 15:18:04 simo: i have no idea what you might want to do with that. 15:18:13 why would we sequester the remaining space into a "default" VG ? 15:18:22 simo: make VM's maybe? 15:18:35 simo: make a filesystem? 15:18:41 simo: make 20 filesystems? 15:18:45 jds2001: you can do whatever, but I do not get why we "use" it intead of letting it be compeltely free space 15:18:52 jds2001: I think he's asking why it's in a VG instead of just Free 15:19:34 sgallagh: i thought we covered that last week :) 15:19:50 some of us may have not been paying attention 15:19:55 sorry must have missed the explanation then 15:20:10 simo: basically, that's an advanced use case 15:20:14 I was ok with not partitioning, given we have no idea what the user wants to do 15:20:26 simo: and there is still custom layout for that. 15:20:27 but I do not get why we want to put all free space into a VG 15:20:33 no sorry 15:20:45 having space you have to partition your self is *already* and advanced use case 15:21:01 joe random user doesn't even know what a partition is, let alone what LVM is 15:21:23 is server utilized by joe random user? 15:21:31 * jds2001 thinks not. 15:21:35 and lot of not so random users also do not really grok LVM 15:22:04 jds2001: you would be surprised, everyone starts somewhere before they become an admin :) 15:22:15 I am not saying we need to dumb down things 15:22:23 jds2001: my gut would say that most server users would understand the concept of a partition, perhaps portions of LVM 15:22:25 simo: Well, the reason for it is that we want to be able to enlarge / trivially 15:22:37 Without having to know much about partitions 15:22:43 but it sounds more friendly to mee if free space is actually free (as seen by parted) rather then sequestered into a limbo called "a default VG" 15:22:50 In that case, you just hit the "enlarge" button in Cockpit 15:22:56 sgallagh: you still can if the space if free 15:23:03 you can add PEs to a VG at any time 15:23:32 simo: Yes, but that's far more complicated to the end-user than just telling them they can do it with a slide-bar and a button 15:23:43 it's just a matter of making sure cockpit knows how to grow the VG itself if there is free space on disk 15:23:56 sgallagh: well the software should do that 15:24:12 i agree with simo that if the user's unused disk space appears in lvs/vgs, it could be confusing for beginners 15:24:23 simo: The other side of it is that if the space is available to a default VG, the "docker-storage-setup" will work properly and automatically 15:24:27 advanced users will choose to partition on their own and/or use kickstarts 15:24:56 sgallagh: mmm 15:25:01 Whereas right now, it basically just throws errors about not using non-LVM in production 15:25:03 mhayden: i think that the point here is making it so a lot of users dont have to do that 15:25:09 s/errors/warnings/ 15:26:30 there's obviously a lot of value in making it easy to do what the admin needs to do with nice simple tools. if we *have* to put the space in a VG to enable that i'd say let's do it 15:26:45 if we can make the tools work with unpartitioned space then that makes it more flexible for the pokemons 15:26:58 For the record, I just checked and confirmed that Cockpit can create and mount partitions (and modify fstab) 15:27:02 By way of storaged 15:27:09 adamw: +1 to what you said 15:27:25 OK, but today we have tools that only work for VGs 15:27:32 * jds2001 is +1 to adamw as well. 15:27:42 but at the same time, we have to deal with reality 15:27:51 sgallagh: when is this targeted? 25? 15:27:57 * jds2001 wants a unicorn 15:28:04 adamw: Also, dealing with free space is never really automatable 15:28:21 sgallagh: what makes that so? 15:28:34 Because it's basically impossible to know whether free space is persistent or transitory (like a USB drive) 15:28:44 Without a human's input, I mean 15:29:23 We can write heuristics which will be wrong often enough that it's a pain in the neck. 15:29:23 * jds2001 thought there was some way to tell if a device was removable 15:29:28 And then be forced to try t omaintain it 15:29:38 jds2001: That's just one example. 15:29:49 What if someone puts in an extra SSD and HDD? 15:29:53 Do we treat those the same? 15:30:26 That's the point at which manual intervention is the realistic expectation 15:30:27 agreed 15:30:36 but if i have one persistent disk, then it can be dealt with 15:30:39 So modifying cockpit to grab random free space to do enlargements would have a lot of consequences 15:30:44 welll that's a good q. for example by default should we use the SSD for the OS or not ? 15:30:47 anything further than that is again an advanced use case, i'd argue. 15:31:38 In the anaconda case, you have a simple choice: Select the disks that you want autopartitioned. 15:31:47 If you only suggest one, that's what you get and the rest is free 15:31:55 If you suggest multiple, they all become part of the VG. 15:31:59 * jds2001 suspects that the majority of server users would use hw raid, such that even if they have tons of physical disks, it appears to the OS as one. 15:32:11 That's probably *good enough* for that part of the process 15:32:12 * jds2001 could be wrong there. 15:32:45 jds2001: I never use HW raid, most consumer grade stuff is just a sham 15:33:00 simo: im used to working with enterprise stuff. 15:33:09 simo: so that's where my vision is skewed toward 15:33:29 Which is probably the better view for Server 15:33:32 yep, but fedora is used by a more diverse set of users 15:33:48 enterprise tend to use RHEL/CentOS on big iron 15:34:20 Fedora Server there is probably a lot more about testing next.gen stuff and installed virtualized or on lower pwer hw 15:34:21 Right, but let's also not forget our mission to be the upstream for those two 15:34:24 or maybe test hw 15:34:46 that too 15:36:51 ok so at least I go t my answer 15:37:12 simo: OK, so what are your feelings at this point? 15:37:16 I have no further objections for now, although I would prefer non-VG space if the tools were easy enough 15:37:33 adamw: To your earlier point, F24 Beta or F25 Alpha are both on the table. We hadn't decided yet. 15:37:50 Fair enough 15:37:56 * adamw would worry about trying to shoehorn it into f24. 15:38:19 That's fair, I'm not opposed to making it a Rawhide-only change. 15:39:53 OK, so let's take a vote on the proposal we have now, then discuss F24 vs F25 timeframe 15:40:26 Please vote +1 if you agree with the proposal sent to the list. 15:40:27 +1 15:40:31 +1 15:41:20 +1 15:42:05 simo, mizmo, mhayden? 15:42:38 * mizmo reads up (sorry in another meeting too) 15:44:09 have the anaconda folks weighed in on the proposed scheme at all? 15:44:53 mizmo: From a technical perspective, yes 15:45:04 It's technically feasible and matches what Atomic is doing. 15:45:13 sgallagh: what about the actual scheme tho 15:45:14 They haven't expressed a *recommendation* 15:45:17 ok 15:45:22 how is the proposal different than the current default 15:45:39 The current default is actually kind of Workstation-centric 15:45:56 Where it will use the first up to 50GiB for / and the remainder for /home 15:46:09 okay and this has a slimmer / 15:46:11 (Plus swap and /boot) 15:46:21 Right, and no separate /home 15:46:33 okay 15:46:38 have any sysadmins weighed in on this with an ok 15:46:42 Where the remaining space is left available 15:46:51 sgallagh: i'm +1 (sorry, in a VC meeting too) 15:46:52 mizmo: Does jds2001 count? :) 15:46:53 mizmo: do i count? :) 15:46:57 and mhayden 15:46:58 yes, are you down with it jds2001? 15:47:08 mizmo: yeah, makes life better 15:47:20 +1 then, although i'd like to do a survey for 25+ to refine it 15:47:34 mizmo: I'd be thrilled if you did 15:47:35 mizmo: makes sense. 15:47:51 * mizmo adds to todo list 15:47:58 * mizmo will work on that 15:48:29 #agreed Linked proposal is accepted. (+6, 0, -0) 15:48:53 OK, so the last remaining question on this point is if we want to make this change in F24 Beta or F25? 15:49:37 F25. 15:50:23 I'm abstaining for now unless I end up a swing vote. I don't mind either way. 15:51:08 * jds2001 is torn...i see adamw's concern, but we have the opportunity to get rid of the insanity in f24 15:51:24 the current scheme is just insane. 15:51:59 Yeah, I kind of wish this had come up two weeks ago, when we could have gotten it into Alpha 15:52:59 * jds2001 says f24 15:53:03 simo, mizmo, mhayden, nirik? 15:53:20 f24 - i want to get some feedback on it 15:53:23 sorry had to step out 15:53:26 * simo reads backlog 15:53:37 i'm okay with either, tbh 15:54:02 f24, I see no reason to delay 15:54:11 ...wait, we ship it in a production release in order to get feedback? 15:54:15 adamw: what is your concern ? 15:54:18 oooooo....kay? 15:54:26 mhayden: Well, since F25 is a given either way, does that mean "F24"? 15:54:39 as far as I can tell this has already been tested in the atomic stuff 15:54:49 so it is not like some ne concept from outer space 15:54:50 sgallagh: yes, i'm fine with F24 15:55:06 simo: well, one, we've now completely missed the alpha phase, so we get to deal with whatever teething problems this comes with at Beta or Final. two, we now have like two months to come up with a plan for documenting and communicating it instead of 8 months. 15:55:13 adamw: is atomic discounted as the testing ground ? 15:55:18 simo: it's not fully useful 15:55:26 why not ? 15:55:30 for a start, we haven't built any cloud atomic installer images for f24 yet 15:55:36 ahh 15:55:40 for a second, cloud atomic has a fixed size deployment 15:55:44 there are no packages, there is no package selection 15:55:49 sgallagh: unfortunately, i must depart -- in person meetings starting here :( 15:55:57 understood. Thanks for coming. 15:56:02 adamw: but partitioning scheme does not affect package installations 15:56:06 so any unfortunate interactions between, say, the 'is there enough space for this package based install' and a 15GB / have not been tested by atomic 15:56:09 adamw's point abot communication and documentation is a fair one 15:56:26 simo: there is code in anaconda to determine whether there is sufficient space for install 15:56:29 We probably do want to have the User Guide updated to make this clear 15:56:30 * nirik thinks f25+, but ok 15:56:35 adamw: the package set we're targeting is Server 15:56:43 adamw: not "choose your own adventure" 15:56:58 adamw: so we know what the size of that is and that it fits. 15:57:27 surely anaconda must test after partitioning scheme is fixed given users can use custom aprtitioning 15:57:28 if you choose to install every pacakge in the repos, 15GB may or may not be enough, dunno. 15:57:29 So I think I'm coming down slightly on the side of F25 as well unless someone here wants to volunteer to do the doc-writing 15:57:33 so I do not see it as a big risk 15:57:33 but that's that the point. 15:57:44 s/that/not 15:58:09 ok I am ok either way, but I think f24 would be fine 15:58:26 * jds2001 can write docs, depending on the deadline. 15:58:38 jds2001: Translation freeze would be the deadline 15:58:40 /me looks that up 15:59:26 Is the docs translation freeze the same as the software translation freeze? 16:00:37 Actually, https://fedorapeople.org/groups/schedule/f-24/f-24-docs-tasks.html suggests May 25th as the freeze for other docs 16:01:23 sgallagh: that's easy to accomplish 16:01:39 * jds2001 was wanting to make sure it wasn't like 2 weeks from now or something :) 16:01:58 Well, depends on whether we need something in relnotes too 16:02:11 That date would be April 11 16:03:20 * jds2001 thinks a quick relnote would be in order. 16:03:28 adamw: Would you be comfortable with F24 if jds2001 owns the doc updates? 16:03:51 jds2001: That was the Beta relnotes date, FWIW. But we'd want to do that, yes. 16:03:58 i still think it's unnecessary stress but i'm not gonna stop you all from trying. 16:04:37 OK, we'll see how it goes in Beta. It's easy to revert if we had to. 16:05:21 * jds2001 thinks this should be a talking point as well. 16:05:25 #agreed We will make this change for Fedora 24 Beta. (+5, 0, -2) 16:05:44 OK, I can't actually keep going today, but if others want to run the meeting I'll leave it open. 16:06:00 #action jds2001 to write release notes and update documentation to cover the change in defaults 16:06:07 we should a new F24 candidate build in a few hours, please help test it if you can. 16:06:15 (there should've been one right now only the compose just exploded) 16:06:33 ouch 16:07:48 I'll do a spot-check of the Server tests, but if anyone else can do a more thorough run-through, I'd appreciate it. 16:08:04 Most of my testing from the 1.6 build should carry over, since little changed. 16:08:07 * danofsatx is finally here 16:08:47 OK, does anyone want to take over the chair? 16:08:59 Or shall we call it a day? 16:09:06 * jds2001 should run 16:09:39 * jds2001 guesses call it a day 16:09:39 OK, doesn't sound like incredible interest in continuing. 16:09:44 thanks for coming, folks. 16:09:54 * danofsatx reads scrollback 16:10:04 #action sgallagh to prep the partitioning changes this week 16:10:10 #endmeeting