#openstack-meeting-4 log

03:00:43 <banix> #startmeeting kuryr
03:00:44 <openstack> Meeting started Tue Nov 17 03:00:43 2015 UTC and is due to finish in 60 minutes.  The chair is banix. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:47 <openstack> The meeting name has been set to 'kuryr'
03:01:16 <banix> Who is around for the kuryr meeting at this alternate meeting time? :)
03:01:16 <vikasc> Hi everybody
03:01:23 <tfukushima> o/
03:01:24 <vikasc> o/
03:01:35 <fawadkhaliq> hello everyone!
03:02:05 <banix> #link https://wiki.openstack.org/wiki/Meetings/Kuryr#Agenda
03:02:09 <vikasc> fawadkhaliq: Hi fawad
03:02:34 <banix> Hi vikasc tfukushima fawadkhaliq
03:02:48 <banix> This may be a short meeting but that’s what we say everytime
03:02:59 <vikasc> banix: :)
03:03:01 <fawadkhaliq> lol
03:04:00 <banix> #topic Announcements
03:04:24 <banix> I updated the IRC meeting for the new time; It was incorrectly updated but that should get sorted out shortly:   https://review.openstack.org/#/c/245868/
03:04:42 <tfukushima> So obviously this is the new starting time for the alternated schedule.
03:05:04 <banix> tfukushima: yes indeed
03:05:11 <tfukushima> banix: It's already merged.
03:05:22 <fawadkhaliq> banix: great. btw, I was wondering if we should also add this information on Kuryr Wiki as well like other projects?
03:05:37 <banix> we will probably need to send another email the dev list in case there is any doubts
03:05:46 <banix> fawadkhaliq: yes indeed; will do
03:05:51 <fawadkhaliq> banix: thanks!
03:06:00 <banix> Anyone else has any announcements?
03:06:27 <tfukushima> Nothing from my side.
03:06:40 <vikasc> vikasc: not from my side too
03:06:54 <banix> #topic Action Items
03:07:21 <banix> We hade a few action items from last week as listed on the agenda; let’s go through them quickly
03:07:39 <banix> 1. gsagie to check conntrack for security groups in the mitaka cycle
03:07:45 <tfukushima> I think it's too early for gsagie and too late for apuimedo.
03:07:53 <banix> Gal is probably fast asleep :)
03:08:06 <vikasc> lol
03:08:39 <banix> but I think we know for sure the use of native OVS conntrack has not been implemented yet; Do we know if the plan is to have it included in Mitaka?
03:08:51 <fawadkhaliq> banix: i think it is
03:08:54 <fawadkhaliq> let me share a link
03:09:12 <fawadkhaliq> #link http://openvswitch.org/pipermail/dev/2015-November/062228.html
03:09:34 <fawadkhaliq> Not in Neutron ofcourse
03:10:35 <tfukushima> I'm still catching up...
03:10:42 <banix> fawadkhaliq: thanks for the link; yes the question is when that will be available through the Neutron OVS driver
03:10:45 <vikasc> vikasc: AFAIK currently ovs can lookup tcp flags only so based on that stateful conntrack can be implemented using this feature of ovs
03:11:26 <vikasc> fawadkhaliq: any idea
03:11:46 <banix> There was a blueprint and someone working on it a while back but since things had not merged on the OVS side, that work got stopped; Sooner or later that will be picked up again
03:12:09 <fawadkhaliq> Makes sense. I am not aware of Mitaka plan on this. Didn't see any discussions on the summit either
03:12:11 <vikasc> banix: seems it will take a bit of time
03:12:50 <vikasc> may be someone from team can takeup this action to explore on this
03:12:55 <fawadkhaliq> With OVN being the priority for many folks, I am not sure who will spend time porting these to existing driver?
03:13:18 <banix> Regardless, as we keep track of the conntrack, we will probably need to support Hubrid OVS plgu/unplug which leads us to the 2nd action item from last week
03:13:23 <banix> fawadkhaliq: true
03:13:40 <banix> 2. banix to work with diga on the ovs binding (with the hybrid as follow up patches if necessary)
03:13:52 <fawadkhaliq> agree with vikasc: perhaps we can take an action item and see if there is any plan. I can follow up with relevant folks. Please assign an action to me.
03:14:10 <vikasc> fawadkhaliq: great
03:14:41 <banix> fawadkhaliq: thanks Fawad; since Gal has already taken the action don’t spend too much time tracking this
03:14:54 <fawadkhaliq> banix: sounds good
03:15:26 <banix> #action fawadkhaliq to also check on the status of Neutron OVS driver use of OVS conntrack
03:15:50 <banix> Anyone has been in touch with Diga?
03:16:38 <tfukushima> banix: No. I haven't heard anything for more than a month. Have you?
03:16:39 <vikasc> negative
03:16:57 <banix> I couldn’t find him on IRC and sent him an email. If we don’t hear back in a day or so I will add the plug/unplug piece for OVS
03:17:17 <vikasc> banix: makes sense
03:17:26 <banix> #action banix to get the plug/unplug for OVS ready for review
03:17:28 <tfukushima> Ok, thanks.
03:17:29 <vikasc> thats an important missing piece
03:17:43 <vikasc> banix: thanks
03:18:06 <banix> vikasc: yes, sure. will get it in this week.
03:18:31 <banix> moving on to the next action item from last week:
03:18:47 <banix> 3. apuimedo to review validation vikasc patches
03:18:59 <vikasc> thats done
03:19:01 <banix> vikasc: Any patches left for review?
03:19:10 <vikasc> only https://review.openstack.org/#/c/241134/
03:19:14 <fawadkhaliq> vikasc: can you please share the links?
03:19:17 <fawadkhaliq> oh its here
03:19:17 <vikasc> but this is not a validation patch
03:19:18 <fawadkhaliq> thanks
03:19:24 <tfukushima> Let's talk about it later.
03:19:33 <vikasc> sure
03:19:56 <vikasc> banix: this is dhcp disable/enable one.
03:20:05 <banix> vikasc: ok sounds good; will talk about the above later today
03:20:19 <vikasc> vthanks
03:20:22 <banix> 4. apuimedo to review the external network connectivity blueprint
03:20:42 <vikasc> i guess this is pending yet
03:21:01 <tfukushima> #link the external network connectivity blueprint https://blueprints.launchpad.net/kuryr/+spec/external-network-connectivity
03:21:16 <banix> tfukushima: thanks for the link
03:21:48 <banix> vikasc: I have not looked at it yet; Others have any comments?
03:21:56 <vikasc> banix: nope
03:22:12 <fawadkhaliq> banix: vikasc: I will review it and add my comments.
03:22:21 <vikasc> fawadkhaliq: thanks fawad
03:22:52 <banix> #action All to reviewexternal connectivity blueprint  #link  https://blueprints.launchpad.net/kuryr/+spec/external-network-connectivity
03:23:30 <banix> anything else on the Action Items from last week?
03:24:43 <banix> #topic vif plug/unplug (binding)
03:24:45 <vikasc> banix: fyi..currently working on ipam implementation. will take one or two days more
03:25:03 <banix> vikasc: will get to that topic shortly
03:25:17 <vikasc> banix: ok
03:25:49 <banix> Just wanted to mention that the os-vif repository has been created: #link  https://github.com/openstack/os-vif
03:26:21 <banix> No content in it yet but I believe this is something which we will hopefully use
03:26:25 <tfukushima> I'm not familiar with os-vif but it's a tiny component takes care of the vif binding decoupled from Neutron and Nova in my understanding.
03:26:37 <fawadkhaliq> anyone aware of when the basic structure will be in place? then we can start filling in.
03:26:59 <fawadkhaliq> tfukushima: thats correct. So the vif code moves out of Nova tree.
03:27:19 <banix> tfukushima: my understanding is that it will do what Nova currently does for plug/unplug of different vif types
03:27:46 <banix> and that’s what we do in our binding directory
03:28:35 <banix> As we work on adding support for OVS, etc, we should keep an eye on the os-vif progress and remain in sync wrt the api as much as possible
03:28:48 <vikasc> banix: sure
03:29:00 <banix> regardless, we need to use the binding as we do right now until the os-vif is ready
03:29:05 <tfukushima> #link the os-vif blueprint https://review.openstack.org/#/c/193668/
03:29:23 <fawadkhaliq> banix: +1
03:29:26 <vikasc> tfukushima: thanks for the link Taku
03:30:25 <banix> Shall we move on to the next topic?
03:30:37 <tfukushima> Yes. We can catch up with it but there's no implementation so far.
03:31:32 <banix> tfukushima: yes, jay pipe has a poc kind of implementation under hit github: #link https://github.com/jaypipes/os_vif
03:32:11 <banix> so there has been some work already done but as you mention the repo is empty and it may take a while before it becomes consumable
03:33:13 <tfukushima> Let's move to the IPAM driver.
03:33:17 <banix> General discussion from the summit here: #link https://etherpad.openstack.org/p/mitaka-nova-os-vif-lib
03:33:23 <banix> #topic IPAM driver
03:33:31 <banix> vikasc: please go ahead
03:33:43 <vikasc> banix: sorry banix
03:33:46 <vikasc> need to go offline
03:33:54 <vikasc> will be back in couple of minutes
03:33:59 <vikasc> unavoidable
03:34:02 <banix> vikasc: sure
03:34:05 <banix> np
03:34:18 <banix> #undo
03:34:19 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xab0d650>
03:34:29 <banix> #topic devstack integration
03:35:08 <fawadkhaliq> #link gsagie added the DevStack plugin https://review.openstack.org/#/c/242838/
03:35:18 <banix> I see Gal had uploaded his patch. Anything we need to discuss here?
03:35:23 <banix> thanks for the link
03:35:44 <vikasc> banix: i am back :)
03:35:52 <fawadkhaliq> Toni saw some errors, I will see if I can reproduce.
03:35:59 <tfukushima> According to apuimedo, he got stuck with it.
03:36:22 <tfukushima> I reviewed it and I guess KURYR_HOME is not set appropriately.
03:36:38 <banix> yeah saw that. So let’s give it a try and see how far we go and give feedback
03:36:55 <vikasc> banix: sure.. i will also try it
03:37:05 <tfukushima> apuimedo is in DockerCon EU and showing the demo of Kuryr BTW.
03:37:18 <banix> tfukushima: cool
03:37:20 <vikasc> tfukushima: great news
03:37:26 <fawadkhaliq> good luck apuimedo!
03:37:46 <banix> I wonder if libnetwork people will …. never mind :)
03:37:57 <fawadkhaliq> banix: lol
03:38:02 <banix> yes sending good vives to Toni
03:38:15 <banix> #topic IPAM driver
03:38:23 <banix> vikasc: please go ahead
03:38:58 <vikasc> I had a small discussion with tfukushima also and implmenattion is going on.
03:39:13 <vikasc> will be submitting first patch shortly
03:39:49 <tfukushima> So vikasc is working on the "null" IPAM driver, which basically does nothing but delegate the IPAM to Neutron.
03:40:02 <banix> vikasc: is what is needed a null driver or ….
03:40:03 <vikasc> tfukushima: true
03:40:11 <banix> ok got it
03:40:13 <fawadkhaliq> thanks tfukushima i was just going to ask this
03:40:39 <tfukushima> And I found --ip-range accidentally works with the current Kuryr implementation.
03:40:50 <vikasc> tfukushima:  lol
03:40:58 <vikasc> "accedently"
03:41:04 <fawadkhaliq> vikasc: is there a link where you have captured the proposed mapping or it trivial enough to not need one?
03:41:24 <vikasc> fawadkhaliq: its very trivial enough fawadkhaliq
03:41:37 <fawadkhaliq> vikasc: cool
03:41:49 <tfukushima> So here's the thing:
03:41:52 <tfukushima> $ sudo docker network create -d kuryr foo --subnet 10.0.0.0/24 --gateway 10.0.0.1 --ip-range 10.0.0./24
03:42:09 <tfukushima> --ip-range 10.0.0.0/24
03:42:24 <vikasc> tfukushima: that made life easy :)
03:42:36 <tfukushima> This --ip-range passes the subnet CIDR to the default IPAM driver.
03:42:53 <fawadkhaliq> right
03:43:08 <fawadkhaliq> got it. thanks tfukushima
03:43:26 <tfukushima> And the default IPAM driver takes it, allocate the IP addresses and give one from the range to /NetworkDriver.CreateEndpiont as Address or IPv6Address.
03:44:00 <vikasc> tfukushima: makes sense
03:44:32 <banix> #action vikasc to have the IPAM driver ready soon
03:44:37 <tfukushima> Kuryr already supports Address and IPv6Address in the request against  /NetworkDriver.CreateEndpiont and create  a new subnet if theres no one corresponding to the given Address and IPv6Address.
03:45:23 <tfukushima> So if we --ip-range is set appropriately, Kuryr takes care of things well.
03:46:00 <tfukushima> But in this case the default IPAM driver of Docker and the Neutron IPAM are coordinated appropriately.
03:46:12 <vikasc> tfukushima: thanks Taku for nice finding
03:46:13 <tfukushima> For instance the DHCP port needs to be disabled.
03:46:56 <banix> tfukushima: so this is sounding a bit confusing now
03:47:36 <vikasc> banix: now this is related to this patch https://review.openstack.org/#/c/241134/
03:47:43 <banix> tfukushima: that is when the default IPAM driver is used, and it turns out libnetwork and Neutron use the same serial allocation of IPs
03:47:49 <banix> is that correct?
03:48:36 <tfukushima> Yes, because in the current codebase Kuryr allocates all IP addresses greedily.
03:49:07 <tfukushima> That allocation is done by Neutron.
03:49:27 <tfukushima> So the IPAM drivers are out of sync, we are screwed.
03:49:42 <banix> tfukushima: are you simply saying that the default driver works ok if we disable dhcp? or suggesting that is what we should use
03:49:49 <tfukushima> That's why I told it worked "accidentally" and the DHCP port needs to be disabled.
03:50:03 <vikasc> tfukushima: To be more precise, can we say ip allocation is done by docker default ipam and neutron has to honor that allocation
03:50:21 <banix> exactly which means we should use our own driver (the null driver).
03:50:32 <fawadkhaliq> vikasc: Neutron can only honor if you ask Neutron to use fixed IPs for each port, right?
03:50:38 <banix> i meant exactly to taku’s comment
03:51:05 <vikasc> fawadkhaliq: yes
03:51:28 <vikasc> and neutron dont know that the ip neutron has used for the dhcp port can also be allocated by docker default ipam
03:52:08 <banix> vikasc: sure and thats why we need our own driver. relying on the above won’t be reasonable
03:52:36 <vikasc> banix: true
03:52:38 <fawadkhaliq> vikasc: from what I understand, Neutron not knowing the IP for DHCP port, is a problem contained in the DHCP enable/disable area and that should fix it.
03:52:57 <vikasc> fawadkhaliq: yes
03:53:18 <tfukushima> Yeah, ideally we should have our own IPAM driver which is synced with Neutron, or Neutron itself.
03:53:53 <fawadkhaliq> just to be sure, since I dont know the implementation, we are not relying on something like banix mentioned above. The two systems assumed to have same IP allocation mechanism, right? That might break.
03:54:11 <banix> having to independent IPAM modules is something we can and have to avoid
03:54:22 <banix> two independent
03:54:38 <vikasc> banix: thats what we will address by disabling dhcp
03:55:05 <vikasc> banix: by two ipams you mean here default docker ipam and neutron dhcp?
03:55:07 <banix> vikasc: I don’t think that’s good enough
03:55:15 <tfukushima> Yes, but this little hack is useful until we implement the IPAM driver.
03:55:46 <banix> vikasc:  yes, that case may be ok for just demonstration but not as a solution. Do we have an agreement here?
03:55:56 <fawadkhaliq> banix: +1
03:55:59 <vikasc> banix: +1
03:56:27 <vikasc> we have just 4 mins left
03:56:34 <banix> tfukushima: ok i understand now :) so our solution will be having a null driver and delegating all IPAM activities to Neutron
03:56:35 <tfukushima> So I'll keep working on creating the IPAM spec.
03:56:40 <fawadkhaliq> for the proper solution, we should consider drafting a blueprint perhaps?
03:56:44 <fawadkhaliq> great tfukushima
03:56:45 <fawadkhaliq> thanks
03:56:56 <banix> now I am confused again :)
03:56:57 <vikasc> tfukushima: thanks Taku
03:57:13 <banix> isn’t vikas working on a solution already?
03:57:56 <fawadkhaliq> banix: perhaps they are working as a team ;)
03:58:09 <banix> and by a solution I mean the proper solution that does not rely on two IPAMs being in sync
03:58:29 <vikasc> banix: tfukushima spec will be more than just null ipam and he will cover neutrons pluggable ipam also in that. is that correct Taku?
03:59:16 <tfukushima> Yes. I'm still figuring out and if it's not necessary, I'll move on to another task.
03:59:29 <banix> ok
03:59:31 <tfukushima> We're running our time out.
03:59:33 <fawadkhaliq> hm, Neutron pluggable IPAM in Kuryr when Neutron is the interface to Kuryr. Can't quite understand why would that be needed.
04:00:11 <banix> and as the car talk brothers used to say, we managed to spoil another hour of your time :)
04:00:24 <vikasc> lol
04:00:26 <banix> fawadkhaliq: agree
04:00:33 <banix> thanks everybody
04:00:41 <vikasc> thanks everybody
04:00:44 <banix> #endmeeting