15:01:16 #startmeeting interop_challenge 15:01:16 Meeting started Wed Dec 7 15:01:16 2016 UTC and is due to finish in 60 minutes. The chair is topol. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:18 o/ 15:01:20 The meeting name has been set to 'interop_challenge' 15:01:27 o/ 15:01:27 o/ 15:01:33 o/ 15:01:33 Hi everyone, who is here for the interop challenge meeting today? 15:01:33 The agenda for today can be found at: 15:01:33 #link https://etherpad.openstack.org/p/interop-challenge-meeting-2016-12-07 15:01:35 We can use this same etherpad to take notes 15:02:00 o/ 15:02:18 #topic review action items from previous meeting 15:02:35 #link http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-11-30-15.00.html 15:02:51 o/ 15:02:51 all, please use #link https://etherpad.openstack.org/p/interop-challenge-postmortem for lessons learned doc and add content 15:03:03 So did anyone add some content here? 15:03:30 I know its hard to find time to do this but please do your best. 15:03:36 * markvoelker added some a while bc 15:03:42 *back 15:03:45 cool 15:03:59 Do you feel like an old school marm, topol? 15:04:19 I'll give it until next meeting and we can then all look at it together :-) 15:04:35 Rockyg I taught a class or two way back when... 15:04:40 Chiding the recalcitrant children ;-) 15:04:55 dinosaurs roamed the earth 15:04:55 Oh, I can imagine it... 15:05:31 So hopefully everyone saw we got our repo! YAY! 15:05:36 which brings us to 15:05:38 tongli to migrate doc to repo when ready 15:05:45 should we reformat that etherpad into a lessonslearned.rst in our repo? 15:06:07 Im taking tongli to a fancy lunch today so no guilt on harassing him on todos! 15:06:12 our repo is ready and ansible and terraform scripts all have been migrated over. 15:06:20 tongli I think so! 15:06:24 seems like we have enough content to make a start 15:06:33 we have a doc directory where I think we should start using the folder for docs like this. 15:06:49 @markvoelker, @topol. cool. 15:06:59 I will take a first stab and put up a patch set. 15:07:10 for the doc, then we can review and add more stuff over the time. 15:07:17 Ok, so folks let's not add any more content to the etherpad version. Let's let tongli push a patch with an rst 15:08:01 #action tongli to push the our postmortem doc as a patch to the new repo! 15:08:05 o/ 15:08:14 * gema is at a sprint, sorry for the delay 15:08:26 tongli hopefully you are finding reviews are getting done quicker. 15:08:38 totally, day and night. 15:08:46 yay! 15:08:48 thanks to all the reviewers. 15:08:57 That's the important part 15:09:24 BTW, are we using standard OpenStack core reviewer rules? need two reviews from other than the author to +2 before someone can +A 15:09:49 and not all reviewers from the same company as the author 15:09:54 everyone okay with those? 15:10:06 sure 15:10:09 yes 15:10:10 @topol, we should. yes. 15:10:18 yup 15:10:44 #agree Standard OpenStack core reviewing guidelines are in effect for the new interop repo 15:10:57 next item 15:11:08 markvoelker to review user survey to look for more possible work items to add to doodle poll 15:11:17 markvoelker any luck? 15:11:27 Yeah, I took a look around. 15:11:34 any gold nuggets? 15:11:35 We already had some container and NFV stuff on our list 15:11:42 K 15:11:44 Other than that, some other areas of interest included: 15:12:05 bare metal (probably not a good candidate on account of how few clouds support it) 15:12:22 good point :-) 15:12:45 hybrid cloud (this is something we might be able to showcase partly through tooling...e.g. can part of a workload run on OpenStack and part on something else, or parts on two different openstack clouds, etc) 15:12:54 @markvoelker, I would love to try some of bare metal, bringing ironic in the picture. 15:12:58 PaaS (we mentioned CloudFoundry already) 15:13:28 IoT (this could be done mostly as "the app that rides on top of OS"...e.g. maybe we spin up a ZettaJS service or something) 15:13:34 yeah, I like that as well. all openstack clouds or openstack and microsoft or aws? 15:13:39 tongli you could try bare metal as an incubator to investigate 15:13:42 And finally hardware accelerators, whcih again may not be a real good candidate 15:13:58 federation....but usually that's not a tenant cloud-tenant cloud thing 15:14:10 i.e. multicloud 15:14:16 among these 3, I think hybrid sounds sexy. 15:14:29 sounds like a lot of stuff we could add to the doodle poll 15:14:34 ok, multicloud == hybrid? 15:15:10 I'd probably say hybrid and IoT are viable options for the doodle poll. We'd probably want to flesh them out a bit though, particularly hybrid. 15:15:30 kinda. but openstack to openstack other vendor 15:16:17 and usually geo location spaced 15:17:25 not sure if OS + AWS (or Microsoft) is an option. 15:17:25 IoT is a little bit too broad 15:17:54 we need to have some we for sure can complete during the upcoming cycle 15:17:57 @zhipengh, right. need a bit more specific. 15:18:12 tongli using Juju we can deploy to OS + AWS 15:18:20 and it needs to be attractive as well. 15:18:54 that would be cool. 15:19:21 i think play with oak-tree and tricircle for multi-cloud, could be attractive :P 15:19:48 My guess is we should have one that we all start with first that is pretty solid. and at the same time have others as incubators where individual folks could investigate those 15:19:55 does that make sense? 15:20:11 that too ;-) but oaktree is just starting, so not sure this cycle would work for that. 15:20:45 So if someone is excited about IOT or bare metal I dont want to stop them even they might take some time to bake 15:21:20 or oak-tree for that matter 15:21:31 yeah, get it done in two cycles if need more time. 15:21:48 ++ 15:22:28 oak-tree is based on shade. 15:22:32 so even if the doodle poll doesnt come back with your favorite feel free to do it as an incubator. I think we need to start with one that we feel we can all do 15:22:42 if we do not like shade, why should we like oak-tree? 15:22:56 I like shade :-) 15:22:59 I thought someone has asked to fall back to OS Rest APIs. 15:23:21 @topol, I know, just saying that there are people seem really dislike shade. 15:23:36 if oak-tree is built on top of shade, would it be even worse? 15:23:43 I think shade is covering up some uglies that people wish were fixed 15:24:07 oak-tree just is like shae but allows you to bind to multiple languages besides python 15:24:14 @topol, I am just very skeptical about oak-tree. that is what I am trying to say. 15:24:25 ++ arch wg is going to try to shine some light on that. anyone interested, come and join the fun 15:24:46 tongli, its like everything else. feel free to doubt until the code talks :-) 15:24:56 haha, yeah. 15:25:05 I would view it as an incubator option 15:25:24 ok, we got a quite big candidates pool now, I think. 15:25:37 so let's review the candidate pool. 15:26:10 1. Cloud Foundry 15:26:11 Cloud Foundry, Kube, NFV, IOT, Bare Metal, 15:26:15 2. NFV 15:26:22 oh, ok. 15:26:27 keep going tongli 15:26:31 your way better 15:26:38 hybrid/multi-cloud 15:26:46 ok. 15:26:51 1. Cloud Foundry 15:26:54 2. NFV 15:27:04 3. Kubernetes 15:27:07 need #info 15:27:14 4. Hybrid/multi-cloud 15:27:21 5. IOT 15:27:37 6. Bare Metal (or this should be a small piece of a larger workload) 15:27:47 tongli I think you are being asked to put #info before each option 15:28:16 specifics of each? 15:28:28 ++ but I think this is liely good enough to start 15:29:24 trying to give a list to @markvoelker for his doodle pool. 15:29:59 so my question for things like IoT and Bare Metal, how close are we to having automated workloads 15:30:29 @topol, not close in my view. 15:30:54 Ideally we pick something where we think we can get to having automated scripts for everyone to try in a few weeks 15:30:59 agreed 15:31:14 otherwise the options should be placed in incubator 15:31:21 are we talking about real baremetal here or some simulated stuff (e.g. pxe-ssh)? 15:31:47 skazi_ good question 15:31:56 I dont even know 15:32:02 IMO baremetal is going to rule out a lot of clouds that don't run ironic. But I'll let my voting in the doodle poll reflect that opinion. =) 15:32:26 @markvoelker, yes. let the pool decide. 15:32:35 mixing baremetal and VMs in one cloud is a tricky subject itself 15:32:56 yes but if the poll picks something have the clouds cant support we are dead on arrival 15:33:05 err half the clouds 15:33:41 so what the goal should be? 15:33:49 poll is good for seeing what is most popular, but there maybe pragmatics we have to deal with 15:34:10 goal should be a workload we think at least has a chance of running on all the clouds 15:34:31 tongli: what happened to the dockerswarm? is this still on the table? 15:34:52 @skazi_, great question. 15:34:59 should we expand on that? 15:35:00 if we pick something we know immediately cannot run on half the workloads that does not seem intersting 15:35:19 let's add dockerswarm back to the list, @markvoelker, 15:35:28 agreed. good point 15:36:21 my guess is bare metal perhaps should be incubator if it simply cant run on several clouds. It's like how we chose not to do Heat in the first round 15:36:43 @topol, agreed. 15:36:52 Besides bare metal are there any that also seem like they could not be done by everyone? 15:37:09 Just from memory: as of the April user survey less than a quarter of respondants were running ironic, and less than 10% in production. 15:37:18 Hardware accelerators might also be problematic 15:37:42 Lets keep bare metal and hardware accelerators off the doodle poll 15:37:55 Make sense? 15:38:10 ++ 15:38:28 feel free to individually play around on those as incubators. 15:38:33 for those interested 15:39:20 for the rest of the the items is there any a particular person feels could theoretically be done on their cloud? 15:39:35 err could not be done on their cloud 15:40:10 maybe we could combine couple of those options? e.g. kubernetes based pool of "simulated" IoT devices (agents) reporting some stats to central database cluster (InfluxDB+grafana)? 15:40:40 skazi_ that may be possible 15:40:56 depends how good our skills are 15:41:48 topol: as always :) 15:41:57 oooh, we could do a ddos from hacked iot devices.... 15:42:00 How about we go ahead with the doodle poll and see what shakes out from that and then evaluate as a group 15:42:07 yeah, I don't think these are all mutually exclusive. I think the poll just tells us primary focus areas vs secondary. 15:42:22 Rockyg: +1 :) 15:42:23 we need to make a decision before Christmas. 15:42:24 also who will the poll be open to? 15:42:46 if we continue discussion, we may not be able to complete a nice workload for next summit. 15:42:52 anyone in the community? Just us? 15:43:26 tongli I agree we should get the poll out, and quickly after evaluate and make a decision 15:43:33 It's a nonbinding poll, so I was just figuring we'd send it to the ML per the norm 15:43:45 markvoelker. that works 15:43:46 @markvoelker, that is right. pick a direction, and pieces here and there to make it useful and nice. 15:44:20 one can vote multiple times? 15:44:24 so who wants to create the poll? Is that on tong and brad after we goto cheesecake factory today? 15:44:25 if that is the case, it is not good. 15:44:40 tongli honor system? 15:44:49 sure. 15:44:56 do we need a concord poll? 15:45:27 markvoelker what do folks typically use for these things? 15:45:30 doodle? 15:46:00 doodle usually works fine. I don't expect it to be complicted. If you guys are going to be in a food coma I can take care of it this afternoon. =p 15:46:14 Nah. doodle good enough. But, need to advertise on multiple mls 15:46:26 Ha Ha. markvoelker. sure. its all yours 15:47:17 @markvoelker, please. 15:47:18 #action markvoelker to create doodle poll and post to ML. 15:47:34 THANKS markvoelker 15:47:40 k, next item 15:48:06 meeting channels? 15:48:11 Yeah. 15:48:11 gema ask openstack-interop if we can use the channel and check with infra if it is ok to hold meetings in a non-meeting channel, otherwise go for own channel openstack-workloads 15:48:11 Rockyg to ask ttx if we can grab #openstack-meeting at this timeslot 15:48:33 gema had a crit sit to go work but said she briefed some of you 15:48:34 So, #openstack meeting is only available every other week. 15:48:52 * markvoelker notes that there is currently a thread going about creating a new meeting channel 15:49:07 In fact, our ask got a mail thread going about another meeting channel or meeting in group channels 15:49:10 should we try and wait and grab this slot on the new channel? 15:49:35 #info thread proposing to create #openstack-meeting-5 http://lists.openstack.org/pipermail/openstack-dev/2016-December/108604.html 15:49:45 The one issur *we* have is that we shift times twice yearly for DST 15:49:54 I think we can squat in meeting-cp a little longer as long as we afent permanent 15:49:59 everyone else keeps the utc time 15:49:59 arent permanent 15:50:14 agree with that, too. 15:50:33 hmmm, so should we stick to utc time? 15:50:38 Rockyg yeah that happens to me with the keystone meeting. for us with DST thats just life 15:50:40 we should consider squatting on a single time all year long, too. 15:51:09 we got offered 1600 utc, I think. 15:51:23 on openstack-meeting? 15:51:26 And there is time at 1200 utc, just not current time 15:51:44 Rockyg is that one hour later - 1600 utc? 15:51:46 if we can grab that time for utc1600 every week, I would call to change our time. 15:51:52 Uh, not sure which room, but ironic freed up a time slot 15:52:06 lemme double check.... 15:52:21 utc1600 is 11:00am our time now, 10:00am DST. 15:52:23 can everyone meet at 1600 utc? 15:52:24 I think. 15:52:32 I can make that work 15:52:44 1600UTC is the defcore committee timeslot, so if we keep it on wednesdays I'll be out 15:52:55 then its no good ! 15:53:00 we need markvoelker 15:53:24 who else will be doing the pool. no way. 15:53:41 exactly tongli. we know where our doodle poll bread is buttered 15:53:41 no, it was later in the day.... 15:53:54 Kinda feels like the meeting channel discussion is close to being resolved...maybe we just table this discussion for one more week and see if our current time becomes available on a new channel? 15:54:08 markvoelker that sounds good 15:54:20 @Rockyg, it should be 11:00am. ours is current UTC1500. 15:54:41 let's wait and see what happens with the new meeting channel 15:54:44 which 10:00am EDT. 15:54:57 I would think utc1600 is 11:00am EDT. 15:55:08 2 more quick items 15:55:11 * markvoelker glances at the clock and notes that (speaking of the defcore/interopWG meeting) it starts in 5 minutes... 15:55:13 it mighta been 1800... 15:55:38 im gonna move quick folks 15:55:39 k. as long as we can use this channel, I am ok. 15:55:45 #item PTG meeting 15:55:57 are folks going? Tong Li and I will be going 15:56:05 * markvoelker is planning to attend 15:56:07 but, yeah. I'll post the actual options. I think we could get 1400 now, but that's 6am out here 15:56:11 do we need to ask for our own space there 15:56:18 ? 15:56:35 topol: PTG space is mostly reserved for big tent teams, so it may be difficult to get space there. 15:56:38 Yeha, I'll be there. 15:56:41 how much time at PTG do you all want to spend on interop? 15:57:05 hopefully they have some flex space 15:57:07 we can always meet at a coffee shop, or better, over beers 15:57:11 I can ask ttx 15:57:40 so let's plan on meeting a little there 15:57:48 big thanks to Christopher for setting up the new repo. 15:58:00 but folks can still focous on their primary areas 15:58:04 yay aedo! 15:58:09 #item new repo is up 15:58:17 Thanks caedo 15:58:29 ansible and terraform workloads are all moved already. 15:58:30 new repo structure is in 15:58:36 thanks tongli 15:58:40 now need a bit discussion on tox. 15:58:44 which is enabled. 15:58:51 but we can talk about that next time. 15:58:51 we only have 1 minute 15:58:55 k 15:58:57 perfect 15:59:16 #action topol ask ttx about flex space 15:59:28 #endmeeting