17:00:38 #startmeeting Fedora Cloud WG 17:00:38 Meeting started Wed Jul 15 17:00:38 2015 UTC. The chair is kushal. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:38 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:44 #topic Roll Call 17:00:49 .hellomynameis kushal 17:00:50 kushal: kushal 'Kushal Das' 17:01:01 .hellomynameis lsm5 17:01:02 .hellomynameis dustymabe 17:01:02 lsm5: lsm5 'Lokesh Mandvekar' 17:01:05 dustymabe: dustymabe 'Dusty Mabe' 17:01:08 * gholms lurks 17:01:23 * jbrooks here 17:01:26 .hello roshi 17:01:27 roshi: roshi 'Mike Ruckman' 17:01:35 jbrooks, Hello 17:01:44 jbrooks, I will remember to ping you from next time :) 17:01:49 :) 17:02:00 .hellomynameis jasonbrooks 17:02:01 jbrooks: jasonbrooks 'None' 17:02:08 jbrooks: hi None :) 17:02:15 heh, need to figure that out 17:02:33 :D 17:03:06 jbrooks, add your name and other details in FAS 17:03:48 Anyone else? 17:03:53 number80, hello 17:04:06 o/ 17:04:09 :) 17:04:14 We can start :) 17:04:30 I am unable to open any of the old meeting minutes, can anyone help? 17:05:42 kushal: will try to find 17:05:45 Meanwhile let us go to the open tickets. 17:05:46 .hello maxamillion 17:05:47 maxamillion: maxamillion 'Adam Miller' 17:05:52 maxamillion, hello there :) 17:05:56 hi hi :) 17:05:59 https://fedorahosted.org/cloud/report/9 17:06:15 #topic Missing Cockpit RPMs in Fedora Atomic 22 https://fedorahosted.org/cloud/ticket/105 17:06:26 .hello sayanchowdhury 17:06:27 sayan: sayanchowdhury 'Sayan Chowdhury' 17:07:32 dustymabe, do you know anything more about it? 17:07:47 kushal: I think status is as the last comment says 17:08:02 looks like we aren't going to have the cockpit rpms included in atomic by default 17:08:16 I imagine we can add a systemd service file easily enough through cloud-init / kickstart 17:08:20 * lalatenduM is her 17:08:28 lalatenduM, sayan welcome 17:08:43 kushal: thanks for the reminder ping :) 17:09:10 jbrooks: right. The last request in the ticket is for documentation around how to set it up automatically on bringup 17:09:22 dustymabe, let us just go for a vote, and then ask for help with those docs from the atomic upstream. 17:09:34 dustymabe, +1 here 17:09:47 +1, and I can run down documenting how 17:10:07 obviously +1 from me 17:10:14 +1, makes sense to me 17:10:21 +1 17:10:22 +1 17:10:58 +1 17:11:25 Cool, then I will update the ticket, and ask once again for the docs. 17:12:00 #action kushal to update https://fedorahosted.org/cloud/ticket/105 saying all +1 votes for the proposal from dustymabe and we need those doc examples 17:13:09 #topic Maintaining Fedora docker images for f22 https://fedorahosted.org/cloud/ticket/97 17:13:15 It is done as mentioned by lsm5 . 17:13:19 yup 17:13:22 just commented :) 17:13:23 We should close this ticket. 17:13:25 hi 17:13:30 scollier_, Hello and welcome :) 17:14:24 Moving to next 17:15:16 #topic Investigate systemd-networkd https://fedorahosted.org/cloud/ticket/14 17:15:50 roshi, what do you think? 17:16:00 I am yet to start working on it. 17:16:21 I'm still on the "stick with networkmanager" side of things 17:16:26 just from a QA perspective 17:16:29 kushal: are you going to do an analysis of NM vs networkd? 17:16:34 * gholms thinks the feature page needs work 17:16:41 not to mention all the docs out there for working with NM work with our cloud images 17:16:41 * number80 would have preferred to consider moving to NM 17:17:00 dustymabe, roshi number80 Okay. 17:17:06 but considering that server is now solidly tied to NM, this will be complicated 17:17:14 we don't have enough docs as is for the cloud image (in the form of tutorials as well), and this just serves to bifurcate things further 17:17:26 I will then do the both and see how it goes. 17:17:54 it can't hurt to compare the two, but I really don't see a ton of value in making the switch 17:18:18 though, if there was a large FOSS push (as a whole, across distros) for networkd, then I might be willing to reconsider 17:18:29 roshi: smaller base system, we don't need the NM bloat 17:18:29 but at the same time, if that was the case then all of Fedora should look into it 17:18:30 kushal: sounds good. it's always good to have a comparison 17:18:42 but the bloat is only a couple MB, right? 17:18:44 one could also work on a better NM packages split 17:18:44 number80: We do not have a size problem. 17:18:50 roshi, generally we are ahead than other distros when it comes about being first just like systemd :) 17:18:56 I'd vote for a package split 17:19:16 gholms: yeah, but it pulls too many things 17:19:22 but a bit of "bloat" doesn't outweigh the mindshare/tutorial/docs/testing cost in my head 17:19:23 Yeah 17:19:40 gholms, also we are still trying to keep the size minimal :) 17:19:49 our image is a good size as it is, CentOS is a lot larger last I looked (supposing I was looking at the right thing) 17:19:55 roshi: if we haven't started working on it, it makes sense to delay it to F24 17:20:18 at the very least 17:20:50 number80, I have done initial tests on my local boxes, it worked well. 17:20:57 number80, but nothing is pushed :) 17:21:33 it just smells like a lot of unknown for a little known 17:21:36 kushal: ack 17:21:48 and "bloat" isn't quite enough for me to buy in on it 17:21:55 for the record, NM pulls avahi, who needs avahi on cloud images? 17:21:58 roshi, isn't that always the case with being *first* ? 17:22:07 I think Fedora atomic can also leverage from this i.e. networkd , so +1 to evaluating it 17:22:18 Though we are not first in it. 17:22:22 kushal: almost 17:22:40 kushal: Generally when we do something "first" we acknowledge the costs and get buy-in from the people it will affect first. 17:22:53 I think making the change before writing up a bunch on it and having a solid justification for "why" before we do it though 17:23:00 I'd be interested in networkd from an Atomic perspective, but know very little about it ... so +1 for evaluation of it 17:23:08 gholms, True. 17:23:25 changing a networking stack is no trivial thing, and we'd *at least* want a 1:1 ratio of tutorials for the old way vs the new way 17:23:38 kushal: That's pretty much what my comment on the issue was. The feature page needs work. 17:23:43 and be ready to hear and support people asking "how do I do X like I used to with NM?" 17:23:45 roshi: +1 17:23:49 gholms, understood. 17:24:12 that's what I was meaning by the unknowns 17:24:30 it's a lot of work to support the change, that I want to make sure we have people ready to do 17:24:52 roshi: Would a systemd generator that reads ifcfg files be sufficient? 17:24:52 so we agree on evaluating it and have a go/no-go meeting about networkd ? 17:24:56 Btw, the upstream also commented in the discussion https://fedoraproject.org/wiki/Talk:Changes/Cloud_Systemd_Networkd 17:25:01 having just one person run some local tests isn't quite enough to justify that - especially if we want people using this stuff in prod out in the wild 17:25:18 I wouldn't switch my stuff until it was load tested and really documented 17:25:29 roshi, understood 17:25:33 a NM finger-grained split would work for me 17:25:49 roshi, atleast the work is on for other distros to move to networkd for the cloud images. 17:25:56 NM-core + optional stuff == current NM main package 17:26:03 roshi, coreos is done, Debian/Ubuntu is on the way. 17:26:05 cloud could just pull NM-core 17:26:33 that's something - I haven't looked into it really 17:26:42 That way anyone else coming down from other distros can use/find similar kind of configs for Fedora too. 17:26:45 or tried to test it locally - do we have an image somewhere with it? 17:26:52 * roshi still can't get local cloud builds to work 17:27:03 roshi, nope, I will build one, and upload somewhere. 17:27:08 awesome 17:27:23 #action kushal is to build a local cloud image with networkd and upload it for others to test 17:27:33 and it'd be prudent to document how we plan to test this, what we expect to work, etc etc 17:27:35 That also means I will write down the docs for the same :) 17:27:40 roshi, Yup. 17:27:45 +1 to that. 17:27:56 thanks kushal 17:28:20 Thanks! 17:28:35 sorry if I come across as a grumpy neckbeard on this, we just have enough that needs testing that we don't have coverage for (which is being worked on) that I don't want to add something else to it while we're working on covering what we already have 17:28:39 if that makes sense 17:28:48 roshi, understood :) 17:29:07 * roshi has to be the crotchety QA guy :p 17:29:14 :) 17:29:17 Hehe 17:29:21 Heh 17:29:24 Moving to next ticket then. 17:29:35 #topic Care and Feeding, Fedora Dockerfiles https://fedorahosted.org/cloud/ticket/84 17:30:11 We actually need more people to help out scollier_ in this. 17:30:25 sayan, btw, can you start helping out in some of the things? 17:30:37 it's something that's always on my list to do, but I never seem to get around to it 17:30:38 sayan, say in testing and/or docs :) 17:30:44 kushal, yes, i can 17:30:57 I once volunteered to help, I haven't done anything w/ it -- but I'm still willing to help 17:31:04 * maxamillion needs to duck out, apologies 17:31:19 * dustymabe waves 17:31:30 * number80 can help 17:31:46 #action jbrooks and sayan will help scollier_ in testing the Fedora Dockerfiles for https://fedorahosted.org/cloud/ticket/84 17:31:50 #undo 17:31:50 Removing item from minutes: ACTION by kushal at 17:31:46 : jbrooks and sayan will help scollier_ in testing the Fedora Dockerfiles for https://fedorahosted.org/cloud/ticket/84 17:31:59 #action jbrooks and sayan and number80 will help scollier_ in testing the Fedora Dockerfiles for https://fedorahosted.org/cloud/ticket/84 17:32:02 :D 17:32:08 There was some discussion around putting some CI around it 17:32:17 have we done it yet? 17:32:20 lalatenduM, we need help in that too 17:32:34 kushal: do we have infra for this 17:32:43 lalatenduM, right now, nope :) 17:32:47 and are we using tunir or Jenkins? 17:33:06 lalatenduM, all Fedora QA work goes through Taskotron. 17:33:09 We can use CentOS CI systems :) 17:33:25 lalatenduM, That is always an helpful option :) 17:33:46 roshi, btw, just pass the taskotron docs to lalatenduM for a later look. 17:33:52 I dont have info on Taskotron 17:34:17 I can help to set it up, but can't promise on maintaining it 17:34:18 lalatenduM: check in with tflink for taskotron stuff 17:34:29 roshi: ok 17:34:30 we're working to get disposable clients ready for it 17:34:37 but he's the one driving that 17:35:35 shouldl I put an action on me? 17:35:56 #action lalatenduM will setup a CI for Fedora dockerfiles 17:36:00 lalatenduM, ^^ 17:36:15 ah , thats a very big ai 17:36:18 :) 17:36:41 :) 17:36:53 I am keen on putting a plan as of now 17:36:55 lalatenduM: you can write thing to run in a recently spawned testcloud instance - as that will roughly mirror what taskotron has 17:37:44 roshi: will check 17:37:56 then you just have to port it to a task 17:38:07 i have a copr build 17:38:30 Nice :) 17:38:55 Moving to next topic 17:38:55 roshi: Will sync with you after I have some background on this 17:39:04 kk 17:39:26 #topic https://fedorahosted.org/cloud/ticket/108 Create text for Fedora cloud Flyer 17:39:36 I really never managed to find time for this. 17:39:41 Can anyone please help? 17:41:06 do we have a template? 17:41:20 number80: https://ankursinha.fedorapeople.org/fedora-flyer-workstation/fedora-flyer-workstation-tumble.pdf 17:41:22 with branching F23 my time is going to slip back into full testing mode 17:41:24 the hard part is not writing but making it fit 17:41:44 true.. so if we had the "source" for that pdf? 17:41:51 I could help, but next week, I'll be at europython 17:42:33 https://github.com/sanjayankur31/fedora-flyer-cloud/blob/master/fedora-flyer-cloud.tex 17:43:50 can we just have the writing up somewhere? 17:43:51 jbrooks: is that from an old flyer? or is that new? 17:44:18 added Jun2 looks new 17:44:21 dustymabe, should be from an old one. 17:44:22 dustymabe, That's from the repo linked from the ticket -- the text looks like it matches the workstation flyer? 17:44:37 dustymabe, I mean the source. 17:44:39 cool number80 if you could put the text up somewhere somebody else could handle formatting etc 17:45:12 dustymabe: ack 17:45:22 dustymabe, I guess ankur will do that. 17:45:36 if he can't then I could have a stab 17:46:25 dustymabe, great :) 17:46:34 number80, dustymabe can you please update that ticket? 17:47:45 kushal: sure.. add an action item for number80 pls 17:47:52 dustymabe, lol 17:48:07 i'm updating ticket now 17:48:21 #action number80 will write the flyer text for Fedora Cloud flyer. 17:48:34 Moving next 17:48:34 #topic Producing Updated Cloud/Atomic Images https://fedorahosted.org/cloud/ticket/94 17:49:11 I just pushed a commit for https://bugzilla.redhat.com/show_bug.cgi?id=1234504 17:49:37 Waiting to test the nightly builds, and then we can ask dgilmore for a updated release tree. 17:49:40 Is that okay? 17:49:57 Of course this means after following all the general tests. 17:49:58 that should be fine 17:50:17 kushal: do you publish your tunir tests anywhere? or do you just update the matrices 17:50:20 ? 17:50:37 roshi, I just update the matrices 17:50:48 ok, cool 17:50:56 by hand, or automagically? 17:51:12 you could always use relval to push updates to the matrices as the tests pass/fail 17:51:12 roshi, tunir just runs the commands automatically which I used to run manually. 17:51:22 roshi, Yes, I have to look at that :) 17:51:28 roshi, will ping you next week. 17:52:13 sounds good :) 17:53:10 next 17:53:30 #topic No longer provide 32 bit image https://fedorahosted.org/cloud/ticket/106 17:53:45 I guess since oddshocks isn't around much more 17:53:50 kushal: the vagrant images failed 17:53:52 someone else needs to pick up the torch on this one 17:54:09 roshi: seems good for you :) 17:54:14 32 bit = less test 17:54:15 My idea is that we may put the 32bit image as secondary arch, dgilmore may help. 17:54:20 dustymabe, I will. 17:54:32 dgilmore, Okay, will look into those after the meeting. 17:54:41 :D 17:54:41 dgilmore, Thanks for the info :) 17:54:41 secondary arch for cloud? 17:54:53 or secondary arch for Fedora? 17:54:54 dustymabe, as many people still prefer to run 32 bit images. 17:55:06 dustymabe, only for the cloud product. 17:55:11 do we have a protocol for retiring arches? 17:55:18 or do we just pull support? 17:55:18 dgilmore, ^^ 17:55:35 secondary arch seems sensible to me, for a release or two before pulling it 17:55:41 roshi: we have nothing for doing things like that today 17:56:03 its going to need some changes 17:56:07 roshi, I would still love to keep the image rolling with public testing, less stress on you :) 17:56:10 but we need to make the changes anyway 17:56:22 kushal: is there a good reason why someone would choose 32bit over 64bit? 17:56:31 legacy code base? 17:56:40 yeah but there are i386 libs 17:56:41 dustymabe, smaller memory footprint + legacy apps 17:56:54 dgilmore: I thought as much :) something to propose to fesco or the council maybe? 17:56:56 you can run i386 apps on x86_64? 17:57:04 i thought 17:58:10 I think one use case is if you have 32bit hardware.. but in the case of cloud that argument doesn't make sense 17:58:29 I don't see a ton of reason to keep it for cloud 17:58:41 yeah.. I would vote to drop it 17:58:43 dustymabe: not all apps (java for example doesn't support multilib) 17:58:49 workstation, server? Sure, we should keep 32bit of those since there's so much hardware out there 17:58:53 roshi, that is why I said about secondary 17:59:11 right, I like the secondary idea - but fesco or council probably needs to weigh in on it 17:59:11 mizdebsk, +1 17:59:17 roshi, yes. 17:59:26 We are almost over the time 17:59:26 since workstation and server are going to need to make the same decision somewhere down the line 17:59:58 mizdebsk: ok.. but are those apps ever going to be migrated to 64bit? 18:00:00 Please put up all of your thoughts in the ticket. 18:00:05 dustymabe, Nope 18:00:16 kushal: and why not? 18:00:33 dustymabe, Too costly for the enterprises to do the work. 18:00:40 dustymabe: i was thinking of 3rd-party apps, which we don't have control over 18:00:48 you're saying that we have to support 64bit forever 18:00:56 dustymabe, ^^ I am talking about the same. 18:00:57 * number80 will be at fesco meeting 18:01:01 s/64bit/32bit/ 18:01:22 kushal: ok 18:01:28 dustymabe, I don't see it dyeing so fast. 18:01:29 so secondary arch is maybe the way to go 18:01:40 but we would need to talk about what that means 18:01:46 for sure 18:01:48 does that mean we just have a cloud image on the download page 18:01:49 roshi: likely yeah 18:01:54 and no images uploaded to pub clouds? 18:02:31 dustymabe, I think we should provide that too, but not tested by the QA cycles. 18:02:59 kushal: "that" = 32bit download? 18:03:10 dustymabe, 32bit on aws 18:03:19 and other public clouds 18:03:36 well. I think if we are going to provide it then we can't just have something broken 18:03:50 my vote would be offer the download.. if they want to put it in pub cloud and test it then they can 18:04:03 i'll be quiet now 18:04:16 dustymabe, Okay, 18:04:24 Please update the ticket with your views. 18:04:30 It will documented then. 18:05:01 #topic Open Floor 18:05:38 I want to use 1 hour in the flock from cloud meeting room, so that we can have a chat with the CentOS upstream about their QA effort. 18:05:57 I will invite the Fedora QA team along with the Cloud team. 18:06:10 I hope that is okay. 18:06:21 kushal: sounds good to me 18:06:23 I'll be there 18:06:27 yeah, that'd be great 18:06:32 I'll be there as well 18:07:20 Complete offtopic: photos from fudcon pune https://www.flickr.com/photos/kushaldas/sets/72157653370892863 18:07:32 If there is nothing else, then we can end the meeting. 18:07:38 thanks kushal :) 18:07:38 Going in 5 18:07:40 4 18:07:42 3 18:07:43 2 18:07:45 1 18:07:47 #endmeeting