14:05:29 #startmeeting kuryr 14:05:29 Meeting started Mon Jul 18 14:05:29 2016 UTC and is due to finish in 60 minutes. The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:05:32 The meeting name has been set to 'kuryr' 14:05:42 Hello everybody and sorry for the 5min delay 14:05:49 Who's here for the meeting? 14:05:50 hi 14:05:54 o/ 14:05:55 hello 14:06:02 o/ 14:07:36 Hello everybody! 14:07:40 thanks for joining 14:07:46 hi 14:07:54 #info vikasc limao_ tango irenab and apuimedo present 14:08:05 let's get started 14:08:21 #topic kuryr-libnetwork 14:08:57 we got a few patches merged this last week 14:09:29 #info Docker expose support was added backed by Security groups https://review.openstack.org/337746 14:10:09 #info limao corrected the test paths after the repo split https://review.openstack.org/342885 14:10:43 #info limao moved the remaining port references to our new port, 23750 https://review.openstack.org/340627 14:11:14 #info banix added support for taking hold of pre-existing unbound neutron ports https://review.openstack.org/337882 14:12:22 #info Usage of pre-existing unbound neutron ports would allow users to pre-allocate ports for deployments 14:12:45 alright, let's proceed with the stuff that is in-flight 14:13:32 #link https://review.openstack.org/#/c/340212/1 should be ready for merge 14:13:35 irenab: ^^ 14:14:02 guys, please keep link to bp/bug in the patch you submit 14:15:07 #info vikasc is working on the code refactoring 14:15:35 #link https://github.com/vikaschoudhary16/kuryr 14:15:46 that's the link to the kuryr-lib 14:16:20 vikasc: could you please address tfukushima's comments to https://review.openstack.org/#/c/326894/ ? 14:16:35 apuimedo, sure, will do. 14:17:00 thanks 14:17:41 vikasc: also, there's some -1 from limao_ on https://review.openstack.org/#/c/336784/ 14:17:52 apuimedo, that i am working on 14:18:00 apuimedo, will update soon 14:18:11 vikasc: can you link us to all the necessary patches to be able to drop your github repo? 14:18:26 I'd like to get kuryr-lib merged soon so we can start depending on it 14:18:46 if there is some work that remains to be done, we can also put it as an action point for somebody else to help 14:18:54 https://review.openstack.org/#/c/336784/ 14:18:58 this one only 14:19:34 vikasc: very well. So once you address limao_'s comments I'll try to work with Irena to get it merged 14:19:47 thanks a lot vikasc! 14:19:55 and limao for the reviews! 14:20:05 apuimedo, after this merged. requirements.txt can be pointed to kuryr repo 14:20:05 will check this vikasc 14:20:09 one quick question want to be clear about kuryr-lib, kuryr-lib will only contain common code which need by kuryr-libnetwork/kuryr-k8s? 14:20:11 exactly 14:20:20 limao: that's right 14:20:37 So we may need to update jenkins test first 14:20:56 move gate-install-dsvm-kuryr/gate-kuryr-dsvm-fullstack-nv, gate-kuryr-dsvm-rally-nv from kuryr-lib to kuryr-libnetwork 14:21:00 limao: right, somebody needs to send patches to infra to move the gates to kuryr-libnetwork 14:21:21 #action apuimedo to move gate-install-dsvm-kuryr/gate-kuryr-dsvm-fullstack-nv, and gate-kuryr-dsvm-rally-nv to kuryr-libnetwork only 14:21:24 thanks limao! 14:21:32 I keep forgetting about this one 14:21:51 we'll get it done this week for sure! 14:21:58 I've got a good feeling about it 14:22:05 :) 14:22:09 anything else about kuryr-libnetwork? 14:22:09 Another thing is what kind of folder it will be like 14:22:19 limao: please, explain 14:22:27 Is it will be kuryr-lib/kuryr_lib/XXX 14:22:40 similiar with neutron-lib? 14:22:56 or it will be kuryr-lib/kuryr/lib 14:23:35 it will be kuryr/kuryr-lib 14:23:42 I meant, repo named kuryr 14:23:49 source dir named kuryr-lib 14:24:08 sorry, kuryr_lib 14:24:14 otherwise it won't be importable : 14:24:20 :-p 14:24:55 package name we are having kuryr-lib at the moment 14:25:11 apuimedo: can you summarise your suggestion? 14:25:13 vikasc: that's the pypi package name 14:25:18 but in the code, you'd do 14:25:23 from kuryr_lib import binding 14:25:30 irenab: does that help?\ 14:26:02 apuimedo, we currently have kuryr/lib/binding.py 14:26:32 vikasc: irenab: limao: tango: what do you think about ^^ ? 14:26:44 I'm fine with having from kuryr.lib import binding 14:26:53 if you are fine too, let's keep it like that :-) 14:27:08 apuimedo, i prefer kuryr.lib 14:27:15 I'm fine 14:27:20 me too 14:27:23 apuimedo, because we will have kuryr/rpc_server also 14:27:33 but I see neutron-lib: https://github.com/openstack/neutron-lib 14:27:39 very well 14:27:56 Anyway, I'm fine with kuryr.lib~ 14:27:57 limao: because neutron split neutron-lib out 14:27:58 vikasc: so rpc_server will be separate from the lib? 14:28:05 yes 14:28:08 in our case, we split out the server :-) 14:28:16 OK 14:28:22 similar result in the end though 14:28:38 #info kuryr-lib pypi package will have the code importable from kuryr.lib 14:28:51 anything else about kuryr-libnetwork? 14:29:24 For python34/python35 14:29:41 I see a patch which support python35 14:29:58 so I enable python35-nv in kuryr-lib / kuryr-libnetwork 14:30:18 let me find the patch link 14:30:33 https://review.openstack.org/#/c/341891/ 14:31:15 #link https://review.openstack.org/#/c/341891/ 14:31:28 ah yes, I approved it 14:31:31 I notice our python34/35 is non-voting now, Do you think we can enable them in jenkins? 14:31:37 irenab: please, check that out and merge if possible 14:31:42 limao: we definitely should 14:31:52 apuimedo: will try asap 14:32:03 #action enable python34 and python35 as voting in kuryr and kuryr-libnetwork 14:32:55 nothing from me about kuryr-libnetwork now, thanks 14:33:39 very well 14:35:00 #info kuryr-kubernetes 14:35:17 sorry, that was meant to be a topic 14:35:26 #topic kuryr-kubernetes 14:35:54 #info no big news on this yet. Patches to come once kuryr-lib is merged 14:36:00 questions? 14:36:57 apuimedo: ypu may want to provide some info on already supported stuff 14:37:13 shall I do? 14:37:46 yes, please 14:38:13 just to set an expectations, current k8s kuryr fork, supports k8s services as well as pod to pod communication, including multiple k8s namepsaces 14:38:46 next is k8s policy to be supported via neutron SG groups 14:38:56 irenab: use #info 14:39:07 please check the code if you are interested 14:39:13 link please 14:39:35 #info https://github.com/midonet/kuryr/tree/k8s/doc/source 14:39:40 thanks 14:39:42 #info: it is important to note that it uses lbaasv1. It is a question whether we'll upstream with only v2 or we'll make it configurable 14:39:50 sorry, 14:39:57 #info: https://github.com/midonet/kuryr/tree/k8s 14:40:03 I guess it will depend on the devref that we all agree on 14:40:20 as we won't just dump patches, we'll all send parts, as the current stuff is a prototype 14:41:16 #topic open discussion 14:41:25 Does anybody have any other topic to cover? 14:42:00 vikasc: I wanted to ask if you could try to bring your docker pull requests back to live 14:42:03 *life 14:42:10 they are good additions 14:42:16 apuimedo, i am already planning that 14:42:28 any updates on the mascot choice ? 14:42:41 great! Thanks a lot 14:42:43 apuimedo, from now on i will just address review comments on existing patches 14:42:47 irenab: that's on gsagie 14:42:56 and will update docker pull requests 14:42:59 I'm hoping it is either teh axolotl or the platypus 14:43:06 apuimedo, tagging part i will do after that 14:43:13 cool 14:44:23 apuimedo, there has been lot of work in this split 14:44:25 vikasc: the patch for overlapping cidrs has some unresolved comments 14:44:31 indeed 14:44:32 apuimedo, specially adjusting test cases 14:44:43 do you plan to work on it or its on hold till the refactoring done? 14:44:54 irenab, minor nits only. will do very soon 14:45:07 I think it's better to solve the split first 14:45:10 vikasc: thanks, looks like a valuable addition 14:45:14 that was a lot of work 14:45:18 and we can't let it go stale 14:45:30 apuimedo: sure, agree on priorities 14:45:51 irenab, after refactoring i will track docker pull requests and once they are merged, will update overlapping cidr patc 14:45:55 *patch 14:46:10 as per the devref, which is already under review 14:46:21 vikasc: +1 14:46:35 Hi, I seem to have barged into a room at the right time :) I'm working on dplowing OpenStack using Kubernetes, and am starting to work on improving the ntworking (Using flannel atm). Does Kuryr support bare metal servers? 14:46:55 *Sorry about typos! 14:46:59 portdirect: yes, it does 14:47:11 kuryr only support baremetals at the moment :) 14:47:35 portdirect: only baremetal, right vikasc :-) 14:47:54 though vikasc is working on the nested part 14:47:58 Should it just work also for VM? 14:48:10 great! I'd got the wrong end of the stick and though you only addressed nested container :) 14:48:22 portdirect: what issues you try to solve for flannel? 14:48:27 tango: if you want to avoid double encapsulation, it doesn't just work 14:48:50 portdirect: nested containers are coming, but we are not there yet :( 14:49:00 does it make sense for you to use k8s with neutron networking to deploy and run OpenStack? 14:49:10 portdirect: ^^ 14:49:16 scaling, isolation, security groups, qos 14:49:32 portdirect: good! 14:49:34 portdirect: sound like something the neutron can do :-) 14:49:57 so it will be something like trippleO 14:51:49 Yup, but a bit more flexible :) 14:52:04 portdirect: note that we do not support loadbalancer service kind yet 14:52:22 portdirect: great, I think you can check the fork we anlready have for kuryr k8s 14:52:48 but it is coming in the prototype real soon 14:52:52 Is that the one at the midonet github? 14:52:59 https://github.com/midonet/kuryr/tree/k8s 14:53:57 apuimedo: So if I build a Swarm cluster using VM (not baremetal) and install kuryr, openvswitch agent on each node, I should be able to get libnetwork working? 14:54:18 tango: if ovs agent runs in the VMs it will just work 14:54:23 we do all the development in VMs 14:54:28 ;-) 14:54:29 tango: I think so, but you won’t use the same networking infrastructure for the containers and VMs 14:55:05 Great, that's what I am working on in Magnum, good to double check :) 14:55:20 we want to get to the point where the containers-in-vms use neutron subports 14:55:35 apuimedo, i have plan ready 14:55:36 I'll try and get that up and running this afternoon in our deve envronment - we are also using the ml2 dragonflow driver so it'll be interesting to see how that goes :) 14:55:48 portdirect: tango : it can be great if you could share the requirements as you see them for the projects you work on 14:56:28 indeed 14:56:37 anyway, it's time to wrap up 14:56:56 portdirect: you're welcome to join at #openstack-kuryr channel for further questions 14:57:05 have a nice rest of day, everybody! 14:57:10 thanks for helping :) 14:57:10 Thanks! 14:57:11 and thanks for joining 14:57:15 #endmeeting