#openstack-meeting-4 log

14:01:38 <apuimedo> #startmeeting kuryr
14:01:39 <openstack> Meeting started Mon Nov 28 14:01:38 2016 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:42 <openstack> The meeting name has been set to 'kuryr'
14:01:51 <apuimedo> Hello! Welcome to another kuryr weekly meeting!
14:01:56 <apuimedo> who's here?
14:01:58 <mchiappero> o/
14:01:59 <garyloug> o/
14:02:00 <janonymous> o/
14:02:02 <vikasc> o/
14:02:04 <lmdaly> o/
14:02:09 <ltomasbo> 0?
14:02:12 <ltomasbo> 0/
14:02:17 <limao_> o/
14:02:58 <ivc_> o7
14:03:00 <alraddarla_> o/
14:03:18 <apuimedo> ltomasbo: that's a head with an ear?
14:03:23 <apuimedo> Welcome all
14:03:28 <ltomasbo> :D
14:03:30 <apuimedo> #topic kuryr-lib
14:04:10 <apuimedo> #info The only missing item for the release that blocks lmdaly and mchiappero's work is https://review.openstack.org/#/c/361993/
14:04:19 <apuimedo> which has a -1 from irenab
14:04:41 <apuimedo> I understand that this has been tried out by vikasc and ltomasbo with success
14:04:54 <apuimedo> and I've seen some contention on the implementation from irenab and limao_
14:05:11 <mchiappero> apuimedo: is there really a dependency? or is it for the release?
14:05:20 <apuimedo> mchiappero: it's for the release
14:05:30 <mchiappero> apuimedo: ok
14:05:32 <apuimedo> that will make your unit tests suddenly pass
14:05:34 <apuimedo> :P
14:05:45 <apuimedo> limao_: irenab: could you voice your concerns
14:05:53 <mchiappero> yeah, I didn't know whether you wanted to include it or not :)
14:05:56 <apuimedo> (no need to go into all the details
14:06:11 <apuimedo> but it would be nice to sum it up, so we can move into a decision)
14:06:59 <limao_> apuimedo: I think I already discussed with vikasc and ltomasbo in openstack-kuryr this afternoon, it is ok for me to merge that patch
14:07:07 <vikasc> irenab has opinion that import failure should be handled on kuryr-libnetwork side
14:07:30 <apuimedo> I have to say that I agree in principle with both limao_'s and irenab_'s comments
14:07:39 <vikasc> i too agree
14:07:42 <apuimedo> what I propose is to get it in now, being that it works
14:07:43 <ltomasbo> me too
14:07:57 <vikasc> i will remove this check
14:08:01 <apuimedo> and then we solve those contention points in a point release
14:08:16 <apuimedo> in general I think that the driver instantiation should be done by kuryr-libnetwork
14:08:19 <apuimedo> and not by the module
14:08:28 <apuimedo> but it's something we can move later
14:08:36 <vikasc> sure
14:08:37 <apuimedo> irenab_: vikasc: agreed?
14:08:43 <vikasc> +1
14:08:45 <apuimedo> limao_: ltomasbo: ?
14:08:51 <limao_> +1
14:09:01 <ltomasbo> +1
14:09:29 <apuimedo> alright then, so irenab will probably switch the vote later when her isp lets her
14:09:37 <apuimedo> then we can merge it and trigger the release
14:09:51 <apuimedo> for Ocata I propose
14:09:57 <apuimedo> (I'll send ML thread)
14:10:11 <apuimedo> * Move the plugin system to stevedore
14:10:22 <apuimedo> * clean up the couplings that we still have
14:10:29 <apuimedo> anybody'
14:10:47 <apuimedo> *anybody's got anything else that they want to add to kuryr-lib in the ocata cycle?
14:12:01 <mchiappero> well, in theory whatever is needed for making the kuryr-libnetwork plugins work
14:12:32 <apuimedo> mchiappero: we'll be taking a bit of a new approach in that regards to solve the bad blocking we had recently
14:12:56 <apuimedo> if something is needed for kuryr-libnetwork. It goes first there, and if we want it in kuryr-kubernetes or fuxi, then it graduates to kuryr-lib
14:13:08 <apuimedo> so we won't be putting first version stuff to kuryr-lib anymore
14:13:15 <apuimedo> only stable and used things
14:13:17 <mchiappero> I agree :)
14:13:20 <vikasc> thats nice
14:13:23 <limao_> +1
14:13:31 <ivc_> +1
14:13:39 <irenab> apuimedo: can you please post the kuryr policies somewhere?
14:13:43 <apuimedo> #info kuryr-lib is now where code goes when it is mature and usable in other parts, never again first implementations
14:14:20 <apuimedo> irenab: it is now in the log and summary of this weekly, I'll update it in the kuryr-lib repo later today or tomorrow
14:14:32 <apuimedo> #action apuimedo to update the repo policy for kuryr-lib
14:14:39 <apuimedo> #topic kuryr-libnetwork
14:14:41 <irenab> apuimedo:  thanks
14:14:50 <apuimedo> irenab: thanks to you for the reminder!
14:15:15 <apuimedo> irenab: please, switch the vote on https://review.openstack.org/#/c/361993/28
14:15:20 <apuimedo> we need to merge it
14:15:25 <apuimedo> and then do a bugfix release
14:15:57 <apuimedo> #info ltomasbo posted the vlan subports management patch https://review.openstack.org/402462 that uses the kuryr-lib vlan code
14:16:06 <irenab> apuimedo: will check
14:16:07 <apuimedo> please, let's get this reviewed soon
14:16:45 <apuimedo> and after the kuryr-lib release, this and https://review.openstack.org/400365 https://review.openstack.org/394547 will be taken out of WIP and considered for merging
14:16:50 <vikasc> apuimedo, https://review.openstack.org/#/c/403325/
14:16:52 <irenab> apuimedo:  I just have one general comment regarding the two patches you posted
14:17:15 <apuimedo> vikasc: irenab: let's get https://review.openstack.org/#/c/399958/ merged
14:17:22 <apuimedo> this will improve our test stability
14:17:30 <apuimedo> thanks limao_ for that one
14:17:37 <vikasc> apuimedo, sure
14:18:00 <apuimedo> vikasc: irenab: also https://review.openstack.org/#/c/402537/
14:18:04 <apuimedo> irenab: go ahead
14:18:06 <mchiappero> I will rebase https://review.openstack.org/394547 later today to be able to merge soon
14:18:20 <irenab> for my general comments, I understand the urgency of adding new functionality, but it should not come on the cost of having less maintainable code
14:18:23 <apuimedo> mchiappero: when they are not missing stuff, take out the [wip] tag too
14:18:40 <mchiappero> I'll do while rebasing
14:18:59 <apuimedo> irenab: I agree. This is only to be merged with the understanding that we are making a point release fixing where this code is loaded
14:19:09 <irenab> addingcases per specific drivers in the common controller is not the way to go
14:19:17 <apuimedo> and the next release will move to the new plugin style that kuryr-kubernetes is pioneering
14:19:22 <apuimedo> irenab: agreed
14:19:44 <irenab> apuimedo: thanks
14:19:57 <apuimedo> drivers, as mchiappero has been advocating, have to be chosen by kuryr-libentwork and kuryr-kubernets, not loaded by the library
14:20:10 <apuimedo> so we are going to fix that for sure :-)
14:20:39 <irenab> apuimedo: sounds like we should maintain the list of issue to fix :-)
14:20:44 <apuimedo> limao_: irenab: please review https://review.openstack.org/#/c/403325/2
14:20:57 <mchiappero> about this
14:20:57 <apuimedo> irenab: yes. We have to file bugs for this and mark them for the release
14:21:15 <apuimedo> #action apuimedo to mark the bugs for the milestone releases
14:21:36 <mchiappero> most if not all (I'm not sure though) of the code for the port drivers could be promoted to kuryr-lib actually
14:21:44 <limao_> ok
14:21:47 <mchiappero> I like the approach
14:22:08 <mchiappero> I'm not too sure it's actually 100% doable
14:22:16 <mchiappero> I'm looking for your opinion here
14:22:36 <irenab> mchiappero: by port driver you mean binding driver?
14:22:42 <mchiappero> no
14:22:52 <apuimedo> irenab: port creation
14:23:07 <irenab> BM vs nested?
14:23:11 <apuimedo> it's basically the same as the portdriver in kuryr-kubernetes
14:23:14 <apuimedo> irenab: that's right
14:23:19 <mchiappero> I'm not following you anymore, what part is not clear so that I can reply?
14:23:39 <apuimedo> we will try to move it to the same style as kuryr-kubernetes soon
14:23:44 <mchiappero> I'm not following the code in kuryr-kubernetes so I'm not sure about it
14:23:45 <hongbin> o/
14:23:54 <apuimedo> hongbin: you're on time :-)
14:24:09 <irenab> apuimedo: shounds like the topic for vistual summit/sprint
14:24:10 <apuimedo> mchiappero: basically the idea is that for each neutron resource
14:24:13 <apuimedo> there are drivers
14:24:17 <apuimedo> irenab: indeed
14:24:24 <mchiappero> to recap: irenab you are proposing to get away with the port drivers and move all the code to the binding drivers, right?
14:24:27 <apuimedo> (using stevedore)
14:24:40 <irenab> mchiappero: no, not yet at least
14:24:41 <apuimedo> and there are defaults, of course
14:25:13 <irenab> dinding is different from create,so we may have 2 different group of drivers
14:25:16 <mchiappero> irenab: ok, so I misunderstood, maybe you were referring to some code in the port drivers specifically (if so, which one?)?
14:25:26 <apuimedo> there's neutron resource drivers
14:25:31 <apuimedo> and then binding drivers
14:25:49 <apuimedo> which in the future should use os-vif with some extensions (since os-vif doesn't have vlan/ipvlan/macvlan)
14:26:27 <irenab> so the plan for now, keep binding part in the kury lib and the port create part in the libnetwork?
14:26:46 <mchiappero> ok, I'm afraid I'm not able to follow, I'm sorry :(
14:27:01 <irenab> mchiappero: I may need to take a look on libnetwork code again to answer you
14:27:21 <lmdaly> also are we agreed that the port driver code should be refactored to have an abstract class with drivers that provide the implementation or leave the code as is?
14:27:40 <ivc_> irenab, apuimedo, not to derail the discussion, but we are going to refactor the kuryr-lib binding part to use os-vif VIF objects after it matures in kuryr-k8s, right?
14:27:48 <apuimedo> ivc_: exactly
14:27:57 <apuimedo> we are going to mature it in kuryr-kubernetes
14:28:04 <apuimedo> then see how we can use it in kuryr-libnetwork
14:28:17 <irenab> the question is what we currently decide for libnetwork
14:28:28 <apuimedo> and when that is clear, it moves from kuryr-kubernetes to kuryr-libnetwork and both kuryr-kubernetes and kuryr-libnetwork move to use it
14:28:39 <mchiappero> somehow the port drivers in many cases just forward straight to kuryr-lib binding drivers, so I guess you meant to move that code directly there and get away with the port drivers
14:28:50 <apuimedo> irenab: currently we implement what is missing in kuryr-lib in kuryr-libnetwork
14:28:53 <irenab> current code is getting messed with specific type ==xxx even though we have drivers
14:29:44 <mchiappero> irenab: some checks for IPVLAN will be removed
14:30:22 <mchiappero> ok, if you want we can go through the code again and make a decision offline, but we do need to know which direction is the preferred one here
14:30:23 <irenab> mchiappero: its now more relevant for nested support being added in the libnetowrk controller
14:30:41 <irenab> mchiappero: agree
14:30:55 <vikasc> imo, we should wait on introducing new drivers abstraction and see how resource drivers mature in kuryr-k8s
14:31:09 <irenab> apuimedo: so for now libnetwork should not use kuryr-lib drivers?
14:31:10 <mchiappero> ok, so let's move on no, but please let's continue later so that we can make progress, thank you
14:31:19 <apuimedo> irenab: only if they can be used as is
14:31:35 <apuimedo> mchiappero: thanks!
14:31:41 <apuimedo> #topic fuxi
14:31:42 <ivc_> irenab, apuimedo, so granted that we expect a major binding/VIF driver refactor (prolly in P cycle), imo it should be ok to merge kuryr-lib/kuryr-libnetwork stuff as long as it works and is not _too_ ugly :)
14:31:45 <mchiappero> they can, probably will need some changes in the future, but they can
14:32:03 <apuimedo> ivc_: yes. That's the idea, merge what we have in the queue now
14:32:14 <apuimedo> hongbin: you have the floor
14:32:20 <irenab> ivc_: the problem is that it is ugly …
14:32:21 <apuimedo> #chair hongbin
14:32:22 <openstack> Current chairs: apuimedo hongbin
14:32:31 <hongbin> fuxi?
14:32:34 <apuimedo> irenab: beauty is on the eye of the beholder :P
14:32:48 <apuimedo> hongbin: right
14:32:58 <hongbin> ok, i briefly report the status of the fuxi project last week
14:33:02 <apuimedo> thanks
14:33:18 <hongbin> there is a patch for setup the devstack plugin for fuxi
14:33:21 <apuimedo> hongbin: first, let me apologize for not getting through the reviews. I've seen the new patches you posted
14:33:32 <apuimedo> but I want to try the devstack myself before I approve
14:33:35 <hongbin> apuimedo: np, takes your time
14:33:46 <hongbin> #link https://review.openstack.org/#/c/402244/
14:33:50 <hongbin> here you go
14:34:02 <hongbin> welcome everytone to try it, and provide feedback
14:34:12 <hongbin> this week, i will try to setup the CI
14:34:35 <hongbin> first, add some functional tests, then submit a patch to project-config to have a test
14:34:41 <hongbin> that is all from me
14:35:11 <apuimedo> sounds great hongbin!
14:35:12 <hongbin> apuimedo: thanks for pinging me to give an update
14:35:31 <apuimedo> #action hongbin to set up CI using his devstack patches for fux
14:35:33 <apuimedo> *fuxi
14:35:41 <apuimedo> crap, i screwed the action point :(
14:35:47 <apuimedo> #topic kuryr-kubernetes
14:36:35 <ivc_> well, we've completed the controller side of port binding last week (thnx apuimedo, irenab, vikasc for reviews)
14:36:38 <apuimedo> #info irenab and ivc_ have updated the kuryr-kubernetes devref draft document. I highly recommend it: https://docs.google.com/document/d/1hExm0TNp_OMWY_XMVRYpSvg5G8kFrL5hcrT9M_NDCwo/edit?usp=sharing
14:37:27 <vikasc> better late than never, its very useful doc :)
14:37:27 <ivc_> there's also a PoC CNI driver somewhere in that devref comments (tho i encourage you not to try it yet)
14:37:28 <apuimedo> #info the controller side of port handling was merged last week
14:37:58 <apuimedo> ivc_: share the link, there's brave and crazy people here :P
14:37:59 <ivc_> also there's a link to CNI design decisions diagram in that devref (in .xmind format)
14:38:22 <ivc_> #link http://paste.openstack.org/show/590658/
14:38:29 <apuimedo> ivc_: thanks!
14:38:41 <vikasc> thanks ivc_
14:38:53 <ivc_> the code is *bad* and not intended for someone to look at it, but whatever :)
14:39:12 <apuimedo> ivc_: don't worry too much, I'll just merge it and...
14:39:13 <irenab> ivc_: but it works :-)
14:39:13 <apuimedo> xD
14:39:40 <ivc_> so right now i'm working on a clean implementation that follows the design decisions (see .xmind doc in devref comments)
14:39:51 <apuimedo> #action ivc_ to post the non-ugly version of the CNI driver WIP
14:39:56 <ivc_> eta - this week
14:40:02 <apuimedo> ivc_: great
14:40:31 <apuimedo> after that I think vikasc and ltomasbo will be trying to get it to work with nested ports
14:40:36 <ivc_> also we got an issue with devstack due to the release of kuryr-lib
14:40:50 <vikasc> apuimedo, right!!
14:40:51 <apuimedo> there's two sides that need to be done, a vif port driver
14:40:59 <ivc_> so we need to fix requirements.txt to point to kuryr-lib release instead of git
14:41:03 <vikasc> apuimedo, i am on it now
14:41:06 <apuimedo> and the CNI part (as os-vif doesn't have yet what it takes)
14:41:11 <irenab> ivc_: is there a bug?
14:41:21 <apuimedo> ivc_: after we make today's release published yes
14:41:24 <ivc_> irenab, nope. but the fix is trivial
14:41:44 <ivc_> irenab, i'm just waiting for an updated kuryr-lib release :)
14:42:19 <apuimedo> ivc_: as soon as irenab swaps the vote on https://review.openstack.org/#/c/361993/ I'll request a release
14:42:31 <apuimedo> and then I'll send the patch for requirements
14:42:45 <mchiappero> please irenab :P
14:42:47 <ivc_> ok, cool
14:42:53 <apuimedo> no pressure :P
14:43:01 <ivc_> like at all :P
14:43:02 <irenab> apuimedo: you are twisting my arm
14:43:21 <apuimedo> /¯\_(ツ)_/¯
14:43:47 <irenab> apuimedo:  I really cannot +2 this one: https://review.openstack.org/#/c/361993/28/kuryr/lib/segmentation_type_drivers/__init__.py ..
14:43:47 <mchiappero> stock market might fall if we don't release soon :P
14:44:03 <apuimedo> it will be like brexit and trump combined
14:44:06 <apuimedo> :-)
14:44:17 <mchiappero> release! :P
14:44:35 <apuimedo> anyway
14:44:42 <irenab> vikasc: lets compromise, put huge REVISIT comment on top of this if clause
14:44:43 <apuimedo> ivc_: anything else?
14:44:52 <apuimedo> irenab: +1
14:44:54 <ivc_> apuimedo, nope
14:44:56 <vikasc> sure irenab :)
14:44:59 <apuimedo> very well
14:45:03 <apuimedo> #topic open discussion
14:45:17 <irenab> have to go, enjoy the rest of the meeting
14:45:27 <apuimedo> I'm considering begging for a room for a developer meetup in Atlanta in case some people do go
14:45:33 <ivc_> apuimedo, irenab, tho that __init__.py irenab linked does look kinda ugly, i must agree :)
14:45:43 <apuimedo> irenab: remember to check later for the revisit update and +2 :P
14:46:44 <apuimedo> so, if any of you go, let's meet up!
14:46:53 <apuimedo> anything else from anybody?
14:46:55 <alraddarla_> any easy tasks a new comer can take care of for you?
14:47:11 <apuimedo> alraddarla_: kubernetes or libnetwork?
14:47:22 <limao_> [openstack-dev] [kuryr] - stable release for mitaka or newton
14:47:39 <alraddarla_> libnetwork for now, but i'd like to look into both eventually
14:47:45 <apuimedo> ok
14:47:46 <limao_> there are a mail asking about stable release for M or N
14:48:00 <apuimedo> oh, that's right
14:48:35 <apuimedo> the first stable release will be *sorta Newton, as in we'll release it probably in a week or two
14:48:45 <mchiappero> yes, I have an open actually regarding this https://review.openstack.org/#/c/397640/
14:49:11 <mchiappero> I'm not completely sure about the cause of the failure of the unit tests
14:49:13 <apuimedo> alraddarla_: ping me later and I'll try to check the outstanding bugs for low hanging fruit
14:49:27 <alraddarla_> sounds good, thank you apuimedo
14:49:44 <mchiappero> on some machines it seems to succeed, there it fails
14:49:53 <apuimedo> a heisenbug
14:50:14 <apuimedo> #action apuimedo to check what's up with https://review.openstack.org/#/c/397640/ gates
14:50:19 <mchiappero> could be, I'm not too sure about the injected values, it seems like sometimes mox uses a config file
14:50:24 <apuimedo> limao_ can probably find out easily
14:50:26 <apuimedo> :-)
14:50:41 <mchiappero> thank you!
14:50:52 <limao_> :)
14:50:54 <apuimedo> alraddarla_: oh, this reminds me! dropping mox for mock is doing $DEITY's work
14:51:24 <apuimedo> so... there's that boring task to get acquainted with the code and ridding us of mox forever and banishing to the hades
14:51:48 <apuimedo> anything else?
14:51:50 <mchiappero> I don't want to steal time here, but if you want we can return back to the driver thing :)
14:52:25 <ivc_> mchiappero, i think we can do it in #openstack-kuryr, i doubt we can cover it in 5 minutes here
14:52:37 <mchiappero> so, priority #1 is to avoid pushing requirements/changes in kuryr-lib, right?
14:52:40 <apuimedo> mchiappero: please, read https://docs.google.com/document/d/1hExm0TNp_OMWY_XMVRYpSvg5G8kFrL5hcrT9M_NDCwo/edit?usp=sharing and then ping us on #openstack-kuryr
14:53:06 <apuimedo> mchiappero: no. it's making the release, then merging your patches
14:53:18 <alraddarla_> apuimedo: i can handle that
14:53:21 <mchiappero> apuimedo: ok I'll do
14:53:25 <apuimedo> and doing all that while not touching kuryr-lib except for cleanups
14:53:33 <apuimedo> *and bugfixes)
14:53:44 <ivc_> mchiappero, if you got any question about kuryr-k8s, ping me on irc or we can arrange another videoconf
14:53:57 <apuimedo> ivc_: good point
14:53:59 <mchiappero> yes, that was my understanding, so no changes to interfaces in kuryr-lib
14:54:10 <mchiappero> ivc_: ok, thank you!
14:54:11 <apuimedo> mchiappero: exactly
14:54:21 <apuimedo> alright. Thank you all for joining today! Have a great rest of day!
14:54:27 <apuimedo> #endmeeting