17:02:39 #startmeeting Cloud WG 17:02:39 Meeting started Wed Oct 28 17:02:39 2015 UTC. The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:39 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:45 #meetingname Cloud WG 17:02:45 The meeting name has been set to 'cloud_wg' 17:02:53 #topic Roll Call 17:02:57 .hellomynameis sayanchowdhury 17:02:58 sayan: sayanchowdhury 'Sayan Chowdhury' 17:02:58 .hello adimania 17:02:59 who's around? 17:03:02 .hello roshi 17:03:02 .hellomynameis kushal 17:03:04 adimania: adimania 'Aditya Patawari' 17:03:05 .hellomynameis dustymabe 17:03:07 roshi: roshi 'Mike Ruckman' 17:03:10 kushal: kushal 'Kushal Das' 17:03:13 .hello lalatendu 17:03:13 dustymabe: dustymabe 'Dusty Mabe' 17:03:15 .hello jasonbrooks 17:03:17 lalatenduM: lalatendu 'Lalatendu Mohanty' 17:03:20 jbrooks: jasonbrooks 'Jason Brooks' 17:03:30 .hello maxamillion 17:03:31 maxamillion: maxamillion 'Adam Miller' 17:04:05 .hellomynameis smdeep 17:04:06 smdeep: smdeep 'Sudeep Mukherjee' 17:04:18 .fas rtnpro 17:04:18 rtnpro: rtnpro 'Ratnadeep Debnath' 17:05:01 sweet - good turnout :) 17:05:10 #topic Previous Meeting Followup 17:05:12 scollier to close https://fedorahosted.org/cloud/ticket/124 dusty to open ansible on atomic 23 ticket dmabe,mattdm we need to integrate the Cloud WG and the 2 week atomic efforts 17:05:21 and that didn't preserve the newlines 17:05:22 jas 17:05:31 * scollier to close https://fedorahosted.org/cloud/ticket/124 17:05:31 * dusty to open ansible on atomic 23 ticket 17:05:32 * dmabe,mattdm we need to integrate the Cloud WG and the 2 week atomic efforts 17:05:36 there 17:06:15 doesn't look like 124 got closed 17:06:17 so I just closed 124 17:06:21 :) 17:06:21 thanks 17:06:29 A question around this 17:06:30 and you have updates for the other two? 17:06:33 the ansible atomic 23 ticket.. I didn't open one 17:06:42 because walters put in some python stuff into the image 17:06:50 before I had a chance to open the ticket 17:07:02 should I still open the ticket, point to the work, and then close it? 17:07:34 Should we continue packaging fedora-dockerfiles package in repo or should we stop to favor dist-git? 17:08:12 adimania: that might be a question for scollier who can't make it today 17:08:18 maybe send an email to the list? 17:08:33 ok. 17:08:37 Having a single git repo helps (in term of maintaining it) 17:08:46 roshi: action me/mattdm for the last item again 17:08:47 +1 for email to list 17:09:15 fyi, I am the primary owner for the package. I just wanted to know the opinion of more people. 17:09:16 am I late? 17:09:21 looks like I are. 17:09:41 nah.. just in time 17:10:14 sure thing 17:10:22 were we going to discuss mattdm's email? 17:10:31 I'm ... puzzled, but it seems like a good convo to have. 17:10:36 #chair dustymabe lalatenduM adimania jzb maxamillion jbrooks kushal sayan smdeep rtnpro 17:10:36 Current chairs: adimania dustymabe jbrooks jzb kushal lalatenduM maxamillion roshi rtnpro sayan smdeep 17:10:40 jzb: I'd like to in open floor 17:10:48 maybe mattdm will be here too 17:11:02 #action dustymabe to integrate cloud WG and 2 week atomic efforts 17:11:20 onto the tickets! 17:11:30 jzb: depending on which of mattdm's emails you're referring to I wa splanning to bring it up 17:11:38 #topic python3 only breaks ansible 17:11:41 dustymabe: wait, what are we integrating? 17:11:46 #link https://fedorahosted.org/cloud/ticket/126 17:11:58 dustymabe: actually, we can follow up outside the meeting on that 17:12:18 maxamillion: "Why I'm excited"? 17:12:27 jzb: ah, ok ... I was going to talk about something different 17:12:37 wait 17:12:46 jzb: +1 17:12:48 are we discussing python 17:12:54 we are 17:12:58 yes 17:13:05 As loathe as I am to fatten the Atomic image 17:13:08 ok. I need to follow up on this ticket and close it 17:13:12 it seems ... bad to not have Ansible support. 17:13:21 and I would have said that *before* the thing 17:13:21 this ticket is in regard to the cloud base image 17:13:27 ah 17:13:29 sorry :-) 17:13:30 same applies. 17:13:34 dustymabe, I am okay in putting the packages in. 17:13:41 as am I 17:13:51 ansible support would suck to not have on our images 17:13:51 we decided last week( when mattdm was here) to not include them 17:13:53 and to do socs 17:13:55 docs 17:14:02 dustymabe, Oh okay 17:14:06 right, that's what I was just going to say 17:14:11 dustymabe: we decided in the meeting not on the ML? 17:14:12 dustymabe, I missed it as it seems 17:14:29 I'm in favor of having the packages in there, but that was the decision 17:14:32 dustymabe, i am okay in that, but it will require a lot of messaging/docs :) 17:14:32 jzb: well the discussion was had here 17:14:35 jzb: pretty sure 17:14:51 if you feel strongly otherwise then let's open it up again 17:14:56 in the ticket this time 17:15:02 but it's not like we have much time 17:15:14 there are "workarounds" for getting ansible to work 17:15:14 hrm. 17:15:23 but they aren't great 17:15:37 dustymabe: if we've made a decision, then I dont' want to open a can of worms b/c I've been bad about attending meetings. 17:15:52 dustymabe: but I'd gently suggest in the future we have [DISCUSS] and [VOTE] threads on the ML 17:16:10 so folks who are absent can chime in and it's obvious when we're making Big Decisions (TM) 17:16:40 EOF 17:16:51 ok 17:17:07 +1 17:17:13 i mean let's face it. it would be better for the user to have ansible support 17:17:18 +1 17:17:30 but what does that mean we are doing? being different from the rest of the distro 17:17:33 is that good or bad? 17:17:39 how far does it go? 17:17:51 I'd say cloud is different from the rest of the distro - just look at cloud-init 17:17:51 better for fedora, too 17:18:12 what ever better for community 17:18:32 ok. I'll open it up on the list 17:18:41 roshi: how much time is there left? 17:18:47 I'm thinking 0 17:18:50 dustymabe: well, isn't that the point of different editions? 17:18:57 being able to be different where necessary? 17:19:00 for F23? 17:19:03 yeah 17:19:11 I thought the breakdown was we just don't have two versions of the same package 17:19:18 it's really close to "no chance" 17:19:24 lemme check 17:19:39 jzb: I don't know what you mean? 17:19:49 oh I think I know 17:19:56 dustymabe: as I understand it, it's OK for different editions to have different package selections 17:20:02 yes, we just dropped the old versions of the libraries because no deps brought them in 17:20:15 but not like, a separate version of a package like a divergent Python2 something 17:20:15 because we are python3 only now in our base 17:20:20 nah 17:20:22 it's not looking like we'll have another RC 17:20:39 where was jzb a week ago :( 17:21:11 so all F23 is losing py2 and ansible will break everywhere? 17:21:28 nzwulfin_: without workarounds.. yes 17:21:40 dustymabe: in an all day meeting with my team. 17:21:57 dustymabe: thx 17:22:02 dustymabe: sorry 17:22:10 jzb: it's ok 17:22:30 I should have sent this to the list.. but there is the ticket, so we were somewhat transparent 17:22:50 nzwulfin_, yes 17:22:58 dustymabe: indeed. I've been buried and not keeping up with cloud@ well enough lately. 17:23:01 we are planning to release updated images so we can add it back if we want to 17:23:02 * jzb hangs head in shame. 17:23:19 so we will stick with docs for now 17:23:23 yeah 17:23:29 probably deserves a fed mag post 17:23:31 that's where we're at right now 17:23:31 jzb: ^^ 17:24:29 OK 17:24:42 let's hope we can do that and they don't reject it because it's too "community focused" 17:24:45 * jzb grumbles. 17:24:47 dustymabe: can you update the ticket? 17:25:05 do we have basic docs to fix this? 17:25:12 jzb: the editors meeting is tomorrow - I'll drop a pitch for it to discuss 17:25:15 maybe we can use an ansible playbook to install Python 2 17:25:17 oh, wait. 17:25:21 you willing to write it? 17:25:39 roshi: I'm willing to help, if we have barebones instructions 17:25:47 they're in the ticket 17:25:50 OK 17:25:56 sign me up 17:26:39 #action jzb to write up a magazine article on bootstrapping if the pitch is accepted for the magazine 17:26:46 yeah the workarounds are there. basically use raw mode and set gather_facts to no 17:26:50 #action roshi to put in for the magazine pitch 17:26:54 roshi: thanks 17:26:58 np 17:27:12 #topic Updated Cloud/Atomic images 17:27:18 #link https://fedorahosted.org/cloud/ticket/94 17:27:58 related update: rtnpro wrote many unittests for the atomic images 17:28:16 and we also have the atomic command broken in the latest f22 image, missing dbus module 17:28:39 means we will be adding these as tests, and run them in autocloud in the coming days. 17:29:31 EOF from me. 17:29:45 I feel like we can update and close this ticket 17:29:54 last action on it was 5 weeks ago 17:30:14 roshi: right.. 17:30:47 I guess the only thing to ask is: does this include 2 week atomic and releasing updating cloud images (once per month) for cloud base image 17:30:58 dustymabe, I think so 17:31:00 should we create new tickets for those items as we will be addressing them very soon 17:31:15 dustymabe, mostly the cloud base image, as atomic one will happen anyway 17:31:24 \o/ 17:31:34 * roshi has been in release validation mode - so haven't kept track with all our tickets and whatnot 17:31:40 Thanks to maxamillion 17:32:02 kushal: you did all the hard work 17:32:04 ok. I'll close this one and open something new, more specific in scope 17:33:00 #action dustymabe to close ticket 94 and open a couple more specific tickets 17:34:14 since we're running shorter on time for the number of tickets we have, anyone mind if I jump right to #127? (Working with the server wg) 17:34:30 roshi: sure 17:34:39 #topic Working with the Server WG 17:34:48 #link https://fedorahosted.org/cloud/ticket/127 17:35:39 jzb: do you have any thoughts here 17:35:59 I know I do, but I'd like to hear others 17:36:04 looking 17:36:12 so, dustymabe and I were at the server meeting and said we'd come up with a proposal for this seomtime after F23 release 17:36:15 fwiw 17:36:35 dustymabe, I am not sure about what we want do. 17:36:36 roshi: did we say all of that? 17:36:39 :) 17:36:40 * want to do. 17:36:54 personally I like the cloud image being small 17:37:02 dustymabe, +1 in that 17:37:14 dustymabe: +1 17:37:18 dustymabe, and then people may install whatever they want 17:37:22 I think we should be coordinating more than we are 17:37:28 and I think it is confusing to have multiple versions of things out there 17:37:43 but I think there's still some fuzziness on what people want to spin up on an IaaS and what they want on bare metal. 17:37:45 god forbid we have to upload another set of images to ec2 17:37:52 I think the base image makes most sense as a version of the server product 17:37:57 haha, yeah 17:38:04 ppl run servers in clouds 17:38:10 (to dustymabe) 17:38:20 heh 17:38:47 jbrooks: sure. If you're doing it wrong, you can take the Scotch approach to cloud :-) 17:38:53 ppl also use cloud-init to configure the minimal images to run the services they need 17:38:56 jzb, and that is? 17:39:02 dustymabe, Yup. 17:39:13 kushal: sorry, I tried to re-coin the Pets vs. Cattle to Scotch vs. PBR 17:39:23 I think going heavy weight is the wrong approach 17:39:29 I don 17:39:33 jzb, oh :D 17:39:33 but I could be wrong 17:39:35 kushal: that is, running a specific instance you hand-configure in the cloud like you would an old-school bare metal server. 17:39:45 you *can* do it, but you really shouldn't 17:40:00 jzb, yup, because it is cloud, it can go down anytime 17:40:01 jzb: agreed. and I think almost anyone you ask will tell you that 17:40:09 dustymabe yes 17:40:16 I don't think it makes sense to brand the server product as pet-only, but if that's what it's for, then... ok 17:40:39 A server product w/o a cloud story doesn't sound very compelling to me 17:40:51 jbrooks: maybe it isn't pet only, but it probably has stuff people don't want or need 17:41:00 jzb: just because you shouldn't doesn't mean it doesn't get done ... a lot 17:41:29 maxamillion: right, but do we expect that trend to grow, or shrink 17:41:43 hopefully people are changing their mindset on how to run things inthe cloud 17:41:47 dustymabe, But don't they install that stuff if they choose to? 17:41:56 jbrooks: right 17:41:56 fwiw, on places like DO, it's likely more pet than cattle - but on EC2? probably more cattle than pet 17:41:59 but it's their choice 17:42:04 we aren't deciding it for them 17:42:05 though, 100% of my uses has been pet 17:42:18 roshi: you don't host any services do you? 17:42:19 roshi, DO is less of cloud, more of a great vps 17:42:25 OK, so I don't see why proper cloud images aren't an offering of the server wg 17:42:28 right, what roshi said 17:42:37 similar if you s/DO/Linode/ 17:42:41 right, but we put our cloud image on DO 17:42:46 or they do 17:42:48 jbrooks: "proper"? 17:42:51 jbrooks: what's proper? 17:42:51 but they still claim to be clouds and have hourly pricing like other IaaS 17:42:51 maxamillion, ^^^ yup, that is also VPS :) 17:42:59 roshi, yes 17:43:02 kushal: +1 17:43:17 and with their API, I think you can do more "cloudy" things 17:43:24 I just haven't 17:43:36 jzb, OK, any cloud images? 17:43:38 ok so let me make a statement 17:43:40 * roshi would argue that the server image should be on DO instead of the cloud 17:43:50 (but that's a digression) 17:43:51 roshi, that makes more sense 17:43:54 it would be fine for the server group to produce a cloud version of a server image 17:43:59 roshi, +1 in that 17:44:08 and we could help them out with that if need be 17:44:09 a lot of the use cases i'm seeing for "cattle" is taking a base source and turning it into something else not constantly using cloud-init to bring up custom every time 17:44:10 but I don't think it should be put before the cloud minimal image we produce 17:44:29 and it probably shouldn't be uploaded to a million different AZs in ec2 17:44:40 it would be there for the users to create an AMI out of if they want to? 17:44:48 and we could have simple docs for how to do that 17:44:55 minimal (but not too minimal) would work for most of my cases 17:45:04 I have this fundamental confusion over why the cloud wg is separate from the server wg 17:45:22 When in the cloud is a very common place for servers to live 17:45:23 wait, so the server group is going to start doing cloud stuff? 17:45:41 maxamillion: yeah I think they are interested 17:45:43 jbrooks: pets/cattle 17:45:50 jbrooks: really simple as that 17:45:55 That doesn't make sense to me 17:46:09 jbrooks, that is how people look at the cloud. 17:46:10 dustymabe: this is going to get very confusing for users and/or newcomers if we have many "cloud" products 17:46:19 maxamillion: right 17:46:19 dustymabe: especially if they come from different groups 17:46:23 Well, ok, the idea is that we must have separate pet and cattle WGs 17:46:24 kushal, jzb, I don't really buy the concept of cloud is cattle. 17:46:24 maxamillion, ture 17:46:28 For some reason 17:46:50 I would say that the right answer is "it depends on the application". 17:47:05 i think jbrooks is heading in the direction of mattdm's email 17:47:09 It's like saying: "Fedora Server: Crap for the cloud, by design" or something 17:47:17 Doesn't make sense 17:47:24 for some use cases, cloud is cattle, for some it is not. We should be be deciding that for the users. 17:47:29 that the original cloud wg product is much closer to a spin of Server than a full thing 17:47:40 for everything but enterprise level stuff, cloud will seem the same as server, aiui 17:47:48 I can point to several things that were different 17:47:48 adimania: the nice thing about the minimal image is that you can make a pet out of it if you want 17:47:52 e.g. firewall, cloud-init 17:47:56 it's minimal like that to be molded 17:48:07 minimal image 17:48:07 dustymabe, yes 17:48:08 so you can use it the right way.. or the wrong way 17:48:13 I like to start my pets as minimal images 17:48:17 but we aren't going to force it 17:48:19 dustymabe, I would love a minimal image, regardless of who produces it. 17:48:26 so you can spin up 10k of them at a time and decommission the same number simultaneously 17:48:28 jbrooks: for example, server folks insist on a firewall 17:48:28 adimania: :) 17:48:32 adimania, not about who produces it. 17:48:37 jbrooks: that makes zero sense on AWS 17:48:38 dustymabe: right, but who decides what "right" and "wrong" is? 17:48:50 maxamillion: it's arbitrary 17:48:50 but I still won't think that all cloud is cattle. 17:48:52 adimania, but more about being minimal and made for IAAS systems. 17:48:58 a standard server image is not going to have cloud-init 17:49:00 jzb, And disabling it calls for a whole other WG? 17:49:01 which means making something that can be used in both ways works well 17:49:03 dustymabe: right 17:49:04 which is what we have done 17:49:14 jbrooks: no I'm explaining where we diverge. 17:49:33 * linuxmodder late 17:49:33 jbrooks: server WG has focused on roles that are traditionally "pets" 17:49:42 jzb, I see that there are some differences, but I think they're trivial, and we're taking potential focus from atomic 17:49:44 Rolekit is a major focus for server 17:49:58 And we're saddling the server product w/ an unattractive, limiting scope 17:49:59 previously that had taken the form of package sets for things like FreeIPA 17:50:14 jzb, may be server wg can focus more on how to enable those roles on cloud images, and so on. 17:50:25 kushal: except those roles don't make sense for cloud scale apps 17:50:35 they're still targeting single-server profiles. 17:50:40 jzb, I hope there will be some :) 17:50:41 It is, for instance, a major "con" that the server wg doesn't offer a minimal image 17:50:48 Their competitors do 17:51:04 jbrooks: don't they have a netinstall? 17:51:16 jzb, yeah, they do 17:51:44 granted, their netinstall is pretty chubby 17:51:57 448MB 64-bit, 32-bit 510MB 17:52:06 we need 5 minutes for the openspace, both /me and maxamillion have something to talk :) 17:52:15 netinstall? which distro are you talking abuot? 17:52:15 s/openspace/open floor 17:52:27 jzb: how much of that is the systemd dep chain? 17:52:29 ok so 3 more minutes on this 17:52:38 jzb: not trolling, genuinely curious 17:52:40 PROPOSED: we set up a meeting with server and discuss plans for F24 & F25 17:52:50 maxamillion: unclear, I'm just looking at download size ATM 17:52:55 jzb: fair 17:52:58 jzb: +1 17:52:58 we're not going to decide this her 17:53:00 here 17:53:02 jzb: sometime after F23 release 17:53:23 If cloud wg is to start being about atomic, and server wg wants to start being more about cloud... then it makes sense to relocate the base cloud image to server wg, is my view 17:53:24 side note 17:53:27 should probably have council members there too, to weigh in on this 17:53:35 right now we're still not paying enough attention to the docker image either 17:53:40 it's way fatter than it needs to be. 17:53:53 if atomic becomes the new WG, docker images will get more love 17:53:56 I'm sure of that 17:53:56 jbrooks: except the server wg hasn't really focused on cloud in the past 17:53:58 +1 17:54:07 It's a hole for them 17:54:22 let's carry this discussion to the ML and then set up a post-F23 meeting with the right folks in the virtual room 17:54:24 Who do they compete with, and what do those rivals offer? 17:54:25 so they ask for it and we give it to them.. but we still care about it 17:54:33 sounds good to me jzb 17:54:36 and now there are people inthat WG that don't care about cloud at all 17:54:40 We care about all the fedoras of the world 17:54:58 #action after F23 GA, jzb to schedule a meeting between the groups for a strategy discussion 17:54:59 #action jzb to start discuss thread on cloud/atomic/server wg stuff 17:55:08 dustymabe, I still think base should be under this WG 17:55:14 kushal: me 2 17:55:24 I don't disagree that there could be an Atomic WG 17:55:30 #topic Open Floor 17:55:32 maybe that's what we need then 17:55:37 maxamillion, go ahead 17:55:41 sorry to cut it short there, but in the interest of time... 17:56:06 I would like to request interested parties please review and offer feedback about the Layered Image Build Service's Functional Requirements, mattdm started a thread about it here: https://lists.fedoraproject.org/pipermail/cloud/2015-October/005992.html 17:56:10 that's all I had, thanks! :) 17:56:36 we will be automatically filling bugs/tickets to trac any failed image from autocloud, this will be a separate service. We can do this on fedora cloud trac, but that will increase the number of emails to the list 17:56:44 or we can trac the issues in pagure. 17:57:09 Just wanted to know if people here have any preference. 17:58:00 Anyone ^^ 17:58:04 Trac vs Pagure 17:58:13 kushal: we would probably need to get notified one way of the other 17:58:14 * maxamillion votes pagure 17:58:16 still kinda hazy on the relationship between the separate bits but seems atomic should have its own WG but still work in concert with the Server stuff as a whole 17:58:24 but that's just personal preference and I'm fine with trac 17:58:29 dustymabe, yup, 17:58:34 maxamillion, I am also in for pagure 17:58:37 so either way works 17:58:45 can we get notifications with pagure 17:58:45 cool, pagure that is :) 17:58:48 pagure seems more approriate to me 17:58:48 dustymabe, Yes 17:58:48 linuxmodder: yep 17:58:56 ok sounds good 17:58:57 pagure \o/ 17:59:10 I would go with pagure 17:59:22