15:01:07 #startmeeting kuryr 15:01:08 Meeting started Mon Feb 29 15:01:07 2016 UTC and is due to finish in 60 minutes. The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:12 The meeting name has been set to 'kuryr' 15:01:21 hi 15:01:30 Hello everybody and welcome to another kuryr weekly meeting 15:01:34 Hello! 15:01:35 hi 15:01:39 apart from banix, who's here? 15:01:56 me 15:02:12 irenab: fkautz: are you there? 15:02:20 hey 15:02:48 #info banix, gsagie, fawadkhaliq, salv-orlando, irenab and apuimedo in the meeting 15:02:59 Thank you all for joining 15:03:05 let's get the party started 15:03:25 who brings the red plastic cups? 15:03:46 #topic design summit logistics 15:03:54 #link https://etherpad.openstack.org/p/kuryr-design-summit 15:04:37 In this etherpad you can see the topics that were discussed via email and a tentative list of requirements for Gal to send 15:04:45 from that list, i think we want to request 1-2 fishbowl sessions and around 5-6 work sessions 15:04:47 (thanks Gal for compiling it) 15:04:58 and hope to get it 15:05:12 gsagie: it should be Tu-Thu? 15:05:21 I am also checking how we can get a spot (if possible) in the operators summit day thanks to Salvatore suggestion 15:05:27 Most of you already commented about the topics and so on, but before gsagie sends it, iare there further comments? 15:05:42 so we can learn about mixed openstack containers production/dev deployments 15:05:43 gsagie: salv-orlando: ops presence would be great 15:05:52 we could do with more end-user feedback 15:06:02 irenab: sec checking 15:06:24 irenab: tue-friday 15:06:36 we will request friday free talks half day as well 15:06:39 gsagie: how long are fishbowl and work session slots? 15:06:45 40 minutes 15:06:48 * apuimedo can't remember 15:06:51 + 10 minutes break 15:06:58 apuimedo, gsagie sure it would be great to know how many are using kuryr and in which way 15:07:06 #info fishbowl and work session slots are 40 minute 15:07:30 salv-orlando: if the answer is more than 0 I'll be surprised, since we did not release yet :P 15:07:44 but who knows these days, people like to live at the bleeding edge 15:07:45 gsagie: apuimedo : I think it worth to send an email to the opestack-ops mailing list 15:07:57 irenab: good point 15:08:07 to track attesion prior to the summit 15:08:08 apuimedo: indeed. whuch probably begs one question on how to put together a meaningful ops session 15:08:08 gsagie: do you take that one? 15:08:15 apuimedo: yep 15:08:35 salv-orlando: I was thinking of showing something similar to what I showed on Fosdem 15:08:57 would love to learn about the use cases people are facing without Kuryr as well, just understand what the common ways to deploy and connect between the two environments , maybe we can get some priorities depending on problems 15:08:58 but in this case, swarm bare metal alongside OSt and communication between conts and VMs 15:09:35 #action gsagie to prepare a proposal/email to the ops list detailing what we'd like to show and try to get some feedback 15:09:37 apuimedo: and nested case too 15:09:37 gsagie: +1 15:10:18 so the numbers of 1-2 fishbowl + 5-6 work sessions sounds ok? 15:10:26 and Friday 15:10:28 ok, to close this agenda point, I'd like it if we could maybe agree that each session should probably only get one topic and we should try to decide which should be fish bowl and which work sessions 15:10:56 (can be done offline in the etherpad by voting with your name next to the point) 15:11:05 apuimedo: probably after the slots are confirmed? 15:11:07 like for example: 15:11:31 Documentation: fishbowl (toni) worksession() 15:11:51 irenab: well, I want to see what kind of discussion people feel we should have on each item 15:12:14 the main difference is? 15:12:24 talking versus coding? 15:12:42 I feel like in working sessions it is a bit less directed 15:12:47 the agenda 15:13:09 apuimedo: i think we can get some good progress on small groups of work sessions (i dont expect too much people anyway) 15:13:23 Agreed 15:13:30 and we need to return an answer this week 15:13:35 regarding our request 15:13:57 gsagie: so maybe its more about big/smaller rooms? 15:14:05 for fishbowl I was thinking about early planning things like mesos and horizon integration 15:14:06 i think 5-6 sessions and Friday is more then enough (and probably we will not get more) 15:14:16 gsagie: sounds good 15:14:19 moving on 15:14:59 irenab: yeah, i dont think we really need the big rooms, maybe just 1-2 session for road map and requierments discussion which we might want more people 15:15:00 #action gsagie to send the rooms request. Last chance today for people to add stuff to the etherpad :-) 15:15:16 okie great 15:15:30 #topic Kubernetes integration 15:15:50 apuimedo: let me update here 15:15:58 I was gonna ask you anyway 15:16:01 #link https://review.openstack.org/#/c/281132/ 15:16:22 I pushed the initial spec, early draft and will send update with more details and adress the comments 15:16:50 irenab: Do you think it could benefit from the diagram I made yesterday for the prototyping we are doing? 15:17:07 We had chatwith gsagie yesterday and sent email to the k8s-sig-network regarding the concerns we had 15:17:21 cause if it does, you can freely copy it over :-) 15:17:49 apuimedo: Lets sync offline and the answer is probably yes, but I want to flash it out a bit more 15:18:02 *flesh :P 15:18:07 alright 15:18:17 initial intent is to focus on requirements and discuss the translation from k8s to neutron models 15:18:27 apuimedo: sorry, typing to fast 15:18:44 apuimedo, irenab: i looked at the diagram and think it makes sense, at least it solves most of the problems i could think of that we talked with irenab 15:18:48 it just has a very special meaning to flash things out :D 15:18:55 would be great to get it in Kuryr repo as well 15:18:58 irenab: ok. My intention is to then send two specs 15:18:59 and start discussion 15:19:08 (not necessarily myself) 15:19:10 heh :) 15:19:21 one for the CNI driver 15:19:26 one for the API watcher 15:19:47 that will answer the requirements of the spec you sent irenab 15:19:52 apuimedo: gsagie : I think it makes to capture all piece at high level in the spec and add devref for the details 15:20:09 btw, sorry for raising this now, but Kuryr is going to be mentioned in ONS (by Eshed Gal Or) in this talk: http://ons2016.sched.org/event/67nA/container-based-dynamic-service-chain-using-distributed-sdn-pipeline-injection-openstack-dragonflow-kuryr-eshed-gal-or-huawei?iframe=yes&w=&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no 15:20:23 if anyone is going.. 15:20:36 gsagie: I did not know ons was still a thing ;) 15:20:39 gsagie: this is on the community updates agenda point ;-) 15:20:50 I'll bring it up later and we add it as a link ;-) 15:20:58 salv-orlando: heh same.. 15:21:03 irenab: I'm not sure I got it completely 15:21:14 ah, ok, now I got it 15:21:29 you mean that those two sections should be devref instead of spec 15:21:37 apuimedo: yes 15:21:37 I'm more than fine with it. Good idea :-) 15:21:51 #action apuimedo to send API watcher as devref 15:22:02 #action devvesa to send CNI driver as devref 15:22:13 #action all to review the current spec 15:22:27 anything more about k8s before we move on to nested? 15:22:43 apuimedo: I think that is all atm 15:22:45 not from me, but they are obviously also related :) 15:22:51 cool! 15:23:01 #topic VM-nested containers 15:23:02 I think banix and the team also play with k8s 15:23:18 indeed. I was hoping mpreitzer would also be in the meeting 15:23:24 yeah, actually would love to get banix and IBM team thoughts about the Kubernetes integration 15:23:37 but we can continue engaging in the spec, I think he made a few comments 15:23:41 and how they see it, but i guess we can also iterate on the review 15:23:47 i believe mike has a prototype running 15:24:02 using libnetwork? 15:24:05 fawadkhaliq: the floor is yours (thanks for addressing all the comments, I'll try to review it today) 15:24:12 apuimedo: thanks 15:24:13 we will comment on the review 15:24:14 irenab: yup, using libnetwork 15:24:22 banix: thanks 15:24:27 #link https://review.openstack.org/#/c/269039/9/doc/source/specs/mitaka/nested_containers.rst 15:24:28 irenab: yes. 15:24:33 so the spec is updated after all the comments. thanks for the review everyone 15:24:45 we got reviews from Magnum team as well 15:24:47 * apuimedo has been bad lately with getting to it 15:25:11 Now action item for all of you to review the current version so we can close on it soon 15:25:13 :-) 15:25:16 yes, it was great to see hongbin and adrian joining in 15:25:35 #action apuimedo and all to review the spec! 15:25:41 fawadkhaliq: great will do it today/tommorow but i also want to wait so we get approval from the Magnum guys before we merge it 15:25:53 maybe ping Adrian/Daneyon to review it 15:25:57 next steps would be to start hashing out details about the Kuryr Agent. 15:25:59 fawadkhaliq: gsagie: maybe we can... 15:26:02 #link https://blueprints.launchpad.net/kuryr/+spec/kuryr-agent 15:26:05 yup, nagging them a bit :-) 15:26:07 fawadkhaliq: can the implementation start based on the VLAN aware VM support progress? 15:26:14 gsagie: agree and makes sense 15:26:38 fawadkhaliq: are you going to use vlan aware VM or the binding profile for starting out? 15:26:43 irenab: I will have to evaluate the current status of VLAN aware VMs and will comment on this 15:26:55 I am hoping VLAN aware VMs 15:27:06 very well 15:27:15 if not, then binding profile could be for the used until, I will check and comment 15:27:34 fawadkhaliq: apart from reviews, is there any tasks you'd like to create or get help with? 15:28:00 do we know the status of vlan-aware vm work? 15:28:11 apuimedo: I think at this point, I will involve you, gsagie, irenab in the agent discussion 15:28:13 beyond the spec that is 15:28:30 very well fawadkhaliq. You got that ;-) 15:28:41 apuimedo: nothing else so far. will let you know, thanks 15:29:02 thats all on the nested containers today 15:29:09 banix: i am not aware of progress, but maybe i missed it 15:29:18 banix: I got the sensation from russellb's comment that "in the meantime we could use the binding profile" 15:29:25 banix: I will send an update on the current progress 15:29:32 that it probably will be some time until it is functional in devstack 15:29:34 * russellb looks up 15:29:34 apuimedo: please assign an action item to me for that 15:29:51 #action fawadkhaliq report on vlan aware VMs progress to the ML 15:29:56 vlan-aware-vms is in progress. the OVN plugin has an OVN specific binding profile that can be used now, yes 15:30:13 there are initial vlan-aware-vms API patches up for review now 15:30:26 marked WIP last i checked though 15:30:30 russellb: thanks, will check out the binding profile mechanism 15:30:32 so might be early Newton cycle work 15:30:44 russellb: thanks a lot for checking in! 15:30:47 the OVN binding profile mechanism is here: http://docs.openstack.org/developer/networking-ovn/containers.html 15:31:00 fawadkhaliq: can help you with that if you need 15:31:09 russellb: who is working on the implementation now? 15:31:26 vlan-aware-vms patches: https://review.openstack.org/279253 https://review.openstack.org/279251 https://review.openstack.org/281723 https://review.openstack.org/283407 15:31:27 #link OVN binding profile mechanism http://docs.openstack.org/developer/networking-ovn/containers.html 15:31:38 also related to vlan-aware-vms work https://review.openstack.org/273954 15:31:52 #link https://review.openstack.org/273954 15:32:04 link https://review.openstack.org/279253 15:32:10 #link https://review.openstack.org/279253 15:32:22 and so on :P 15:32:27 thanks russellb 15:32:29 np 15:32:34 moving on to the next topic 15:32:48 banix, your time has come 15:32:56 #topic Existing network reuse 15:33:14 so I tried a couple of approaches 15:33:35 One that keeps using Neutron network name to store the Kuryr network ID 15:33:35 apuimedo: can you please post the link to the agenda? 15:33:54 irenab: yes 15:34:06 https://wiki.openstack.org/wiki/Meetings/Kuryr#Meeting_February_29.2C_2016 15:34:06 which requires updating the neutron network name in the cases where we use existing networks 15:34:31 banix: did you try the new description field? 15:34:44 In my opinion this is reasonable as a stop-gap measure until we have tags in Neutron 15:35:00 apuimedo: i thought hat is not there yet but if there will try 15:35:04 banix: there is the patch about adding descriptions to neutron objects, which can be used in the meantime as well 15:35:14 its not merged yet 15:35:26 yeah thats what i saw last 15:35:30 but it has the chance to be faster then the tags 15:35:33 I also played with using a kv store 15:35:36 banix: I agree, as long as we change to descriptions/tags in the near future, I'm happy to take it 15:35:48 banix: probably will be good to also update https://review.openstack.org/#/c/254005/ 15:35:53 thats the spec Taku started 15:35:56 which works but opens up a whole new set of things to consider 15:36:09 banix: if possible, I'd avoid that 15:36:17 gsagie: yes i promised to update it but haven’t done so; will do today 15:36:24 apuimedo: i agree 15:36:27 banix: which approach did you go for? 15:36:29 banix: about the kv store usage, what are your findings? 15:36:46 schedule a task after returning control to docker that goes and updates kv? 15:36:57 Using consul as kvstore is rather trivial 15:37:14 I suspect other choises wont be much more difficult either 15:37:19 (I had thought of doing that for updating neutron name once we have tags descriptions to give nice neutron names to the kuryr created nets 15:37:27 ) 15:37:43 banix: but this adds another dependency 15:37:48 i keep the kuryr is and neutron id as a kv pair in the store 15:37:54 irenab: agree 15:38:10 and if we want to do it properly need to support various kvstores etc 15:38:23 banix: or use something like libkv 15:38:31 but that is just Go 15:38:33 :/ 15:38:36 banix, irenab: but it seems this is just a stopgap measure until neutron has tugs 15:38:41 and it break the initial goal of being stateless 15:38:57 so considering tags are going to be there i thin it is not worth going the kv store path 15:39:07 banix: agreed on my part 15:39:10 banix: +1 15:39:15 so why worry too much. at the end of the day kuryr is still in an experimental phase. I think it's ok to use consul and then throw it away once neutron tags are available 15:39:36 I call for a vote 15:39:45 on which stopgap measure to go for 15:40:00 unless, of course, there is reasonable certainity that neutron will have tag support in mitaka 15:40:15 gsagie: can you update on this? 15:40:16 those in favor of "name changing" say name, those in favor of kv say "kv" 15:40:23 i believe neutron wont have tags in Mitaka 15:40:31 banix: I agree 15:40:33 banix: I believe that too 15:40:33 and description? 15:40:49 I believe there will be description, but I'm an outsider :P 15:40:52 I am for kv. I don't like mangiling with strings 15:40:54 irenab: no description; just flip a coin :) 15:40:55 name 15:40:56 irenab: someone else took the implementation of the spec 15:41:00 the spec itself is merged 15:41:12 I can ask him for the status and update next meeting 15:41:57 I am agains the name but see additional burden of kv store 15:42:26 irenab: I count that as kv 15:42:31 gsagie: yes, please 15:42:35 gsagie: what's your take? 15:42:40 fawadkhaliq: you too 15:42:44 apuimedo: not, I prefer avoid the vote :-) 15:42:50 irenab: too late :P 15:43:03 apuimedo: i think we need to talk with the person that is going to use it 15:43:04 apuimedo: kv is lessy hacky 15:43:10 if the name change is fine 15:43:13 I count on banix to make the best choice 15:43:19 irenab: +1 15:43:39 lets keep it simple until we have tags or description 15:43:45 irenab: thought you had better judgement :) 15:43:47 i feel that the description could be merged soon 15:43:57 ok 15:44:17 name* 15:44:17 let me checkout the description patch and see where we can go from there 15:44:33 I do not want kuryr to modify something that user defines, but as a temporary solution probably ok 15:44:42 #action: banix to work on using name to have it working like right now 15:45:24 #action: banix to continue investigation of replacing it with description/tags/kv for release time 15:45:28 i dont mind either solution banix picks :) they are the main first user of this anyway 15:45:32 is that right? 15:45:40 I mean, the action points? 15:45:42 sounds good 15:45:44 banix: I beleive in you :-) 15:45:46 sounds good to me 15:45:54 we all do :) 15:45:56 banix: anything you could use some help with? 15:46:20 no, I am good 15:46:25 very well :-) 15:46:34 #topic Packaging 15:46:43 I was not able to move it last week unfortunately 15:46:58 but I believe this week I'll be able to get the rdo one ready 15:47:14 #link https://github.com/celebdor/rdo-kuryr 15:47:23 obviously it is not in the kuryr repo 15:47:41 it should end up living on https://github.com/openstack-packages/kuryr 15:47:45 #link https://github.com/openstack-packages/kuryr 15:47:58 cool 15:48:11 Note that the packaging is a bit ambitious and it uses the CAP_NET_ADMIN hack not to run as root 15:48:38 so probably I'll have to patch the binding scripts not to drop the privilege 15:48:56 any questions about the packaging? 15:49:15 (besides, when will you finish, darn it?! 15:49:16 ) 15:49:17 any progress on the Kolla+OVS ? 15:49:23 dont know if its related 15:49:24 I saw the blueprint for Kola integration was pushed out of Mitaka, Hui Do you have any updates? 15:49:32 HI 15:49:39 I have some work on containerization 15:49:56 #link https://review.openstack.org/#/c/279320/ 15:50:04 If kuryr requires consul, we need add consul to kolla first. 15:50:12 Hui: are you starting from there or is there somewhere else we could look at? 15:50:21 I have some old patch in kolla, but has not merged 15:50:22 Hui: so far we don't need consul :P 15:50:30 ok, i see 15:50:32 Hui: can we get a link for that? 15:50:49 Hui: does kolla have etcd? 15:50:50 apuimedo: we need a kv store for docker irtself 15:50:56 no etcd in kolla 15:50:59 we need either consul, etcd or zk 15:51:12 Hui: banix: which do you think is easier to add? 15:51:24 I prefer consul as we have some existing work on it 15:51:28 consul clusters easier 15:51:35 guys, any spec/doc/launchpad on this task? 15:51:37 Hui: ok, go for it! 15:51:37 but etcd should also be straitforward 15:51:46 sure, let me add that to the kolla bp 15:51:59 link can be helpful 15:52:36 https://blueprints.launchpad.net/kolla/+spec/kuryr-docker-plugin 15:52:46 #link https://blueprints.launchpad.net/kolla/+spec/kuryr-docker-plugin 15:52:48 Hui: thanks 15:52:56 my pleasure 15:52:59 #topic Rally and fullstack integration 15:53:16 gsagie: are you taking this point? (got only 4 minutes) 15:53:29 Baohua is working on this 15:53:29 https://review.openstack.org/#/c/265105/ 15:53:38 #link https://review.openstack.org/#/c/265105/ 15:53:39 keeps failing for testing containers 15:53:46 will need to check it 15:53:48 #action apuimedo review https://review.openstack.org/#/c/265105/ 15:54:07 dont know if the problems are related to the python client 15:54:11 #action gsagie to check the patch to try to dig out the issues 15:54:12 or to the use 15:54:18 k 15:54:34 any other thing about rally? 15:54:41 not at this point 15:54:53 once we get this working we can add more rally tests 15:55:02 #info: as we start implementing specs (like re-using neutron nets) please, add integration tests 15:55:10 right! 15:55:21 #topic community and other topics 15:55:50 http://ons2016.sched.org/event/67nA/container-based-dynamic-service-chain-using-distributed-sdn-pipeline-injection-openstack-dragonflow-kuryr-eshed-gal-or-huawei?iframe=yes&w=&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no 15:55:55 #link http://ons2016.sched.org/event/67nA/container-based-dynamic-service-chain-using-distributed-sdn-pipeline-injection-openstack-dragonflow-kuryr-eshed-gal-or-huawei?iframe=yes&w=&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no 15:56:00 for the people going to the bay area :) 15:56:04 for ONS 15:56:19 there is going to be a kuryr talk in the bay area :-) 15:56:38 we have to cover the globe all the way down to Milwaukee 15:56:41 :-) 15:57:00 anybody else has other news or questions? 15:57:38 apuimedo: I think maybe for next meetings there should be some bug overview at agenda 15:57:55 irenab: excellent point! 15:58:26 people can add links and ask for review 15:58:32 #action gsagie apuimedo to add to the next meeting agenda bug scrubbing 15:58:59 most likely gsagie since I always forget about writing the agenda down :P 15:59:05 nice idea! 15:59:10 we need to review bgs on launchpad, assign level, etc 15:59:19 yes 15:59:20 i did some a couple of weeks ago 15:59:36 maybe we could rotate it among the cores every week 15:59:41 the bug scrubbing 15:59:53 yup 16:00:03 apuimedo gsagie let me know if you guys need help with that. Will be happy to help. 16:00:12 +1 16:00:38 Sukhdev: must be behind the door :) out of time 16:00:43 fawadkhaliq: oh yes, sorry. I didn't mean to close it down to the cores 16:00:56 banix: lol 16:00:57 banix : I am here - waiting :-) 16:00:58 here we're all in the same standing :-) 16:01:05 #endmeeting