14:11:49 <vikasc> #startmeeting kuryr
14:11:50 <openstack> Meeting started Mon Nov 14 14:11:49 2016 UTC and is due to finish in 60 minutes.  The chair is vikasc. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:11:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:11:54 <openstack> The meeting name has been set to 'kuryr'
14:12:09 <vikasc> Hello everybody and welcome to another Kuryr weekly IRC meeting
14:12:13 <ivc_> o/
14:12:15 <irenab_> hi
14:12:20 <vikasc> who's here to chat?
14:12:29 * pc_m lurking again
14:12:36 <limao_> o/
14:12:43 <alraddarla_> o/
14:12:44 <lmdaly> o/
14:13:30 <vikasc> #info ivc_ irenab vikasc alraddarla_ lmdaly  joined the meeting
14:13:40 <mchiappero> o/
14:13:52 <vikasc> #topic kuryr-libnetwork
14:14:47 <vikasc> #link https://review.openstack.org/#/c/394547/
14:15:10 <irenab> there are jenkins failures
14:15:15 <mchiappero> yes
14:15:23 <mchiappero> I'm updating the unit test files
14:15:30 <vikasc> lmdaly has a WIP patch for moving binding from join to create_endpoint
14:15:32 <mchiappero> I hope to finish today or tomorrow
14:15:43 <vikasc> thanks mchiappero
14:17:27 <vikasc> I observed that currently kuryr-libnetwork is missing neutron call for updating port with --allowed-address-pair incase ipvlan driver is used in nested container case
14:17:53 <irenab> vikasc, link to bug?
14:17:56 <mchiappero> yes, that's because there is a patch missing
14:18:02 <mchiappero> being worked on
14:18:09 <lmdaly> We are working on a patch to create a driver based model for libnetwork to do this
14:18:15 <vikasc> irenab, no bug report yet
14:18:23 <vikasc> irenab, just an random observation
14:18:28 <irenab> guys, please report bugs once you observe them
14:18:56 <vikasc> irenab, sure, i was planning to raise after discussion
14:19:11 <vikasc> thanks lmdaly and mchiappero for the update!!
14:19:36 <irenab> lmdaly, can you please elaborate on driver based model?
14:20:28 <lmdaly> not concrete on the idea yet, but thinking much like the model introduced in kuryr-lib
14:21:03 <mchiappero> there is actually another open point regarding IPVLAN
14:21:26 <lmdaly> with a config file option and different implementations based on the driver
14:21:56 <mchiappero> the fact is that libnetwork seems to assign the MAC address, but the IPVLAN driver doesn't have such capability
14:22:00 <mchiappero> so it fails
14:22:09 <lmdaly> will push a WIP patch as soon as possible to get feedback on the structure
14:22:12 <irenab> lmdaly, got it, thanks. sounds as a good approach to keep code base better separated
14:22:20 <mchiappero> do we have any contact we can leverage in docker?
14:22:53 <mchiappero> also the libnetwork specs are confusing at times, we need clarifications there
14:22:58 <vikasc> may be banix would have helped
14:23:03 <irenab> I am not aware of any, probably mailing list option
14:23:04 <mchiappero> if you know someone personaly let us know
14:23:28 <mchiappero> ok, thanks
14:23:41 <vikasc> i messed up the order :P
14:23:49 <vikasc> #topic kuryr-lib
14:24:16 <vikasc> #link https://review.openstack.org/#/c/397057/
14:24:45 <irenab> vikasc, unit testing is missing
14:24:54 <vikasc> i pushed a small fix in ipvlan/macvlan driver ip assignment
14:25:33 <mchiappero> I'm not too sure I understand this patch
14:25:45 <mchiappero> the previous behaviour seemed to be correct to me
14:26:30 <vikasc> mchiappero, would you mind please adding your comments to patch
14:26:57 <vikasc> irenab, will add if fix is valid :)
14:27:06 <mchiappero> I will, but I need to find some time to better review and maybe test it :)
14:27:22 <limao_> in utils._configure_container_iface, it add ip onto the macvlan/ipvlan device, the ip should be not is vm-port
14:27:37 <vikasc> mchiappero, np, we can still discuss offline. i will ping you
14:27:51 <limao_> the ip should be not is vm-port -> the ip should not be vm-port fixed ip
14:28:15 <lmdaly> for the demo I passed in port as vm-port and nested_port as dangling neutron port with the container_ip
14:28:20 <irenab> maybe the name is confusing, I thought nested port is the container port
14:28:37 <mchiappero> it is/should br
14:28:44 <mchiappero> *be
14:28:59 <vikasc> irenab, nested_port seems to be vm_port to me
14:29:17 <vikasc> irenab, because in veth driver, this is not being even used
14:29:20 <lmdaly> I would have thought the same as irenab
14:29:23 <irenab> then it should be nesting_port :-)
14:29:43 <limao_> I was thought it is vm-port...
14:29:46 <vikasc> i will take a look again
14:29:51 <mchiappero> me too
14:30:01 <lmdaly> seems we need a name change :)
14:30:05 <vikasc> request everbody to please review the same
14:30:10 <limao_> since nowhere actually use this param now..
14:30:33 <irenab> if its not in  use, better to remove it
14:30:39 <vikasc> #link https://review.openstack.org/#/c/361993/
14:31:00 <lmdaly> it will be used for the driver patch we introduce for libnetwork
14:31:00 <vikasc> irenab, it will be used in trunk port case
14:31:30 <irenab> then lets just improve the name
14:31:43 <vikasc> irenab, +1
14:31:59 <vikasc> #link https://review.openstack.org/#/c/361993/
14:32:21 <vikasc> WIP patch for adding vlan driver support
14:32:45 <irenab> vikasc, I posted few comments
14:33:12 <vikasc> thanks irenab, i will go through them
14:33:33 <vikasc> intention is to leverage neutron trunk ports
14:34:25 <limao_> a quick question, in which use case we need to use local vlan? I see local vlan manage in that patch
14:35:07 <limao_> I mean : https://review.openstack.org/#/c/361993/11/kuryr/lib/segmentation_type_drivers/vlan.py
14:35:08 <vikasc> limao_, for the isolation of traffic from containers
14:35:28 <vikasc> limao_, on  the vm only
14:35:33 <irenab> limao_, vlan is to identify the container
14:35:58 <limao_> you mean in vm-nested case with subport trunk port?
14:36:07 <vikasc> limao_, yes
14:36:08 <irenab> yes
14:36:49 <limao_> In my currently understanding, the vlan in vm should not be local vlan, it should be same vlan as subport
14:37:33 <vikasc> limao_, vlan of subport menas?
14:37:41 <limao_> (I'm not sure if I miss something here since I has not actually tried trunk port now)
14:38:03 <vikasc> limao_, sorry, can you please reword your question
14:38:17 <limao_> The VM should be trunk port, in case it using vlan 100,200
14:38:37 <limao_> then the container on this vm should just use eth0.100, eth0.200, right?
14:39:09 <irenab> limao_, I think the idea is to use trunk port neutron APIs to get something similar to what OVN did:  http://docs.openstack.org/developer/networking-ovn/containers.html
14:39:49 <limao_> oh... let me check offline, thanks for the info , irenab, vikasc
14:40:12 <ivc_> limao_, irenab, we are we talking about vlan-aware-vms or ipvlan-based trunk ports?
14:40:31 <limao_> I think it should be vlan-aware-vms
14:40:44 <irenab> vikasc, may I raise one question that ks more related to the open discussion part, just need to drop in 5 mins
14:41:02 <irenab> ivc_, vlan aware vms
14:41:11 <vikasc> irenab, sure, please go ahead
14:41:29 <irenab> there is a design summit in February
14:41:57 <irenab> I didn't see kuryr in the list of confirmed projects, I wonder if anyone plans to attend
14:42:07 <limao_> PTG?
14:42:10 <irenab> yes
14:42:29 <limao_> I do not see it on list too
14:42:42 <vikasc> #action need to confirm with Toni on PTG.
14:43:10 <irenab> vikasc, thanks. Please keep going according to the usual route
14:43:21 <vikasc> irenab, thanks :)
14:43:31 <limao_> thanks irenab
14:43:40 <vikasc> ivc_, yes vlan aware vms
14:44:31 <vikasc> limao_, as per my understanding scope of vlans(vlan-per-container) will be local to vm only
14:44:53 <limao_> ivc_ , vikasc: I was thought we do not need manage local vlan in kuryr, just use the vlan of the subport
14:44:56 <vikasc> limao_, i could not get chance to have a look at ovn way yet
14:45:34 <ivc_> limao_, vikasc, we need to manage vlans for subports
14:45:47 <vikasc> limao_, i think i got your point
14:46:18 <ivc_> because when you create sub-port in neutron we either specify the vid, or let neutron set it
14:46:45 <ivc_> but we need to coordinate subports (on neutron) with the ethX.Y inside the vm
14:46:59 <vikasc> ivc_, +1
14:47:28 <limao_> Is this info can be get when container create? or we need to cache it in kuryr?
14:47:48 <vikasc> ivc_, we are talking about this https://review.openstack.org/#/c/361993/
14:47:55 <apuimedo> \o/
14:48:09 <vikasc> limao_, we will have to manage in kuryr
14:48:14 <vikasc> apuimedo, hello
14:48:19 <limao_> apuimedo :-) you get released ?
14:48:24 <vikasc> handover to you apuimedo
14:48:38 <vikasc> and many many congrats
14:48:40 <irenab> have to leave, will catch up on the log
14:48:40 <vikasc> :)
14:49:07 <apuimedo> yup
14:49:10 <apuimedo> we're all home
14:49:16 <mchiappero> :)
14:49:20 <apuimedo> sorry I couldn't make it 50min earlier
14:49:21 <mchiappero> doing well?
14:49:24 <ivc_> apuimedo, congrats on your daughter release !
14:49:28 <apuimedo> thanks!
14:49:33 <lmdaly> congrats! :)
14:49:34 <apuimedo> it was a hard fork!
14:49:36 <vikasc> sweets...........
14:49:45 <vikasc> apuimedo, laddu
14:49:50 <vikasc> :)
14:49:52 <apuimedo> but the new process is running strong and consuming a lot of resources
14:49:54 <apuimedo> as it should
14:50:04 <apuimedo> thank you all
14:50:15 <mchiappero> :)
14:50:25 <apuimedo> are we in kuryr-kubernetes part or in open discussion already?
14:50:34 <vikasc> just starting
14:50:34 <ivc_> neither
14:50:42 <vikasc> #topic kuryr-kubernetes
14:51:00 <ivc_> #link https://review.openstack.org/#/c/376044/2/kuryr_kubernetes/controller/handlers/vif.py@71
14:51:04 <apuimedo> only 9min remaining
14:51:14 * vikasc feeling sorry for poor time-management
14:51:17 <apuimedo> sorry, it's because my email was not sent properly
14:51:37 <ivc_> polling for neutron port activation seems to be a hot topic
14:51:58 <ivc_> but i've checked and it is the same in kuryr-libnetwork
14:52:06 <ivc_> #link https://github.com/openstack/kuryr-libnetwork/blob/master/kuryr_libnetwork/controllers.py#L342-L360
14:52:07 <apuimedo> #action apuimedo to address vikasc comments to https://review.openstack.org/#/c/396113/
14:52:58 <apuimedo> ivc_: yes, that was a relatively recent addition from banix
14:52:59 <ivc_> so i was thinking if it is worth adding some notification-based mechanism for both projects to check for port activation
14:53:04 <apuimedo> only for ovs, iirc
14:53:21 <apuimedo> well, we have an open door to do it in neutron for both
14:53:26 <apuimedo> just as it does for nova
14:53:35 <apuimedo> so that's the long term solution I'd like
14:53:48 <apuimedo> or the one that I think is more doable
14:54:06 <apuimedo> ivc_: did you see https://review.openstack.org/#/c/396113/ ? I think it addresses the loopback requirement you noted to me
14:54:53 <ivc_> apuimedo, yes, but need to test it (the cni binary is 'lo' instead of 'loopback')
14:55:32 <apuimedo> yeah... I need to test it too
14:55:42 <apuimedo> I had to run to the hospital just after writing it xD
14:56:00 <mchiappero> :D
14:56:07 <apuimedo> almost literally
14:56:10 <vikasc> :D
14:56:15 <apuimedo> also
14:56:23 <mchiappero> maybe the code was ready too
14:56:25 <apuimedo> I want to add to devstack to set kubectl config
14:56:26 <mchiappero> :P
14:56:30 <apuimedo> :D
14:56:39 <limao_> apuimedo： you will get more sleepless night now
14:56:40 <apuimedo> to make development easier
14:56:47 <apuimedo> limao_: yeah, more time for coding
14:56:58 <limao_> :)
14:57:02 <apuimedo> one eye on the baby and one on the screen, like a chameleon
14:57:12 <vikasc> apuimedo, height of optimism
14:57:43 <apuimedo> indeed
14:58:00 <apuimedo> anyway. I will be working part time for a few weeks now
14:58:14 <apuimedo> I still should be able to finish cni and do these devstack improvements :-)
14:58:35 <limao_> home is always first :)
14:58:43 <vikasc> limao_, +1
14:58:48 <apuimedo> very true limao_
14:58:57 <apuimedo> anything else about kuryr-kubernetes before we close?
14:59:27 <apuimedo> I'd appreciate that people try the devstack and start to play with the environment and review ivc_'s code if they haven't started already
14:59:41 <ivc_> apuimedo, well we could discuss the cni-daemon idea next week
15:00:06 <ivc_> since its a long-term idea anyway
15:00:21 <apuimedo> ivc_: good point
15:00:40 <apuimedo> ivc_: we can even do an extraordinary irc meeting some time in the week in #openstack-kuryr
15:00:50 <apuimedo> vikasc: we must close the meeting now and move to #openstack-kuryr
15:00:57 <jimbaker> apuimedo, thanks
15:01:00 <apuimedo> I'm sure there's people waiting to take the room :P
15:01:02 <vikasc> sure
15:01:03 <ivc_> apuimedo, sure
15:01:16 <vikasc> #end-meeting
15:01:19 <openstack> jimbaker: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
15:01:33 <jimbaker> vikasc, ^^^
15:01:45 <apuimedo> vikasc: endmeeting
15:01:50 <apuimedo> not end-meeting
15:01:52 <vikasc> #endmeeting