18:00:36 #startmeeting FESCO (2015-02-18) 18:00:36 Meeting started Wed Feb 18 18:00:36 2015 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:36 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:36 #meetingname fesco 18:00:36 The meeting name has been set to 'fesco' 18:00:36 #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh 18:00:36 Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza 18:00:37 #topic init process 18:00:46 good day. who is here? 18:00:46 good morning everyone. 18:00:52 .hello sgallagh 18:00:53 sgallagh: sgallagh 'Stephen Gallagher' 18:00:59 Hi all 18:01:42 i think mitr said he would not be here 18:01:43 .hellomynameis jzb 18:01:44 jzb: jzb 'Joe Brockmeier' 18:01:54 hi joe 18:02:04 * ajax waves 18:02:16 anyone seen dgilmore ? 18:02:18 "seen" 18:02:29 he was just around in fedora-releng. ;) 18:03:00 hi 18:03:07 ah, great. let's get started 18:03:14 #topic F22 System Wide Change: RpmOstree - Server side composes and 18:03:14 atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree 18:03:14 .fesco 1390 18:03:15 jwb: #1390 (F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree) – FESCo - https://fedorahosted.org/fesco/ticket/1390 18:03:16 https://fedorahosted.org/fesco/ticket/1390 18:03:47 walters: you around? 18:03:47 * dgilmore is behind on everything from the last couple of weeks still 18:03:47 OK. so based on my reading, this is simply a Change to highlight the underlying tooling Atomic uses 18:04:00 jzb, is my summary fairly accurate? 18:04:04 jwb: yeah. Thats my understanding as well. 18:04:23 jwb: seems reasonable 18:04:26 i am 18:04:44 i've made a few updates to the wiki pages 18:04:47 ah great 18:04:54 * dgilmore goes to read 18:05:06 walters, for RpmOstree, did i miss anything in my summary there that you think is worth pointing out? 18:06:06 I'm +1 to this as it's basically like all the other 'new version x.y.z' changes we have... More detailed docs would be nice. Whats changed ? what would people using it care about seeing in release notes, etc 18:06:17 nirik, same 18:06:20 walters: I think this is way too vague still. 18:06:36 dgilmore, how can I improve it? 18:06:47 dgilmore, i don't think this one is really that vague. it seems to be "new version of RpmOstree" 18:06:56 which is no differen than "new version of gcc" 18:07:04 there was no Change for it previously though 18:07:07 or gnome 3.16 or boost uplift, or... 18:07:14 walters: it only talks about what rpm-ostree is. 18:07:14 walters: what if any impact would it have on what we ship or any other products? 18:07:21 walters: the summary has Server side composes and atomic upgrades 18:07:37 there is nothing about that in there that I see 18:07:40 dgilmore, i think most of that is covered in teh AtomicHost Change 18:07:48 and we delivered an atomic tree in f22 18:08:04 hey, look. circle.s 18:08:09 jzb, I don't think much 18:08:23 walters: I think the change should be about how somoene would build a ostree and deploy it for themselves 18:08:31 gahh in f21 18:08:32 see paragraph 3 in summary 18:09:01 walters, jzb: i think it is fair to say if this Change page did not exist, RpmOstree would still ship, nothing else would be impacted, and nobody would notice. correct? 18:09:18 so the Change page itself seems to just be to highlight RpmOStree 18:09:43 jwb, well...if a component RPM changed in such a way to break it, I don't have a reference point to show if it's not a documented change 18:09:56 (this is not an abstract thing, current systemd git master broke ostree) 18:09:58 walters: good point 18:10:26 walters, so you believe the existence of the Change page will elevate the tooling to release blocker status? 18:10:55 * rishi is here 18:10:58 my goal isn't to block the release, merely to support the tooling 18:11:09 you are making this... difficult. 18:11:10 walters: which we are doing. 18:11:23 why did you file this Change? what is your goal with this one specifically? 18:11:46 walters: I think that using this change to highlight how people can build thier own trees is of imense benefit 18:12:11 1) so that other parts of fedora that interact with/depend on the tools would have a reference point for the effort 2) for what dgilmore just said 18:12:32 i'm lost as to what you mean by "reference point." 18:12:39 and that's why i added paragraph 3 in the summary 18:13:35 like an answer to "what is rpm-ostree and why do i care that my package foo broke it"? 18:13:59 yeah 18:14:34 ok. then i still have no problems with this Change page. it is essentially a documentation/awareness change 18:15:14 we're approaching 15min on this one, and i think the AtomicHost change is the larger discussion. shall we vote? 18:15:19 * nirik nods. 18:15:23 yes 18:15:27 yes 18:15:44 I'm still +1 as this is just a version thing. I'd like more docs/releasenotes blurbs if possible tho 18:15:53 proposal: Approve RpmOstree change 18:15:54 +1, same 18:15:54 +1 18:16:00 +1 18:16:01 jwb: +1 18:16:03 +1 18:16:08 * dgilmore is 0 18:16:38 rishi, ? 18:16:46 +1 18:17:01 I would like more documentation and clearer messaging 18:17:13 I was still reading the Wiki. Sorry for the delay. 18:17:28 #agreed Approve RpmOstree change (+1: 7, -1: 0, 0: 1) 18:17:49 #info Further documentation and release notes blurbs would be appreciated 18:17:55 ok, let's move on 18:18:03 #topic F22 System Wide Change: Atomic Host - 18:18:03 https://fedoraproject.org/wiki/Changes/AtomicHost 18:18:03 .fesco 1396 18:18:03 https://fedorahosted.org/fesco/ticket/1396 18:18:04 jwb: #1396 (F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost) – FESCo - https://fedorahosted.org/fesco/ticket/1396 18:18:20 ok. so somehow i missed that this one is proposing to create a new Product 18:18:23 note i did finally consolidate the bare metal/vagrant chanegs in here 18:18:38 yeah, I did too. 18:19:01 walters, are you intending AtomicHost to be a Product on the level of Cloud, Server, and Workstation? 18:19:11 jzb too. sorry 18:19:40 well 18:19:48 jwb: speaking just for me - not at this time, though I can see a point where we might explore building Server w/rpm-ostree 18:19:50 to be honest, i would like to write code 18:19:52 Or is this intended to consume Fedora Cloud? 18:20:03 what it's called and stuff, i mean... 18:20:17 basically if it stays in Fedora Cloud that's totally fine by me 18:20:25 walters, that would make things easier. 18:20:27 have the anaconda changes been written/landed? or just thought of? 18:20:38 nirik, almost a year ago now 18:20:43 ha. nice 18:20:44 essentially, you want to expand the scope of AtomicHost to beyond just the Cloud image 18:20:51 exactly 18:21:14 walters: So are you thinking of an Atomic Workstation? Or Server? 18:21:19 walters: has the anaconda support changed since f21? 18:21:27 dgilmore, GRUB2 18:21:28 Whether or not walters is, I think Workstation folks are thinking about it 18:21:34 walters: i.e. are you able to select a atomic tree in the gui? 18:21:36 stickster, not for F22 though 18:21:40 jwb: correct. 18:21:46 dgilmore, no...that would be really nice 18:21:48 stickster: Yes. :) 18:21:51 so, we would make atomic versions of all the products and ship them as images? or ? 18:21:53 walters: so the only difference is that grub2 and extlinux are suppoorted? 18:22:08 stickster: Which is why I asked walters 18:22:09 nirik: Not sure, but probably out of scope here if it's not F22 change related... still TBD 18:22:27 dgilmore, yes...though for the RpmOstree change I might want to add in ARM/other bootloaders into scope...it shouldn't be too hard 18:22:35 walters: my main question here is whats new from f21? other than talking it up more 18:22:54 walters: we really should support more than just x86_64 18:22:58 you raised that concern before, I answered "we promote it for bare metal, and grub2" 18:23:05 walters: but that is outside of this discussion 18:23:09 so I guess new is vagrant images and a pxe image? 18:23:16 nirik, and bare-metal? 18:23:27 my question is more _what_ is shipping for those? 18:23:29 jwb: bare metal with extlinux was supported in f21 18:23:31 so specifically for bare metal, the intention is the installer acts like the DVD, not boot.iso 18:23:32 well, thats been there, but we are just advertising it? 18:23:39 i.e. it embeds the content 18:23:57 walters: that requires a lot of changes in pungi to support 18:24:04 walters: I look forward to seeing patches 18:24:09 rpm-ostree-toolbox implements this now 18:24:11 there is no DVD... 18:24:15 * nirik is getting confused. :) Can someone enumerate what new image files this will entail shipping? 18:24:52 we have a Workstation Live image, a Cloud image, and a Server DVD. what will AtomicHost ship in/on/as? 18:24:56 walters: what exactly do you want to ship in Fedora 22? 18:25:13 jwb, dgilmore those were in other changes 18:25:25 jzb, what were in other changes? 18:25:33 dgilmore, the 3 things on the Change page plus the previous cloud images 18:25:36 in addition to qcow2 we want a bare metal installer and vagrant image 18:25:59 qcow2 and AMIs 18:26:02 walters: okay there is no mention of a dvd there 18:26:06 so ignore that 18:26:24 jzb, so you want an AtomicHost DVD iso 18:26:33 the new things is that grub2 is supported in addition to the extlinux support from f21 18:26:33 no 18:26:44 the vagrant image 18:26:47 jwb: well it should be smaller than CD sized... 18:26:52 the host content fits into a CDROM, and does not support software collection 18:26:52 er DVD sized, but yet 18:26:54 yes 18:27:02 s/collection/choice/ 18:27:17 so you want an AtomicHost iso. 18:27:27 conceptually it's like http://wiki.centos.org/Manuals/ReleaseNotes/CentOSMinimalCD6.5 18:27:30 jwb: yes 18:27:38 which neither Fedora nor RHEL have, but ^ is very popular 18:28:09 because it gives you an all-in-one that is useful to install servers without dragging down gigs of multiple desktops, developer tools etc 18:28:19 assmuing such an iso is created, a person would use it to install e.g. a bare-metal machine in the Atomic model. then they would use ... something we already produce to get updates via atomic? 18:28:35 right, they get updates from a tree 18:28:50 and those trees are already generated and provided by fedora infrastructure 18:28:51 that seems much like boot.iso... but I guess has a bit more? 18:29:06 nirik, boot.iso requires downloading packages from network. 18:29:32 nirik, i think it seems more like splatting e.g. a live image to disk 18:29:33 sure... 18:29:41 jwb, no, it's like a small DVD 18:30:22 * jwb scrolls back 18:30:34 ok, so we would need pungi to create this based on a ks right? 18:30:34 coreos actually is always boot-to-live, and their installer is a shell script 18:30:51 well, we've been using rpm-ostree-toolbox 18:30:55 but ultimately both call into lorax 18:31:29 stop 18:31:35 ignore low level details just for one second 18:31:57 you want an iso. the iso is used to install bare-metal. it does so by splatting an atomic tree onto a disk. 18:32:16 so how in that model is it like a DVD? does the iso contain multiple trees a user can choose from? 18:32:32 it's like a DVD in that it does not require a network 18:32:39 neither does a live install 18:32:58 so when you say it's like a DVD, you're confusing me 18:32:59 that happens to be true, sure 18:33:13 it's like a dvd in that it boots to anaconda and has no live env right? 18:33:21 personally I try to avoid using media terminology 18:33:25 well, like the old no longer made fedora install dvd. 18:33:32 i think of boot.iso and the install DVD as boot-to-anaconda 18:33:42 so that's one axis 18:33:56 walters: maybe this would be easier: aren't you already generating what we want from Rawhide? 18:33:56 then the second is whether or not content is embedded 18:33:56 walters: That's great, but work with it for the sake of understanding :-) 18:34:03 walters: this is a matter of making it official 18:34:12 and come out of the build system instead of self-generated 18:34:21 So this could just as well be an image like our Live images, only the image is an Atomic Host, provided Anaconda knows how to deal with it (or perhaps doesn't matter if image content is irrelevant at that level) 18:34:36 can you install a non atomic host with this iso? 18:34:43 jzb, all of the tools to generate it are packaged yes 18:34:45 nirik, at the moment i'm assuming no 18:34:57 walters: its an install media that the payload is an atomic tree and not rpms to be installed? 18:34:58 mmm...not easily 18:35:07 walters: right, but also - isn't the ISO you've been doing pretty much the model of what we want here? 18:35:11 dgilmore, that is my understanding 18:35:22 dgilmore, exactly. (However, with more rpm-ostree changes we could support per-client trees, but it's nontrivial) 18:35:36 ok. 18:35:38 walters: thats ouside of the scope for this discussion 18:35:47 jzb, yes. 18:36:19 ok, so let me summarize 18:36:26 the Change proposes to: 18:36:35 walters: I will have to spend some time with you to see how you are producing what you are and figure out how to tie that into our compose process 18:36:56 1) create an iso that can be used to install an atomic tree on e.g. bare metal. the iso contains the tree in the image. 18:37:08 2) create similar qcow2 and AMIs 18:37:21 dgilmore, definitely, would be great. (Ultimately it's a pretty thin lorax wrapper but there are some details) 18:37:39 3) create a different minimal image for PXE usage 18:37:46 is all of that correct? 18:37:48 jwb: I think you just paraphrased the proposal itself 18:37:49 ;) 18:37:53 jwb: + vagrant 18:37:57 jwb: you missed the vagrant image 18:38:04 right 18:38:07 thozza, well, 1 is a hell of a lot more detailed than the first bullet 18:38:24 I would elaborate more on 3) though because there are two types of PXE 18:38:25 jwb: ok, I agree 18:38:29 it is more clear 18:38:38 which is entirely what we are after here. clarity 18:38:45 sure 18:38:47 when most of the people in the Fedora+derivatives world talk about PXE they're talking about PXE-to-Anaconda 18:38:53 take my note as an ACK ;) 18:38:56 where #3 is PXE-to-Live 18:39:10 which is building on livemedia-creator work from the anaconda guys 18:39:13 and tooling exists to create all of the image types? 18:39:18 yes 18:39:23 jwb: not that we can use 18:39:32 dgilmore, that was not my question. 18:39:36 one step at a time 18:39:40 I have on my todo list to integrate livemedia into koji 18:40:06 is the content of the install iso the same as the vagrant images? or ? 18:40:15 nirik, yep, there's just one tree 18:40:16 nirik, that was my next question 18:40:41 now this is an issue, as it means e.g. the cloud image carries linux-firmware. But...we can revisit multiple trees at some later point 18:40:45 walters: PXE to live is just the same as people that pxe boot for teh rootfs right 18:40:49 and the anaconda changes already landed 18:40:50 ok, so 6 images per arch? 18:41:06 where you load a kernel and initramfs and use a network based filesystem 18:41:14 nirik: its all x86_64 only 18:41:53 install.iso, install.qcow2, install.ami, vagrant.vbox, vagrant.libvirt, minimal-pxe 18:41:55 ok. 18:41:58 nirik, ah...i'm only counting 5: ISO, vagrant-libvirt, vagrant-virtualbox, pxe-to-live, qcow2 (right?) 18:42:08 walters, jzb: so what is missing right now that prevents the install iso from being created? 18:42:18 i hadn't counted AMI as one would expect that to be in Amazon 18:42:26 walters: sure, true. 18:42:41 jwb: I don't think Koji has the tools to create the ISO from ostree trees. 18:42:56 walters: But might need some changes from our fedimg/push-to-cloud tools... /me looks to oddshocks 18:42:57 jwb, rel-eng integration 18:43:00 jzb, but we create the ostrees right? 18:43:17 jwb: from the rel-eng side all of this is new and needs investigation to see what it will take 18:43:33 we have the os tree we make today 18:43:48 dgilmore, stickster: and to my understanding, we are looking at options from a people perspective to help this along, correct? 18:43:57 we have tooling to make vagrant images, but have not yet done so 18:44:13 we do not have the other tooling mentioned in a state to use 18:44:22 jwb: Correct, I would like to see the "rel-eng integration" thing spelled out so we know whether there are immediate things that need done apart from re-architecting for Glorious Future 18:44:29 jwb: I don't think he's online right now, but I believe imcleod will be able to lend a hand in the short term as well. 18:44:32 stickster: ^^ 18:44:44 jzb: Sure, much appreciated. It shouldn't be a one-man show. 18:45:02 i have another question still, but does anyone in FESCo or otherwise feel this is do-able in the F22 timeframe? 18:45:08 jwb: we are looking at lots of things going forward and pulling in all resources we can, but it is not a magic bullet 18:45:20 dgilmore, there are no magic bullets. 18:45:21 jwb: And just to further clarify, we are hiring someone to help with this stuff. But I don't like the idea of saying "stuff" without more SME input on what that stuff is' 18:45:29 SME? 18:45:33 STOP USING ACRONYMS 18:45:34 subject matter expert 18:45:36 ILA 18:45:40 SUA 18:45:43 FUCK 18:45:47 heh 18:45:51 jwb: I'm not familiar with that one 18:45:52 (that's an acronym) 18:45:52 :-O 18:46:02 Such Undeniable Awesomeness. 18:46:05 based on this I am +1. 18:46:16 nirik, based on what? for F22? 18:46:26 i've yet to see anyone say we can actually contain the rel-eng side in F22 18:46:26 I'd like to see the change page tweaked. I'd even do it if folks wanted. 18:46:32 jwb: Back on topic, my point is that I would like to have a better understanding of what needs to be done in rel-eng tooling to support each of the items nirik (or walters, take your pick) enumerated above 18:46:42 i mean, this all sounds excellent but what exactly are we approving here 18:46:48 jwb: from my perspective the vagrant image is doable as is the existing cloud/qemu/kvm images. 18:46:57 jwb: well, if those things are not done, we hit the change point and punt to next release. 18:47:07 nirik, that's like next week 18:47:12 but the installer iso and the pxe bits I am much less sure of until I look into it 18:47:39 let me take a step back 18:47:57 does anyone have issues with Fedora producing the requested trees/images in general? 18:48:08 i certainly would like to see this. it would make Atomic much more consumable 18:48:09 jwb: no 18:48:09 i do not 18:48:11 yeah, time flies doesn't it. ;) 18:48:40 I don't have any issues with this as a goal, you are right that it's not too likely by next tuesday 18:48:46 ok, sounds like we're generally in agreement on the overall goal. so now it comes down to timeframe and feasibility 18:48:52 jwb: No. 18:48:55 jwb: fedora producing them I have no issues 18:48:57 I would like to see this happen too. 18:49:03 no 18:49:10 I think that the contingency plan is for the situation when the owners/rel-eng realize that something is not doable in F22 time frame 18:49:16 But I don't think my voting +1 will automatically make this happen. 18:49:37 jzb, walters: if the bare-metal iso isn't produced for F22 and we get just vagrant + cloud, is that acceptable? 18:49:55 jwb: well, I guess it'd have to be :-) 18:49:56 stickster, it's hard to summarize in the space provided by this GtkEntry in my irc client...probably best on a mailing list? 18:50:12 jwb: I'm really hoping we can accomplish that, though 18:50:19 walters: Yeah, understood, so long as you can actually enumerate somewhere 18:50:45 jwb, i guess...i'd probably end up making them on alt.fp.org 18:50:46 jzb, from a process standpoint, unless it can be done after next week without impacting the release otherwise, then i don't see it happening for f22 18:51:06 (Also, I know I'm not FESCo and hope not to be polluting this meeting. OTOH I have a new team person landing in this particular "hot zone" so I'd like to understand it.) :-) 18:51:21 if the tooling integration _can_ land just whenever and it doesn't impact the release, then great 18:51:41 * nirik notes we could be adding that to f23/rawhide now too. 18:51:46 yes 18:51:53 279502 18:51:56 ok, so here is what i propose 18:52:04 jwb: It seems to me that if the contingency plan is simply "fine, don't have it done," the strict Alpha checkpoint may not be so sensible 18:52:05 * dgilmore notes we are just starting on major tooling changes for f23 18:52:31 proposal: FESCo tentatively approves the AtomicHost Change. nirik will work with walters and jzb to clarify things on the Change page 18:52:38 +1 18:52:54 (because you volunteered nirik) 18:52:54 sure, +1. 18:53:00 jwb: +1 for it 18:53:08 proposal looks good +1 18:53:15 i'm +1 18:53:15 jwb: I guess by "tentatively" you mean if there are people to do the work. 18:53:29 Where "people" is basically nirik at the moment. 18:53:29 rishi, meaning we're realistic and realize not all of it may land in F22 18:53:35 *nod* 18:53:37 +1 18:53:50 people includes walters, jzb, dgilmore, etc 18:53:56 nirik is helping on the documentation front :) 18:54:08 ajax, ? 18:54:25 +1 18:54:27 jwb: Right 18:54:29 sorry, multiple windows 18:54:32 sgallagh, ? 18:55:17 nirik: Feel free to rope me into the conversation as appropriate. 18:55:33 #agreed FESCo tentatively approves the AtomicHost Change. nirik will work with walters and jzb to clarify things on the Change page (+1: 7, -1: 0, 0:0) 18:55:34 jwb: Sorry, multi-tasking. +1 18:55:38 #undo 18:55:38 Removing item from minutes: AGREED by jwb at 18:55:33 : FESCo tentatively approves the AtomicHost Change. nirik will work with walters and jzb to clarify things on the Change page (+1: 7, -1: 0, 0:0) 18:55:41 (and a quick check, this all stays under Cloud?) 18:55:43 #agreed FESCo tentatively approves the AtomicHost Change. nirik will work with walters and jzb to clarify things on the Change page (+1: 8, -1: 0, 0:0) 18:55:48 walters, i think at this piont, yes 18:55:53 ok, cool by me 18:55:55 it's not ready to be a separate product yet 18:56:01 walters: I'm pretty sure the Council has to approve any new Products anyway 18:56:09 yes 18:56:25 #info AtomicHost stays under Cloud for the time being. 18:56:43 ok thanks everyone for hanging in there while we work through this 18:56:46 let's move on 18:56:55 #topic F21 privacy issue, Geolocation done for every install 18:56:55 .fesco 1411 18:56:56 https://fedorahosted.org/fesco/ticket/1411 18:56:57 jwb: #1411 (F21 privacy issue, Geolocation done for every install) – FESCo - https://fedorahosted.org/fesco/ticket/1411 18:57:21 i'm not seeing an issue here 18:58:06 * dgilmore doesnt see an issue here 18:58:24 I think it gives us less infmation than we can get from mirrormanager hits 18:58:46 mm gives us arch and release of the install 18:58:49 you have the option of not using mirrormanager, if you do an otherwise not-network install 18:58:53 I think we should document this somewhere/somehow for concerened users... but otherwise. 18:59:12 ajax: you have the option to not use this also 18:59:28 dgilmore: You mean via the boot option? 18:59:39 yeah, kcmdline isn't what i call obvious 18:59:47 Proposal: Make sure that the kernel boot option is listed on a wiki page somewhere and otherwise do nothing. 18:59:49 i'm not going to make a proposal on this one. someone else dig in :) 18:59:56 rishi: that or you do the install dvd with no network 19:00:06 sgallagh: well, it's on the anaconda boot options page I think. ;) 19:00:47 do we have a place to centrally list these kinds of things? 19:01:36 ajax: doubtful 19:01:38 not sure. I guess we could make a wiki page with GeoLoc or something ? 19:01:50 but people would have to know to look for it. 19:01:57 i mean, yes, they would 19:01:59 https://fedoraproject.org/wiki/Anaconda_Boot_Options#geoloc 19:02:34 i mean more in the "this is the kind of data that otherwise mundane interaction with fedora might expose about you" sense 19:02:53 ajax: Isn't that basically what a privacy policy would say? 19:02:57 Ultimately I suppose we should have a Fedora distribution privacy policy… but we have little chance of keeping it comprehensive and accurate. 19:03:25 mitr, that's also not really something i think FESCo should do 19:03:37 rishi: there's a gap between what fedora would do with that data, and what a mitm could discover 19:03:45 We asked Legal about that and got a response that said that the privacy policy didn't need updating for this. 19:03:50 That's about as official as it gets 19:03:51 rishi: the former is a "privacy policy" 19:03:56 I guess I am +1 to sgallagh's proposal. I might make a Geolocation wiki page explaining our setup in fedora infra... 19:04:21 sgallagh: OK, +1 19:04:47 ajax: But there should be something that says these are things that Fedora might expose on the network. 19:05:17 rishi, that isn't scalable 19:05:22 +1 sgallagh i suppose. i'd like something more comprehensive but i sure ain't volunteering 19:05:31 +1 sgallagh 19:05:32 and it's _such_ a rathole 19:06:02 we have 5 votes if sgallagh is for his own proposal 19:06:09 sgallagh: +1 19:06:09 jwb: +1, for the record 19:06:19 i adore the idea of a linux that gets opsec paranoia right, but it's not really a product goal atm 19:06:35 anyone else wish to vote? dgilmore ? 19:06:37 +1 19:06:39 +1 19:06:56 +1 to sgallaghś proposal 19:07:19 ajax: Isn't that pretty much what Tails is for? 19:07:23 ajax: A really paranoid user would probably not use a netowkr in the first place. 19:07:26 So that there is too. 19:07:39 #agreed Make sure that the kernel boot option is listed on a wiki page somewhere and otherwise do nothing. (+1:9, -1:0, 0:0) 19:07:47 lets move on 19:07:58 #topic anaconda password change is causing consternation among the 19:07:58 user community please review this policy decision 19:07:58 .fesco 1412 19:07:59 https://fedorahosted.org/fesco/ticket/1412 19:07:59 jwb: #1412 (anaconda password change is causing consternation among the user community please review this policy decision) – FESCo - https://fedorahosted.org/fesco/ticket/1412 19:08:23 sgallagh: right. 19:08:43 oh good this ticket 19:08:43 dcantrell posted a summary of what i understand is the anaconda team's view on this 19:09:11 we have 3 choices that i can see 19:09:13 * nirik is still somewhat baffled that this has caused such torment. 19:09:18 1) revert the change 19:09:25 correction 19:09:30 1) ask the anaconda team to revert the change 19:09:31 well, ask anaconda developers nicely to revert 19:09:49 2) ask the anaconda team to work with the WGs on a per-product policy setup 19:09:53 3) do nothing 19:10:10 a variant of 1 would be to carry a revert patch in the SRPM, but that gets... weird 19:10:26 so, here's my thing with this 19:10:29 in the Workstation WG meeting, they expressed a strong desire for solution 2 19:10:30 4) Make a wider statement on standardizing password policy across the distro at some level (not necessarily the current one) 19:10:41 do we have any product that actively does not want pwquality checks 19:10:49 sgallagh, that can be done in all cases. it isn't a solution 19:10:56 ajax, Workstation 19:10:58 ajax: workstation 19:11:08 uhhh 19:11:25 this change was a decision by anaconda 19:11:34 they really want the check disabled because ssh is not enabled by default 19:11:35 Also, QA is unhappy with the change, since they have a lot of really simple default passwords in their test plans 19:11:38 I think the security should not be forced in such a way to users, disrupting their habits 19:11:44 how are you getting that impression, given (say) comment 23 in that ticket? 19:11:47 it wasn't due to something FESCo said should be done 19:11:48 sgallagh: /qa/some qa folks/ 19:12:02 ajax: Which impression? 19:12:15 rishi: the impression that workstation doesn't want this 19:12:17 I won't say that Workstation doesn't want the checks at all. It doesn't want to hard enforce the checks. 19:12:24 thozza: I do not see that as an issue. websites enfore so many different policies 19:12:33 ajax, uh... i asked the WG this morning and they said they want solution 2 where it's per-product tunable so they can turn it off 19:12:40 ajax: The fact that it reverted a similar thing in gnome-initial-setup some time ago. 19:12:41 ajax, cantanzaro is not in the WG 19:12:49 well okay fine 19:12:54 i'm not just pulling this out of my ass here... 19:13:01 as someone who cares more about workstation than anything else, i think they're wrong 19:13:07 dgilmore: sure, but was the double click really not sufficient? or some warning 19:13:08 but i'm not going to fight that here 19:13:33 If I want to shoot myself into foot, I want to be allowed to 19:13:33 ajax: Why do you think it is wrong? Honest question. 19:14:05 Speaking as a person who has done a lot of security work, I'm not really happy with the current requirement. It's enforcing complicated passwords instead of strong passwords. 19:14:20 I'm not saying we should happily accept weak passwords, but forcing in such a way is not the best approach in my opinion 19:14:37 * dgilmore thinks that as workstation is the ones that want a change, and the new policy was a decision of teh anaconda team that the two of them should work together to find a solution. if they can't then FESCo can intervene 19:14:43 rishi: like i said, not here 19:14:55 so, perhaps the way to attack this would be to try and improve libpwquality 19:15:01 dgilmore: I thought that they asked us to intervene... 19:15:22 sgallagh: Somehow I managed to use passwords that are easy to remember and makes libpwquality happy. 19:15:26 sgallagh: no, it seems to be a user 19:15:43 sgallagh: based on a thread in a forum 19:15:47 Sadly I can't tell the world how I did that. 19:15:50 it's not hard. 19:16:10 rishi: Of course it can be done, but it's usually non-obvious. 19:17:02 so, okay, two: anaconda ignores unknown kickstart options, right? 19:17:02 Anyway, I'm also of the opinion that just requiring an "are you really sure?" second click is probably good enough here. 19:17:15 sgallagh, so a revert 19:17:35 jwb: let me phrase it better. 19:17:42 sgallagh: Wasn't it done for Server in the first place? 19:18:05 Proposal: Revert to the confirmation click in F22, ask for improvements to libpwquality in F23 to make the change less painful. 19:18:09 rishi: We didn't ask for it. 19:18:16 i want to be completely clear here: i think fesco asking for a revert is a very very very bad move. 19:18:23 Most of our installs are done by kickstart, which was unexpected. 19:18:33 ajax, as do i 19:18:42 and not because i think the strong password checks are entirely unobjectionable, though that happens to be true 19:18:43 sgallagh: ks hasn't changed? 19:18:52 nirik: No, ks can do as it pleases. 19:18:56 right 19:19:05 Hi, I'm not on the workstation WG and wasn't at the meeting. But I read the meeting log and another item that was discussed was that we don't really need anaconda creating user accounts for Workstation at all, that's a job for g-i-s. That would sidestep the problem nicely, but obviously requires product-specific configuration. 19:19:15 Re: libpwquality improvements - people have suggested that it is not an exact science. So not sure what to expect. 19:19:23 mcatanzaro, sigh. please one issue at a time 19:19:29 we aren't here to discuss that right now 19:20:15 jwb: OK :) Re libpwquality: we could use it and still enforce checks if the scale was different. Right now it rates relatively strong passwords as 0, that is the problem. 19:20:15 /me rereads above and realizes he typed "which was unexpected" when he meant to say "which was unaffected..." 19:20:32 mcatanzaro: have bugs been filed? 19:21:32 dcantrell just left a comment in the ticket. he is requesting that FESCo come up with a guiding principle on password quality enforcement 19:21:40 https://fedorahosted.org/fesco/ticket/1412#comment:16 - does this mean that pwquality folks don't like this either. 19:21:41 (that's a paraphrase. see his comment) 19:21:49 nirik: Not sure. Anyway if products could choose their own quality level, and we could get a *dramatically* lower strictness to reach quality 1, then we'd be good.... 19:22:18 so it sounds like there are avenues available to address this short of outright revert 19:22:47 I think we can work with the pwquality folks. Our concern as I interpret it is that the anaconda devs seem to want a one-size-fits-all for all products. 19:23:00 they kind of do, yes 19:23:08 mcatanzaro: well, I guess. I am not sure I agree with setting a lower quality, but I guess it's not my call. 19:23:14 What was wrong with the previous way of enforcing strong passwords by double acking it? 19:23:24 ajax: What avenues? Prod-specific tweaks? 19:23:31 the change came about because of the proposal to disable root logins via ssh. https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00043.html is where what is implemented was raised 19:23:35 thozza: Probably that we were just training people to do so 19:24:12 rishi: clearly there's a difference in the necessary password strength for a throwaway vm than for a laptop that might get stolen, so, at least that yes. 19:24:13 sgallagh: but it was the user's choice 19:24:52 ajax: My understanding is that it needs support from Anaconda. 19:25:12 rishi: yeah, it would! 19:25:17 See: http://pkgs.fedoraproject.org/cgit/fedora-productimg-workstation.git/tree/fedora-workstation.py 19:25:24 rishi: and the people doing those products would have to actually interact with anaconda 19:25:28 you know 19:25:30 get a patch in 19:25:33 they've started 19:25:38 wunderbar 19:25:48 ajax: See the URL. :) 19:26:05 ajax, so i think you're proposing to push the work to the WGs? 19:26:15 which is option 2 19:26:22 which requires some amount of complicity from anaconda 19:26:22 jwb: Well, not entirely. 19:26:43 Because the Anaconda team will need to maintain 2 code paths. 19:26:48 jwb: i think we should set the precedent that escalation to fesco is a thing you do when normal polite interaction with the ecosystem has failed 19:27:02 and not just because waaah my choice 19:27:10 That I totally agree with, ajax 19:27:12 I think the anaconda team should reconsider their approach completely 19:27:39 ajax, so your proposal is do nothing :) 19:28:15 Mine would be "gently nudge". 19:29:10 jwb: more like "gently nudge and table until/unless necessary" (thank you rishi) 19:29:11 we're already at 20min on this one 19:29:16 so any proposala? 19:29:22 *s 19:29:29 or voting 19:29:29 * nirik is trying to think up one around helping libpwquality improve... 19:29:31 ajax: Although I don't think FESCo has worked like that in the past. 19:29:42 rishi: be the change, yo 19:29:49 eg., that systemd change 19:29:53 the problem is that will not placate the qa folks who object or workstation I suppose. 19:30:15 Where we basically became referees between 2 sets of developers. 19:30:22 nirik: right 19:30:23 Anyway... 19:30:29 i'm pretty sure it's not our job to make people feel warm and fuzzy 19:30:43 nirik: and afaik its only a small subset of QA that has raised objections 19:30:46 ajax: So what are we doing now? 19:31:03 proposal: ask interested parties to work with libpwquality folks to improve tests. 19:31:03 babysitting 19:31:05 Anyway... 19:31:25 nirik: I think there are two things 1. how to enforce strong passwords and 2. how to check the password strength. 19:31:32 nirik: Did you see the comment from tmraz? 19:31:34 and 1. is more of a problem 19:31:49 https://fedorahosted.org/fesco/ticket/1412#comment:16 19:32:10 I doubt "improve pwquality" is the answer. 19:32:11 really it comes down to this ticket was filed by a user based on a whinge session in a forum, after anaconda decided to change the password policies in the installer. with workstation chiming in and saying they dont want the password policy applied to them. 19:32:17 we have two choices. 19:32:19 FYI the next comments in that ticket show I was wrong in comment #16. 19:32:20 do nothing 19:32:53 dgilmore: There were some threads on Fedora MLs. 19:32:55 rishi: yes, I did. I guess it's not clear to me that he intends to not change anything or not 19:32:55 or sit down and write a policy that says what the minimum password requirements are for Fedora the OS 19:33:02 rishi: sure 19:33:40 if we write a policy on minimum password requirements we would need to make sure the defaults matched that in anaconda, pam, etc 19:33:42 how about we ask anaconda folks to s/password/passphrase/ :) 19:33:54 nirik: I saw people mention that it is not an exact science. So, I don't know. I am not an expert on libpwquality. 19:34:22 I think we are going in circles here 19:34:27 agreed 19:34:28 thozza: I think so 19:34:37 Because why would you want a passphrase for a local password? workstation != server, products are different.... 19:34:38 well, me either, but I have heard several people say they picked something that should be strong, but it wasn't scored as they expected. I don't know if this is a bug in libpwquality or how anaconda uses it or what... but that sounds like a bug. 19:35:16 mcatanzaro: because a passphrase makes you realize it can be a long thing you can easily remember. So you don't get in bad habbits about other accounts. 19:35:54 proposal, FESCo to come up with a policy on the minimum default password requirements for Fedora the OS. (which users would be free to override) 19:35:57 the reason we are going in circles is because none of the proposals marry any of the competing view points 19:36:00 https://lists.fedoraproject.org/pipermail/test/2015-February/125074.html 19:36:05 % echo "a nice shot of whiskey please" | pwscore 19:36:05 100 19:36:17 don't tempt me 19:36:30 mcatanzaro: right, that sounds really a lot like a bug... 19:37:00 I think we should at least ask anaconda devels to consider some user input on the change and not treat it as the unquestionable solution 19:37:11 Just let the products do whatever they want? 19:37:19 thozza, i'm fairly sure they've considered it. 19:37:27 thozza: I think most of their resistance to changing is that some of the user input has been very hostile 19:37:40 like closing those bugzillas as NOTABUG in every second comment? 19:37:46 it's hard to want to give in to someone yelling in your face and shouting 19:37:55 proposal: defer 19:38:00 we aren't making progress here 19:38:05 * nirik nods. +1 19:38:08 jwb: I think we have no better solution now 19:38:12 jwb: +1 19:38:16 i think there IS no better solution 19:38:17 jwb: +1 19:38:20 i would like to revisit this once existing known bugs are addressed 19:38:28 ajax, fair. i'll info that 19:38:34 Proposal: everyone gets assigned the password "correct horse battery staple". Should be secure enough for anyone. 19:38:36 that might be tenable if someone filed them (which I don't think they did) 19:38:42 otherwise +1 jwb 19:38:50 #agreed FESCo defers on this 19:39:05 (Obviously, that was not a serious proposal) 19:39:18 #info People seeing issue with seemingly strong passwords should file bugs. FESCo will revisit when all know bugs are resolved 19:39:29 moving on 19:39:39 well, all known bugs could be... forever... 19:39:40 nirik: i'm willing to treat mailing list posts as proto-bugs for the purpose of this particular spat ;) 19:39:49 #topic F22 System Wide Change: Systemd Package Split - 19:39:49 https://fedoraproject.org/wiki/Changes/SystemdPackageSplit 19:39:49 .fesco 1406 19:39:50 https://fedorahosted.org/fesco/ticket/1406 19:39:51 jwb: #1406 (F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit) – FESCo - https://fedorahosted.org/fesco/ticket/1406 19:39:51 ajax: fair enough 19:40:24 this again? 19:40:31 :) 19:40:34 * rishi looks at ajax 19:40:38 ajax, we did not have consensus or quorum last week 19:40:46 Proposal: The systemd package maintainer knows the package best. Trust this. 19:41:03 sgallagh, taht is a terrible proposal because there are 3 of them and they disagree 19:41:11 ah yeah, just now found last weeks minutes 19:41:13 Why can't the systemd guys figure it out themselves? 19:41:19 I talked to systemd maintainers/upstream and they don't think this is a good idea either 19:41:20 jwb: Do they? I thought it was a downstream vs. upstream disagreement 19:41:26 msekleta: and lnykryn 19:41:27 So, I am still at 0... +1 because I don't want to override a packager on their package. -1 because it seems like a lot of work for little gain and upstream is against it... let me see if I can tip that one way or another. 19:41:37 sgallagh, lennart and kay are both upstream and in the team that deals with the fedora package 19:41:45 true. 19:41:58 sgallagh, if you meant zbyszek_afk alone, then say so 19:42:10 the ticket has some sizes that would be saved 19:42:14 I am still -1. 19:42:24 jwb: Last I spoke to them, they didn't *want* to be doing that and were happy that zbyszek was taking it off their hands :-/ 19:42:25 the proposal was intended to package unused tools and daemons in separate subpackage 19:42:51 (This was in Brno a couple weeks ago) 19:42:58 sgallagh, i don't want to be sitting in this damn meeting anymore. but i am, and you're arguing for an ambiguous proposal 19:43:01 sgallagh: Lennart and Kay clearly said "no" on the ML. 19:43:22 thozza: more used you mean? 19:43:22 I am against the split, speaking from position of RHEL systemd maintainer 19:43:40 nirik: like systemd-networkd/resolved and so on 19:43:47 anyhow, I guess I will tip -1 here. The savings aren't worth it. 19:43:49 i still have real difficulty understanding how 30M of buildroot space is such a big deal 19:43:49 but then they realized they don't want that 19:43:58 so systemd-units is what was left 19:43:59 -1 19:44:31 we're at -3 19:44:36 i am -1 to the split 19:44:48 also shipping a binary (systemctl) in a different package, although it requires the daemon for most commands does not make sense for systemd guys 19:44:59 ajax, are you -1? 19:45:02 so therefore I'm also -1 19:45:10 yeah, -1 19:45:11 I'd really rather that the maintainers decide this. If they're incapable of agreeing, I guess I'm -1 19:45:19 that's -6. 19:45:29 i don't love the -1 but at least as proposed i'm not thrilled 19:45:49 #agreed FESCo denies this Change request (+1:1, -1:6, 0:0) 19:45:58 and i have to believe there exists a comparably effective and less contentious solution 19:45:59 #topic Open Floor 19:46:02 sgallagh, pretty much all other maintainers other than zbyszek are against the split 19:46:28 proposal: end this meeting :) 19:46:35 One quick thing 19:46:41 GSoC: Please file proposals. 19:46:54 nothing is really quick on this meeting ;) 19:46:56 This was unfortunately postponed to the last minute; please file them by EOD tomorrow 19:46:58 #info Please file Google Summer of Code proposals if you are interested 19:46:59 EOF 19:47:39 who wants to chair next week? 19:47:40 Oh I had one item. 19:48:08 nirik, go ahead 19:48:53 So, upstream Xfce is it seems trying to finally release 4.12. I was skeptical, but it seems like things are actually happening... 19:49:07 I made a change page, but didn't submit it yet. 19:49:20 Denied. Too late. 19:49:21 ;) 19:49:50 indeed. However, the Xfce package set is pretty self contained... and we would probibly update f22 in any event 19:50:09 but I am not sure if I should try to submit the change now or wait until it actually happens. 19:50:10 nirik: done by next week? ;) 19:50:14 there is always the possiblity to do the work 19:50:54 dgilmore: nope... beginning of march 19:51:01 is when they are claiming. ;) 19:51:18 they also is not any kind of massive release... just lots of bug fixes and translation updates. 19:51:30 no gtk3 switch or anything 19:51:36 nirik: It's not release-blocking, so I'd be okay with it coming in as a late Self-Contained Change 19:51:53 nirik: I think its up to you. I would be okay with it. but I also use Xfce 19:51:54 https://fedoraproject.org/wiki/Changes/Xfce412 is the change page. I need to ping jreznik about it I guess. 19:52:03 Any chance of getting a snapshot in for Alpha though? 19:52:18 sometimes it is better to ask for forgiveness than permission. 19:52:26 sgallagh: well, the problem is... we could push 4.11 stuff in... and they could fail to actually release 4.12 again 19:52:38 it's been several years 19:52:42 #info nirik to investigate late Xfce change 19:52:53 nirik: I'll take a look 19:52:53 * rishi trusts nirik 19:52:54 nirik: If it's primarily a set of bugfixes, is that really a problem? 19:53:16 whilst you continue to discuss this: who wants to chair next week? 19:53:33 also there's lxqt change, I hope guys agreed already on who's going to do what 19:53:34 sgallagh: well, I don't want to be stuck shipping 4.11 for 2 more years and have people say "no, can you duplicate it with 4.10" 19:53:43 not sure if it was already updated to reflect it 19:53:57 anyhow, I guess I'll submit it, and see what happens. ;) 19:54:03 jwb: I guess I could. 19:54:24 nirik: If it's in that sort of shape, I guess I'd be more inclined to tell you to wait until F23, then 19:54:27 nirik, ok. i was hoping someone else would 19:54:44 sgallagh: well, I am paranoid. ;) 19:54:55 jwb: me too, but I also want the meeting to end 19:54:56 nirik, jwb: I think it's probably my turn 19:55:00 sold 19:55:00 I'll take it. 19:55:06 #info sgallagh to chair next week 19:55:07 * nirik cheers 19:55:07 well, it's last week before the first change checkpoint... 19:55:17 anything else? 19:55:49 nothing from me 19:55:49 yeah. mass rebuild timing on f23 19:56:01 * jwb hangs head 19:56:18 isn't the answer "as soon as jakub says it's ready"? 19:56:29 With the gcc 5 ABI change, C++ seems breaking left and right. Do we want an early mass rebuild? 19:56:41 jwb: AFAICT he was saying gcc was already ready for F22. 19:56:58 I didn't get that impression 19:57:04 mitr: On the mailing list we decided that a mass rebuild would not help the C++ ABI situation, because packages need to be built topologically but a mass rebuild would be unordered. 19:57:11 mitr: we really need to build some new mass rebuidl tooling 19:57:15 nirik, nor i. i saw something about some PRs that need to be fixed first 19:57:22 mcatanzaro: OK, never mind then. 19:57:31 "There are bugs being fixed both on the gcc side and on the side of packages, 19:57:31 I think it is too early for the final mass rebuild, but gcc should be ready 19:57:31 for that in a short time. " 19:57:37 mitr: as the c++ abi change needs some special handling we currently can not account for 19:58:12 it would be awesome to say 'rebuild all things that depend on/use gcc. go' 19:58:27 (in the order needed with buildrootupdating) 19:58:28 it would be awesome to discuss this outside the context of this meeting. 19:58:33 yep 19:58:43 #info NEED MOAR BUILD TOOLS 19:58:46 #endmeeting