14:00:57 <apuimedo> #startmeeting kuryr 14:00:58 <openstack> Meeting started Mon Jun 20 14:00:57 2016 UTC and is due to finish in 60 minutes. The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:01 <openstack> The meeting name has been set to 'kuryr' 14:01:15 <apuimedo> Hi! Who's here for the kuryr meeting? 14:01:49 <tango> Hi, Ton Ngo from the Magnum team. 14:01:54 <vikasc> O/ 14:01:57 <hongbin> o/ 14:04:05 <apuimedo> irenab: ping 14:04:11 <apuimedo> devvesa: ping 14:04:16 <apuimedo> limao: ping 14:04:25 <apuimedo> just checking if we have extra people 14:04:39 <irenab> hi 14:04:41 <limao_> hi 14:04:57 <apuimedo> :-) 14:05:12 <devvesa> hi 14:05:32 <apuimedo> #info tango, vikasc, hongbin, irenab, limao devvesa and apuimedo present for the meeting 14:05:51 <apuimedo> #topic kuryr-libnetwork 14:06:42 <apuimedo> We had some issues in the past weeks with the tests 14:07:00 <apuimedo> and some questions about the container images 14:07:07 <apuimedo> let's start with the testing issues 14:07:27 <apuimedo> For those that did not see, the fullstack breakages were caused by our dependencies 14:07:52 <apuimedo> #info flask 0.11 caused some fullstack breakages 14:08:17 <apuimedo> #link https://review.openstack.org/#/c/323895/12/ 14:08:23 <irenab> apuimedo: issues are fixed and merged? or there arestill pending patches? 14:08:47 <apuimedo> #info pyroute2 0.3.x caused some breakages on trusty kernels 14:09:00 <apuimedo> #link https://review.openstack.org/#/c/331333/ 14:09:17 <apuimedo> irenab: the latter is pending a merge by the infra team 14:09:37 <apuimedo> #action apuimedo to nag the infra team so that the change is merged and the bot sends an update to our repo 14:10:39 <apuimedo> about the kuryr/libnetwork image now 14:10:53 <apuimedo> tango brought up this question the last week 14:11:32 <apuimedo> there was a question whether that is the official upstream image 14:11:56 <apuimedo> #info https://hub.docker.com/r/kuryr/libnetwork/ is the official upstream image 14:12:28 <apuimedo> which means that you can open bugs in launchpad for any possible fault it may have, like the one mentioned in the previous meeting, logging 14:12:43 <tango> Thanks apuimedo for confirming, we are integrating Kuryr with our Swarm bay, and the image is a good way to do this. 14:12:51 <apuimedo> tango: did you check if with `docker logs` it showed the logs? 14:13:08 <apuimedo> tango: that's great to hear! 14:13:26 <tango> I believe docker log show the log from the web server 14:13:45 <tango> but so far I have not been able to get the log from Kuryr 14:13:52 <apuimedo> it still is a bug if it did not go to /var/log/kuryr, so I'd appreciate if you can report the bug in launchpad 14:14:25 <tango> ok, I will double check a few more things to make sure I am not missing anything, and open a bug 14:14:41 <apuimedo> #info the container is built from contrib/docker/libnetwork/Dockerfile 14:14:46 <irenab> apuimedo: about the image 14:14:49 <apuimedo> thanks tango 14:14:57 <apuimedo> right now, the build system is terrible 14:15:12 <irenab> should not the source repo be the upstream kuryr? 14:15:20 <apuimedo> irenab: it is 14:15:28 <apuimedo> in an indirect way 14:15:30 <apuimedo> :P 14:15:31 <irenab> looks like some fork … 14:15:36 <apuimedo> it relies on a private server I have making a mirror of the changes 14:15:47 <irenab> :-) 14:15:55 <apuimedo> because to create the automated build in docker hub we must have permissions over the repo in github 14:16:00 <apuimedo> which only infra has 14:16:23 <irenab> apuimedo: so eventuleyy it will go directly? 14:16:27 <apuimedo> #info infra is planning on a generic build system for project's containers that will then be able to push images 14:16:46 <apuimedo> however, due to a lot of requirements in scale for kolla 14:16:49 <apuimedo> that may take a while 14:16:54 <apuimedo> that's why I did a workaround 14:16:55 <irenab> apuimedo: I guess soimilar needs as Kola has 14:17:06 <apuimedo> kolla has many more needs :P 14:17:07 <irenab> apuimedo: got it, thanks 14:17:29 <apuimedo> another issue with the container image is that it pulls from github when doing docker build 14:17:56 <apuimedo> it would be much better if it pulled from the repo, so you could edit the code, do docker build and you immediately got a new container with your changes 14:18:10 <apuimedo> that would require us to move the Dockerfile to the root of the git repository 14:18:36 <apuimedo> and I do not think we can do that until we move the libnetwork parts to the new kuryr-libnetwork repository 14:18:55 <apuimedo> but we will get there 14:19:29 <tango> That's helpful to know. 14:19:34 <apuimedo> #info apuimedo proposes to move the Dockerfile to /Dockerfile as soon as we move to the kuryr-libnetwork repository 14:19:44 <apuimedo> tango: any more questions about the container? 14:20:22 <tango> I am good for now. One other related question: 14:20:31 <apuimedo> tango: go ahead 14:20:56 <tango> I guess we need to run the openvswitch agent on each node along with the Kuryr image 14:21:37 <apuimedo> tango: that's right. The image contains ovs-vsctl, but the neutron ovs agenst need to run on each node 14:21:42 <apuimedo> *agents 14:21:45 <tango> I am looking at running the agent as a container also, so I wonder if anyone has tried this or if there might be any issue. 14:21:58 <apuimedo> tango: it should just work 14:22:11 <apuimedo> if both are on the host networking namespace 14:22:20 <apuimedo> if it does not. Time to ping us in #openstack-kuryr :-) 14:22:28 <tango> Sounds good, Kolla has this image, so I am hoping it will work. 14:22:45 <apuimedo> so do I 14:22:53 <apuimedo> I did not look at that kolla image recently 14:22:59 <apuimedo> but let me know how it goes 14:23:07 <apuimedo> moving on to other libnetwork things 14:23:08 <tango> Thanks apuimedo, that's all I have for now. 14:23:33 <apuimedo> #action vikasc to rebase https://review.openstack.org/#/c/331050/ 14:23:54 <apuimedo> I think the infra went to a dark place today early in the morning and it was failing everything 14:24:07 <diga> Hi, got delay 14:24:15 <apuimedo> irenab: did you have time to review that patch about the overlapping stuff? 14:24:27 <apuimedo> and by stuff, I meant cidrs :P 14:24:35 <vikasc> apuimedo, done 14:24:35 <irenab> devref ? 14:24:50 <apuimedo> irenab: the short term fix 14:24:52 <apuimedo> https://review.openstack.org/#/c/331050/ 14:24:57 <apuimedo> #link https://review.openstack.org/#/c/331050/ 14:25:07 <irenab> Ithe above one is LGTM, I was waiting to see Jenkins 14:25:32 <apuimedo> yes, that's why I asked for a rebase 14:25:37 <irenab> vikasc: thank you for adressing my comments 14:25:44 <apuimedo> let's see if jenkins runs again, otherwise let's re-trigger a re-check 14:25:51 <vikasc> apuimedo, i rebased this morning 14:26:02 <vikasc> apuimedo, i will do recheck 14:26:12 <vikasc> irenab, thanks for reviewing 14:26:49 <apuimedo> thanks vikasc 14:27:18 <apuimedo> #action apuimedo irenab to try to get https://review.openstack.org/#/c/331050/ merged 14:27:22 <vikasc> apuimedo, irenab , please review delay_neutron_ext_check also 14:27:30 <irenab> link? 14:27:36 <vikasc> https://review.openstack.org/#/c/326303/ 14:27:41 <apuimedo> #action apuimedo to review https://review.openstack.org/#/c/326303/ 14:28:28 <vikasc> apuimedo, I observed that currently config file does not work 14:28:51 <vikasc> because neutron client gets created before starting server with config file 14:28:57 <apuimedo> vikasc: I am aware :P The config file is in bad state, diga filed a blueprint to fix it 14:29:10 <apuimedo> to fix the config file, that is 14:29:15 <apuimedo> the initialization is separate 14:29:23 <apuimedo> and you are working on that, vikasc, right? 14:29:30 <vikasc> yes 14:29:50 <apuimedo> good 14:30:01 <apuimedo> it's https://review.openstack.org/326303 14:30:08 <vikasc> apuimedo, above patch is addressing this as well 14:30:17 <vikasc> apuimedo, yes 14:30:18 <irenab> do we have the mitigation policy in general for the case that neutron API server is not responding? 14:30:22 <apuimedo> I also saw, limao_ that https://bugs.launchpad.net/kuryr/+bug/1593906 was filed 14:30:22 <openstack> Launchpad bug 1593906 in kuryr "Remove mox from testing infrastructure " [Undecided,New] - Assigned to bailin.zhang (bailin-zhang) 14:30:49 <irenab> i.e kuryr restart or just failing the called method? 14:30:51 <apuimedo> irenab: the change to delay neutron checks until the first interaction should mean that you can start kuryr before Neutron is ready 14:31:12 <irenab> apuimedo: this is only part of the handling 14:31:21 <apuimedo> it will only fail once you ask kuryr to translate docker net into neutron if Neutron is not up at that moment 14:31:21 <irenab> neutron API server may stop responding 14:31:33 <irenab> or its config can be changed and restarted 14:31:41 <apuimedo> irenab: in these cases we fail operations 14:32:06 <apuimedo> devvesa: could you check https://bugs.launchpad.net/kuryr/+bug/1593906 ? 14:32:06 <openstack> Launchpad bug 1593906 in kuryr "Remove mox from testing infrastructure " [Undecided,New] - Assigned to bailin.zhang (bailin-zhang) 14:32:11 <irenab> so when neutron server is responding again, there is no check for supported extensions 14:32:23 <irenab> or the model inconsistency, right? 14:32:26 <apuimedo> we are using mox with python3 in our prototype, so I wonder what the nova people have found 14:32:27 <vikasc> irenab, hmm 14:32:35 <irenab> I will fill a bug to trace it 14:32:41 <apuimedo> irenab: good idea 14:32:59 <apuimedo> #action irenab to file a bug about reconnection and extension re-checking 14:33:25 <vikasc> apuimedo, :) 14:33:35 <apuimedo> irenab: please review limao's https://review.openstack.org/#/c/319524/ 14:33:43 <irenab> okie 14:33:46 <apuimedo> I think it is practically ready 14:34:02 <apuimedo> vikasc: you're welcome to repeat your +1 as well ;-) 14:34:14 <vikasc> apuimedo, sure :) 14:34:40 <diga> irenab: apuimedo : I am setting up my environment on fresh server, I think I should try testing all the scenarios 14:34:50 <apuimedo> diga: good 14:35:14 <limao_> Cool 14:35:16 <apuimedo> anybody else has any question about libnetwork can ask it later in #opentsack-kuryr or in the mailing list 14:35:26 <apuimedo> #topic kuryr-kubernetes 14:36:07 <apuimedo> irenab: IIUC, you have a minor objection to https://review.openstack.org/#/c/328106/ before we merge it, is that right? 14:36:30 <irenab> checking 14:37:20 <irenab> just a suggestion to be more explicit about DeLETE event. but maybe it was not clear only to me, so I am fine to proceed as is 14:37:54 <apuimedo> irenab: so please +2 :P 14:37:56 <irenab> I think the meaning is that DELETE event is not generated for the endpoits 14:38:06 <apuimedo> yeah. I also think so 14:38:20 <irenab> I hoped to get a responce and confirmation on the patch :-) 14:38:21 <apuimedo> irenab: I'd rather we get this merged and you send a patch to clarify afterwards 14:38:31 <irenab> apuimedo: good idea 14:38:45 <apuimedo> #info there's been work in the kubernetes devref 14:39:01 <apuimedo> #link https://review.openstack.org/#/c/328106/ 14:39:18 <apuimedo> this one addresses the endpoint translation 14:39:43 <apuimedo> #info further detail into the watcher and translator https://review.openstack.org/#/c/330282/ 14:40:01 <diga> apuimedo: any one working on this stuff ? 14:40:17 <apuimedo> I want to thank irenab, devvesa, tfukushima and vikasc reviews to my patch 14:40:19 <diga> after config file, I will take this in 14:40:28 <apuimedo> you are getting it much better than I originally had it :-) 14:40:35 <apuimedo> both in wording and in concept 14:40:52 <apuimedo> diga: we have quite a bit of work done in it in our prototype repo 14:41:15 <apuimedo> the most urgent task is to move kuryr libnetwork part to the new kuryr-libnetwork repo 14:41:27 <diga> apuimedo: okay 14:41:45 <apuimedo> diga: but you are welcome to help with kuryr-kubernetes as well ;-) 14:41:45 <diga> apuimedo: I will take a look at it 14:41:59 <diga> thanks apuimedo 14:42:06 <apuimedo> #action apuimedo to address the final comments to the patch 14:42:14 <apuimedo> hopefully we can merge it this week 14:42:44 <apuimedo> devvesa: am I forgetting anything about kuryr-kubernetes? 14:42:54 <apuimedo> Anybody else has any questions? 14:43:37 <apuimedo> #info once we have these two specs I think we can start bringing the code to kuryr-kubernetes repository 14:43:47 <gsagie> apuimedo: is there anyone working on moving the libnetwork code to kuryr-libnetwork? 14:43:58 <apuimedo> gsagie: not really, no 14:44:09 <apuimedo> gsagie: is that a volunteering? 14:44:16 <apuimedo> :P 14:44:19 <gsagie> you can write it on me :) 14:44:26 <apuimedo> Yay! 14:44:30 <gsagie> i do wonder what is going to stay at the main kuryr repo thought 14:44:38 <gsagie> maybe the devstack installation 14:44:46 <gsagie> and the tests 14:44:47 <apuimedo> gsagie: the library, specs 14:44:51 <irenab> sorry, got disconnected 14:44:55 <apuimedo> unti tests for the library 14:45:06 <gsagie> apuimedo: what is "the library" ? 14:45:15 <gsagie> from the code that we have now 14:45:17 <apuimedo> #action gsagie to work on splitting kuryr into kuryr (having the common library and binding) and kuryr-libnetwork 14:45:24 <apuimedo> the binding, utils 14:45:28 <apuimedo> part of the controller 14:45:34 <irenab> apuimedo: gsagie : any update on the nested containers? 14:45:37 <apuimedo> so, binding and common neutron ops 14:45:44 <apuimedo> hey, hey, hey 14:45:44 <gsagie> Need to talk with fawad 14:45:53 <apuimedo> irenab: we are on kubernetes topic :P 14:45:57 <apuimedo> let me swap it 14:46:08 <apuimedo> #topic containers-in-vms 14:46:09 <gsagie> apuimedo: ok, think i have an idea but we might need to do some refactoring in the main repo first then i can move it easly 14:46:16 <gsagie> but i will work on that 14:46:31 <apuimedo> gsagie: yes, some refactoring (specially of controllers) is in order 14:46:47 <apuimedo> gsagie: it would be good if we could use python namespaces 14:47:05 <apuimedo> so that in the end we had kuryr.libnetwork kuryr.kubernetes kuryr.cni, etc 14:47:17 <apuimedo> in pypi 14:47:34 <gsagie> yes 14:47:37 <gsagie> np 14:47:44 <apuimedo> fawad is not present, but if there are questions about the nested case 14:47:52 <apuimedo> now is the time to record them 14:47:54 <apuimedo> ;-) 14:47:55 <gsagie> well i do know that Omer was trying to reach him 14:47:56 <irenab> gsagie: I think there is some launchpad issue to trace it 14:47:59 <gsagie> to take some tasks 14:48:05 <vikasc> apuimedo, why do we need kuryr server and kuryr agent 14:48:37 <apuimedo> vikasc: the idea is that whatever makes the requests to Neutron should not be in a VM that belongs to the user 14:48:45 <apuimedo> (or tenant) 14:49:03 <gsagie> the agent is a more lightweight version that is mostly incharge of the binding at this point 14:49:18 <apuimedo> the agent should have only minimal knowledge in order to do the binding, that's right 14:49:47 <vikasc> apuimedo, gsagie .. got it 14:49:53 <apuimedo> :-) 14:49:56 <vikasc> apuimedo, gsagie thanks 14:50:01 <apuimedo> okay, moving on 14:50:01 <gsagie> i do feel it might be used when we start consider policy, but we will need to talk about it (esp for the security case) 14:50:15 <gsagie> the agent that is 14:50:18 <apuimedo> gsagie: yes, if we ever want to do policy in the VMs 14:50:22 <apuimedo> using bpf or the like 14:50:26 <gsagie> yes 14:50:29 <apuimedo> then the agent will have to smarten up 14:50:38 <apuimedo> #topic open discussion 14:50:57 <apuimedo> irenab presented about kuryr in the openstack-israel days 14:51:06 <hongbin> Back to the nested containers topic 14:51:20 <apuimedo> hongbin: yes plese, go ahead 14:51:24 <irenab> apuimedo: its Networking Day 14:51:41 <apuimedo> irenab: too many things ending up on "Day" 14:51:41 <hongbin> I remembered someone volunteer to split the BP into several subtasks 14:51:42 <apuimedo> xD 14:51:53 <gsagie> hongbin: thats fawad, he isnt here 14:51:58 <apuimedo> right 14:52:03 <gsagie> he is suppose to be in charge of the nested containers 14:52:03 <hongbin> OK 14:52:30 <hongbin> For the task spliting, is any chance to do it by another person? 14:52:42 <apuimedo> hongbin: yes 14:52:44 <hongbin> (if fawad is busy) 14:52:45 <gsagie> hongbin: do you have any volunteer on your end? 14:52:49 <apuimedo> I think at this point anybody can help 14:53:07 <vikasc> apuimedo, gsagie , I would be happy to volunteer 14:53:08 <hongbin> I might find contributors if tasks is splitted 14:53:10 <apuimedo> shooting an email to the mailing list presenting a possible breakup would be great, for example 14:53:16 <gsagie> vikasc great :) 14:53:35 <vikasc> i have some level of magnum understanding also 14:53:42 <apuimedo> I think taking it to the ML for a round of discussion would raise awareness too 14:53:45 <vikasc> not sure if hongbin remember me :P 14:53:50 <hongbin> Right now, it is hard for contributors to figure out how to contribute 14:53:52 <gsagie> vikasc: maybe you can start with splitting the work into tasks and then you can take some and maybe someone else can help with the others 14:53:56 <hongbin> vikasc: yes, I do :) 14:53:58 <apuimedo> hongbin: right 14:54:15 <apuimedo> that's why I think that a few emails in the ml can help 14:54:24 <vikasc> gsagie, sure 14:54:36 <gsagie> great thanks! 14:54:39 <vikasc> hongbin, thanks :) 14:54:41 <apuimedo> gsagie: do you mind getting the ball rolling sending a first email? 14:54:53 <apuimedo> vikasc can jump in afterwards :P 14:54:59 <gsagie> apuimedo: ok i will 14:55:01 <diga> gsagie: apuimedo : I can put some efforts in there if vikasc needs any help 14:55:03 <apuimedo> great! 14:55:24 <hongbin> thanks gsagie 14:55:35 <apuimedo> anything else in these last 5 minutes? 14:55:38 <vikasc> diga, thanks diga.. :) 14:55:51 <diga> vikasc: you are welcome! :) 14:56:10 <apuimedo> going once 14:56:21 <gsagie> \o/ 14:56:23 <apuimedo> going twice 14:56:35 <gsagie> 100$ 14:56:35 <irenab> sold 14:56:40 <apuimedo> gone! 14:56:47 <apuimedo> thank you all for your participation! 14:56:53 <apuimedo> have a nice rest of day 14:56:53 <gsagie> cya 14:56:56 <apuimedo> #endmeeting