17:01:15 #startmeeting cloud_wg 17:01:15 Meeting started Wed Dec 16 17:01:15 2015 UTC. The chair is kushal. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:15 The meeting name has been set to 'cloud_wg' 17:01:20 #topic Roll Call 17:01:29 .hellomynameis dustymabe 17:01:29 .hellomynameis kushal 17:01:32 dustymabe: dustymabe 'Dusty Mabe' 17:01:35 kushal: kushal 'Kushal Das' 17:02:05 * gholms takes a seat in the bleachers 17:02:17 gholms, :) 17:02:42 #chair gholms dustymabe jzb jbrooks scollier 17:02:42 Current chairs: dustymabe gholms jbrooks jzb kushal scollier 17:02:48 Did I miss anyone? 17:03:15 * jsmith is here 17:03:17 haven't seen adimania in a while 17:03:23 .hello corey84 17:03:24 linuxmodder: corey84 'Corey Sheldon' 17:03:29 #chair linuxmodder 17:03:29 Current chairs: dustymabe gholms jbrooks jzb kushal linuxmodder scollier 17:03:39 #topic Action items from last meeting 17:03:52 * Kushal will write to list about #143 (f24 features) 17:03:52 still kinda new to cloud but no better way to learn right 17:04:00 * kushal to do more posts for attracting/guiding volunteers 17:04:06 linuxmodder, correct 17:04:14 linuxmodder, being in the meeting is a good start. 17:04:23 linuxmodder right :) 17:04:23 So I have started a thread. 17:04:24 corey right? 17:04:34 But it seems no reply yet. 17:04:45 oops. I see your .hello from above 17:04:55 dustymabe, feel free to put a change :) 17:05:16 kushal: all of my ideas were half baked or for F24 time frame 17:05:22 err.. F25 17:05:39 dustymabe, then get the wiki pages ready for F25 :)( 17:05:41 :) 17:05:48 I will write to list for that too 17:05:54 number80, you there? 17:06:36 I guess maxmillion's openshift can go in as a change 17:06:45 kushal: + 17:06:48 er, +1 17:07:50 let me find my change page 17:08:20 .fas rtnpro 17:08:21 rtnpro: rtnpro 'Ratnadeep Debnath' 17:08:28 rtnpro, welcome 17:08:32 I'm +1 for openshift change as well 17:08:44 * rtnpro reads above 17:08:50 https://fedoraproject.org/wiki/Changes/Cloud_MOTD 17:08:50 there was a question on the list recently about using Gluster w/ the host 17:09:05 I'm poking some Gluster folks to see if we can't get that done in the F24 timeframe 17:09:14 so you can just use Gluster in a container. 17:09:48 jzb, I think we will have to help them in filing the change 17:09:55 jzb: we'll still need the gluster client on the host or somewhere that k8s can use it 17:09:58 kushal: Why do that only on the cloud image? 17:10:03 kushal: yeah 17:10:23 nzwulfin: are we sure that can't be done in a privileged container? 17:10:39 * jzb wonders how much weight the gluster client would add 17:11:01 gholms, I am creating the generic package, so it can be used in any place within Fedora 17:11:21 jzb: i'm not sure, i just want to make sure we're talking about the right goal 17:11:27 gholms, jzb also iirc server is trying to do something for their usecases. 17:11:31 kushal: That doesn't answer my question. ;) 17:11:49 had a d/c sorry 17:11:50 makes sense to ammend the motd for that 17:11:58 blind assumption gholms it changes more frequently then the other offerings 17:12:00 gholms: only do what? 17:12:08 gholms, I am trying to enable it for cloud first. 17:12:12 probabably noticable but doubtfully impactingly so 17:12:19 jzb: i've not found anything done currently that talked about clients in containers, just gluster servers 17:12:21 kushal, the server wg is 17:12:27 jzb: To only do MOTD updates on cloud 17:12:28 gholms, have to start somewhere and make |get a functional template why not cloud 17:12:30 gholms, cloud base image. 17:12:52 big enough audience to test it not frontline enough to kill things if they break gholms 17:13:14 i'm +1 for cloud MOTD 17:13:16 gholms, also the atomic should be a bit different. 17:13:18 Seems like if it's good enough for the product one is least likely to log into it's good enough for the rest, at least at first glance. 17:13:22 kill things == novice or non dev user borking and having no clue how to fix 17:13:27 +1 for MOTD 17:13:54 +1 MOTD as well 17:14:08 jzb, glusterfs-fuse and ceph-common are in rhelah now, and they'll be in the next centos atomic host 17:14:09 gholms, it is good for workstation too, but I don't have any say there directly. 17:14:50 People introduce systemwide changes all the time. Just propose it as one. ;) 17:15:01 Anyone else wants to put in any change? 17:15:12 jbrooks: in the host itself? 17:15:20 jzb, yes, in the tree 17:15:23 sigh 17:15:29 * gholms is for it, for the record, though it should take instances without Internet access into consideration 17:15:32 Just in this latest version 17:15:48 gholms, in that case, it will have other messages :) 17:15:49 ok 17:15:57 gholms, I will keep in mind. 17:16:04 well, if they've thrown in the towel for now, might as well pull those in. 17:16:09 jbrooks: probably for openshift support 17:16:14 gholms, question how you plan to do the polling for deltas tehn 17:16:22 kushal: If it doesn't take a minute longer to boot... ;) 17:16:39 linuxmodder: Do it asynchronously 17:16:40 #chair nzwulfin jbrooks 17:16:40 Current chairs: dustymabe gholms jbrooks jzb kushal linuxmodder nzwulfin scollier 17:16:44 I think it's a matter of... not everything can be in a container right now 17:17:17 gholms, yup yup, I will ask for the ideas about how to implement it properly :) 17:17:18 can we propose cloning walters for F24 then ;) 17:17:31 nzwulfin, +1 to that 17:17:42 walters as a service (tm) 17:17:49 nzwulfin: dude, we've had clone walters as a feature request for years. 17:17:52 We hella need that 17:17:59 i only propose that b/c he'll read it in logs not live :) :) 17:18:18 i think a second dustymabe would help too 17:18:22 So everyone please at least reply to that thread in the list about f24 features. 17:18:26 :) 17:18:36 I'm working on a 2nd dustymabe in the lab 17:18:47 Moving to tickets then. 17:18:47 frankenmabe 17:18:57 #topic Fedora Cloud FAD (late 2015/early 2016) https://fedorahosted.org/cloud/ticket/115 17:19:17 dustymabe, so it seems most of the fedora engg team folks will stay back till 9th 17:19:18 * dustymabe fail 17:19:25 dustymabe, good name btw 17:19:41 kushal: right. I am planning to try to stay an extra few days in Brno to attend those meetings 17:20:14 dustymabe, +1 :) 17:20:21 jzb, I hope you will be there. 17:20:55 kushal: yes 17:21:23 kushal: trying to cut down on the "on the road" time, but I'm in Europe from the Thursday before FOSDEM through Tuesday after DevConf.cz 17:21:26 A proper FAD at some point would be nice too 17:21:30 Nice, may be we can start putting in names in the ticket (who ever we know for sure attending) 17:21:48 as a heads up, there is a RH QE event in brno before devconf if that ends up being relevant 17:21:55 I'll be around up from feb, 3 to feb 9 (morning) 17:22:03 dustymabe, I don't mind. Fly me to moon. 17:22:47 (having ISP stability issues today -- apoligize in advance if I re-hash things) 17:22:51 number80, hello there 17:22:54 #chair number80 17:22:54 Current chairs: dustymabe gholms jbrooks jzb kushal linuxmodder number80 nzwulfin scollier 17:23:05 Moving to next ticket. 17:23:22 * number80 preparing fesco meeting 17:23:32 nice number80 17:23:42 #topic Migrate all Dockerfiles / Images to systemd where possible https://fedorahosted.org/cloud/ticket/121 17:24:06 kushal: let's lump all dockerfile related tickets together and ask if anyone has anything to add 17:24:19 I feel like these have kind of stagnated because we don't really know what we are doing with them 17:24:52 I feel the same :-p 17:25:00 scollier, this one seems to be on you. 17:25:13 dustymabe: I've been poking mattdm about this 17:25:22 we kind of stalled with the build system "everything not on GitHub" etc thing 17:25:36 * jzb goes to see if he can summon mattdm 17:25:39 *nods* 17:25:48 kushal, reading. 17:26:28 kushal, right, so I spoke with jzb about this and we really need to follow up and get closure. timelines, direction, etc... 17:26:37 stabbing in dark on containers but can't a unpriv'd user be given a similarto sudo access for such things 17:26:42 does the proposal on the list to add LABELs to the Dockerfiles help or hinder motion 17:26:45 scollier: are you a proven packager? 17:26:53 jzb, no 17:26:57 or do we have one in the cloud wg to own packages? 17:26:59 hrmph 17:27:03 number80, is 17:27:10 who owns the current fedora-dockerfiles package? 17:27:27 .whoowns fedora-dockerfiles 17:27:27 kushal: adimania 17:27:31 jzb, :) 17:27:36 ah 17:27:41 .whoowns fedora-dockerfiles 17:27:41 linuxmodder: adimania 17:27:49 kushal, h^ 17:27:51 and adimania has been absent lately 17:27:53 bonus 17:27:58 ok 17:28:01 lovely 17:28:03 jzb, yes, he is starting his own work iirc 17:28:11 kushal: his own work? 17:28:13 how do you mean? 17:28:37 likely like me a startup (in my case) 17:28:46 OK 17:28:56 yes 17:28:59 or some similar such 17:29:00 or consulting 17:29:06 ok 17:29:08 jzb, I don't have details. 17:29:13 I don't think I've ever used these from the rpm 17:29:17 just from git 17:29:22 my proposal for now is this 17:29:32 let's start by fixing the stuff where it lives now 17:29:33 jbrooks, same 17:29:35 jbrooks, yes, but rpm was for normal users to see the examples. 17:29:42 jzb, +1 to that 17:29:53 nothing is stopping anybody from moving the files at a later date for the buildsystem or whatever 17:29:54 +1 fixing "in-place" 17:30:01 github is pretty easy for normal people, too -- you can browse right to the example 17:30:08 if we want to put them in pagure later or split out into separate packages, then they can do so 17:30:13 jzb, ack. 17:30:20 any objections? 17:30:22 the cli bit is a bit "oh shit" for normal users often tho 17:30:35 non efrom me 17:30:47 +1 to in-place 17:30:58 Cool 17:31:01 jzb, i'll let the co-maintainer know 17:31:14 So should I skip the rest of the dockerfiles tickets? 17:31:22 #commands 17:31:22 Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #rejected #restrictlogs #save #startmeeting #topic #unchair #undo #unlurk 17:31:37 ok, so proposed: 17:32:25 I'm good with a prop. to fix in place and move to pagure 17:32:32 Cloud group agrees to continue to maintain dockerfils on GitHub for now until a more concrete proposal and timeline is proposed to move them elsewhere. Work will re-commence on updating Dockerfiles for dnf, systemd, etc. 17:33:04 can we vote on that (and cloud wg members, please add (binding) to +1 or -1) 17:33:08 ? 17:33:18 +1 17:33:22 jzb, did you mean #proposal Cloud group agrees to continue to maintain dockerfils on GitHub for now until a more concrete proposal and timeline is proposed to move them elsewhere. Work will re-commence on updating Dockerfiles for dnf, systemd, etc. 17:33:45 linuxmodder: ish, doesn't look like #proposal is an accepted command :-) 17:33:47 +1 17:33:53 +1 17:33:57 +1 for me 17:34:14 #proposal Cloud group agrees to continue to maintain dockerfils on GitHub for now until a more concrete proposal and timeline is proposed to move them elsewhere. Work will re-commence on updating Dockerfiles for dnf, systemd, etc. 17:34:27 it works elsewhere in meetings thats odd 17:34:30 +1 again 17:34:35 #chair linuxmodder 17:34:35 Current chairs: dustymabe gholms jbrooks jzb kushal linuxmodder number80 nzwulfin scollier 17:34:41 you are there 17:34:54 linuxmodder: I did a #commands to check 17:34:57 ah you chair'd my fas not mick lol 17:35:06 it's not listed 17:35:16 oh, jzb, my vote +1 17:35:20 anyway - any -1's ? 17:35:26 +1 17:35:27 going once... 17:35:28 not that I can tell 17:35:28 +1 17:35:31 ok 17:35:46 +1 17:35:48 looks like all +1 s 17:35:52 #agreed Cloud group agrees to continue to maintain dockerfils on GitHub for now until a more concrete proposal and timeline is proposed to move them elsewhere. Work will re-commence on updating Dockerfiles for dnf, systemd, etc. 17:35:59 thanks all 17:36:28 jzb, so skipping the rest of the dockerfiles tickets? 17:36:49 kushal: anything that's outside that scope we need to discuss? 17:37:02 nope, all normal ones 17:37:16 do we need to talk about the LABEL proposal from the list? 17:37:29 #topic make docker archived image get imported with lowercase tag https://fedorahosted.org/cloud/ticket/131 17:37:29 hailed mattdmm in -admin he may be in shortly 17:37:36 nzwulfin, may be on openfloor 17:37:40 kushal: ok 17:38:01 fix is in updstream as far as I know 17:38:02 iirc the patch was ready. 17:38:03 oh, didn't Ian say last week this was solved? 17:38:15 jzb, may be we missed it :( 17:38:32 maybe solved upstream.. might have to trickle down and then we might have to change our tools to use it 17:39:11 i would leave ticket open for now 17:39:17 I will ask Adam for his input. 17:39:26 +1 for leaving open 17:39:39 k 17:39:40 Okay. Moving to next ticket then. 17:39:49 #topic Fedora 23 Retrospective https://fedorahosted.org/cloud/ticket/135 17:40:12 jzb, do you want to say thing on this? 17:40:29 * anything 17:40:53 I think we covered it last week, I probably need to go back and update the ticket. 17:41:41 jzb, thanks. Adding an action item. 17:41:56 agree with comments but not sure how to go about that 17:42:00 #action jzb will update #135 on Fedora 23 retrospective 17:42:23 #topic vagrant boxes fixups https://fedorahosted.org/cloud/ticket/136 17:42:24 linuxmodder: "that" being...? 17:42:47 fixing the lack of autocloud testing on docker and the like 17:43:14 linuxmodder, we added those tests :) 17:43:30 dustymabe, do you want to say anything on this? 17:43:37 on the current ticket 17:43:40 ? 17:43:41 I thought we can just add a device from virt-manager 17:43:50 dustymabe, Yes, #136 17:44:16 kushal: right 17:44:37 dustymabe, So do we need to do anything special to the Vagrant images? 17:44:52 we should be able to easily add this, but I think it would take some coordination with one of us and maybe someone like Ian to pull it off 17:45:12 If I had some dedicated time for it I could do it, but I don't right now with the wedding coming up and atomicapp work 17:46:07 dustymabe, may be I misunderstood, do we have to add that device in the image? or can we just do it in the instance from virt-manager or virtualbox? 17:46:24 That's pretty easy 17:46:25 dustymabe: is it possible to do that via a Vagrantfile? 17:46:37 Someone could mod their vagrantfile to do it, ... like jzb said 17:46:51 so maybe a sample vagrantfile is what's really called for? 17:46:53 I think it is something we can add to the vagrant boxes 17:47:03 to make it the default 17:47:05 jbrooks, jzb so we should do few blog posts + more docs 17:47:22 dustymabe, I think we should keep to the Vagrantfile 17:47:34 Vagrant users can decide what they want to do 17:48:50 let's start there, and then see if there's a call to do it in the box by default? 17:49:12 I don't know that I've ever been like "this vagrant box needs a cd device" 17:49:33 jzb: the reason the guy wanted it was so he could follow the tutorial for installing vbox guest additions 17:49:38 (not a vagrant guy so staying out of it but generally seems like a saen appraoch) 17:49:40 it tells people to insert a cd 17:49:46 er,sane 17:50:09 there is nothing wrong with adding it to the box in my opinion 17:50:16 I bet we could do the whole thing in a vagrant provisioning script 17:50:17 people who didn't use it before won't notice a difference 17:50:22 people who want it will use it 17:50:22 dustymabe, the vbox site shows that you use the cd adapter bit 17:50:24 I bet it'd be super short 17:50:28 has since 4.3.x 17:50:55 either way.. what I am saying is that we don't lose anything by adding a cd device to the vm 17:51:14 and obviously somebody has asked for it, so some people would see it as a benefit 17:51:37 isn't vagrant more lib-virt-ish than vbox-ish? 17:51:55 linuxmodder: probably more people using vbox than libvirt 17:51:56 the opposite, actually 17:51:57 seems more like a lazy factor to me tbh 17:51:58 linuxmodder: not sure what that means.. it basically builds on the hypervisor 17:52:13 dustymabe, but, yeah, nothing lost by adding it 17:52:14 lazy factor.. meaning people shouldn't be lazy? 17:52:24 does adding it to the box means it's available to all providers without mods to the Vagrantfile? 17:52:33 nzwulfin: yes 17:52:40 thanks 17:52:45 dustymabe, no more like I can't google this shit lazy which we all know is hardly ever good turnout 17:53:02 a plugin for installing/updating this: https://github.com/dotless-de/vagrant-vbguest 17:53:22 yeah.. well part of the draw of vagrant is making things easy.. otherwise people would just use libvirt/vbox directly 17:53:30 dustymabe: +1 17:53:36 jbrooks, plugin being totally optional I assume not forced on user? 17:53:41 * nzwulfin is going to stay out of that one... 17:53:43 My search gave me this at the first result https://gist.github.com/leifg/4713995 17:53:44 if so I'm +1 17:53:50 Yeah, you'd go do it yourself 17:54:01 linuxmodder: so - odds are if you google "vagrant" and anything you're going to wind up on a tutorial for Ubuntu 17:54:03 so.. that was just one case where someone might want a cd device 17:54:16 linuxmodder: so sending folks to Google rather than helping them, probably not the best strategy 17:54:18 adn ubuntu != fedora right? 17:54:20 there are others I'm sure 17:55:02 anywho.. at least for the time being there is no one working on this so we'll move to next year probably 17:55:20 dustymabe: I will however ask that we make tickets more specific ;-) 17:55:21 dustymabe, I will look into this, but only after 23rd :) 17:55:42 Okay we have only 5 minutes 17:55:43 jzb: yeah we were getting some feedback on the fed mag article 17:55:47 and I thought we might have more items 17:56:04 Moving to next ticket? 17:56:10 https://fedoramagazine.org/fedora-cloud-vagrant-boxes-atlas/ 17:56:23 updated ticket 17:56:28 #topic Producing 2 week atomic images https://fedorahosted.org/cloud/ticket/139 17:56:37 We had a release yesterday. 17:57:01 * jzb is working on a post for the Magazine/Project Atomic 17:57:19 All is good in that side. 17:57:33 Going to open floor? 17:57:40 #topic Open Floor 17:57:46 * jsmith has nothing additional 17:57:47 networkd :) 17:58:01 I'd like to +1 the proposal on the list to add LABELs to our example Dockerfiles :) 17:58:15 nzwulfin: I'm ok with that 17:58:22 nzwulfin, I am +1 17:58:31 Any comments on networkd? 17:58:34 kushal: re: networkd 17:58:50 did anyone ever talk to the point of Atomic Host sharing tree with bare metal 17:58:52 I'm still concerned about making sure it's well tested 17:59:02 and the implications of moving to networkd for bare metal 17:59:11 I feel like this is a discussion walters should be involved in 17:59:39 tflink, right concern, but we have to do it someday. So why not now. 17:59:48 swapping out the network stack means that all the other network testing for other fedora products would not be re-usable for the cloud image 17:59:53 kushal: why do we have to do it? 18:00:04 I still don't understand that 18:00:14 tflink, 1. systemd 2. Other major cloud images are doing the same. 18:00:23 the only things I've seen are "becuase it's smaller" and "becuase everyone else is doing it" 18:00:41 tflink, everyone else doing it is a good cause for users. 18:00:55 how would most users even notice? 18:00:57 where as it is also something in the image already. 18:01:14 mhayden: might have some input 18:01:27 tflink, I guess we should continue 1-2 more minutes :) 18:01:28 * mhayden stumbles in 18:01:29 re, open floor: on the subject pre-meeting of adding stuff to base image, I'd love for there to be a method for doing DNS lookups, to debug DNS issues. 18:01:48 siXy: for atomic host you mean? 18:01:52 yes. 18:02:01 mhayden, we are having the Networkd discussion for F24 :) 18:02:08 oh, okay 18:02:18 mhayden, also having a thread in the list, 18:02:30 mhayden, may be you want to reply to that :) 18:02:35 siXy: I'm +1 for that as well 18:02:40 just haven't had time to submit a PR 18:02:43 other than the smaller bit waht other bonuses or pros does networkd bring exactly 18:02:44 anyway, ending this meeting? Is that okay? 18:02:58 linuxmodder, easy to use. 18:02:58 siXy: the tools container? 18:03:06 kushal: let's finish out the discussion on networkd 18:03:11 dustymabe, Okay 18:03:11 nzwulfin: if DNS is broken, you won't be able to pull an image 18:03:16 nzwulfin: therefore that doesn't help 18:03:21 siXy: right 18:03:24 siXy: yeah i was about to SMH for that 18:03:25 that has been my argument in the past 18:03:30 soon as i hit enter ... 18:03:33 so it needs to be in there 18:03:33 I'm still concerned that we're 1) making atomic the primary deliverable. and 2) making major changes in the cloud image which significantly increase its testing requirements 18:03:34 :) 18:03:35 can't you still use IPs in the interim 18:03:39 mhayden, so here, people want to know about the + points of networkd. 18:04:03 tflink: what's the concern about 1 exactly? 18:04:05 when to be quite frank, there isn't an incredible track record of testing the cloud image when it mostly overlaps with a small server install 18:04:08 tflink, I think we already took the decision of making atomic as the primary deliverable. 18:04:20 jzb: removing focus at the same time we're changing scope 18:04:28 I'm not saying we shouldn't 18:04:41 tflink: that's good, because as kushal said it's already decided 18:04:42 linuxmodder: not really. I've no idea what the IP of docker hub might be, for a start. adding nslookup or similar shouldn't be that expensive. 18:04:49 :-) 18:05:03 just concerned that there's a change in focus at the same time there's a change in scope when there's not a great track record of testing in the first place 18:05:09 of the cloud image 18:05:09 mhayden, still there? 18:05:20 I'm not grokking the "change in scope" bit 18:05:27 jzb: networkd 18:05:32 tflink: also looking for a proposed solution 18:05:38 so I'm not too worried about networkd not working in cloud environments 18:05:39 Does the rest of Fedora have an opinion on networkd? 18:05:41 nothing else in fedora uses 18:05:45 jzb: solution for what? 18:05:46 kushal: i am 18:05:47 tflink, that is why we are bringing in more volunteers for helping in testing. 18:05:57 but the problem is that atomic host shares the tree with the bare metal version 18:06:00 tflink: teh concern 18:06:02 er, the 18:06:04 kushal: that doesn't change the past track record 18:06:13 dustymabe, I am not changing anything on the tree 18:06:18 it seems like it would be troublesome if cloud images shifted to networkd without the rest of fedora moving at some level 18:06:20 dustymabe, but just enable network in the kickstart file 18:06:21 but I'm more of a "believe it when I see it" kind of person 18:06:34 systemd-networkd on workstation isn't the best idea, but it's good for servers/cloud/containers 18:06:50 afaik, the cloud image would be the only place where networkd is used by default 18:06:50 kushal: so what is the point then.. 18:06:52 IIRC, ArchLinux has completely gone to systemd-networkd 18:06:52