14:01:00 <apuimedo> #startmeeting kuryr
14:01:01 <openstack> Meeting started Mon Mar  6 14:01:00 2017 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:04 <openstack> The meeting name has been set to 'kuryr'
14:01:23 <apuimedo> Hello everybody
14:01:30 <ltomasbo> o/
14:01:31 <alraddarla> o/
14:01:32 <vikasc> o/
14:01:32 <hongbin> o/
14:01:35 <mchiappero> o/
14:01:36 <yedongcan> o/
14:01:38 <limao> o/
14:01:39 <apuimedo> welcome to the first official Pike cycle weekly irc meeting
14:02:55 <apuimedo> #topic VTG
14:03:06 <garyloug> o/
14:03:08 <janonymous> o/
14:03:22 <irenab> hi
14:03:30 <apuimedo> I have to say I enjoyed the Virtual Team Gathering. I hope it was not too strenuous to follow and join
14:03:43 <apuimedo> and that the recordings and boards were helpful
14:04:23 <irenab> apuimedo: I agree with you, my experience was positive too
14:04:35 <ltomasbo> it was my first one, but I liked it too!
14:04:42 <ivc_> o/
14:04:48 <apuimedo> ltomasbo: it was the first one for everybody
14:04:49 <apuimedo> :P
14:04:57 <apuimedo> I'd like to propose a meeting tomorrow at 14utc to go over the action items
14:04:58 <ltomasbo> :D
14:05:06 <apuimedo> does that time work?
14:05:25 <janonymous> +1
14:05:31 <mchiappero> +1
14:05:38 <irenab> can we shift 30 mins earlier?
14:05:45 <vikasc> +1 irenab
14:05:47 <apuimedo> irenab: fine for me
14:06:02 <vikasc> will prefer 30 mins earlier
14:06:09 <apuimedo> mchiappero: janonymous: ivc_: does that work for you 13:30utc tomorrow?
14:06:13 <janonymous> +1
14:06:13 <mchiappero> ok
14:06:18 <ltomasbo> ok
14:06:38 <irenab> +1
14:07:13 <apuimedo> #info March 7th 13:30 utc VTG Action Item sorting session.
14:07:22 <vikasc> thanks!
14:07:28 <apuimedo> #action apuimedo to send the VTG Action Item sorting session to the mailing list
14:07:39 <apuimedo> Anything else about the VTG?
14:07:39 <ivc_> apuimedo as long as it is an hour long, i'm ok with that
14:07:50 <apuimedo> it is
14:08:25 <irenab> apuimedo: please share the list before, so we can check what to pick before the meeting
14:08:39 <apuimedo> irenab: it will be in the email to the ml
14:08:41 <apuimedo> :-)
14:08:49 <irenab> thanks
14:08:54 <apuimedo> #topic fuxi
14:08:58 <apuimedo> #chair hongbin
14:08:58 <openstack> Current chairs: apuimedo hongbin
14:08:59 <alraddarla> sorry, i actually have to step away. will catch up in a bit
14:09:08 <hongbin> hi
14:09:13 <apuimedo> alraddarla: very well, if there is any question reach out on the ml
14:09:16 <apuimedo> or irc
14:09:33 <apuimedo> hongbin: any fuxi updates?
14:09:38 <hongbin> for fuxi, there are several patches landed last week
14:09:53 <hongbin> and we are proposing the first release
14:09:56 <hongbin> #link https://review.openstack.org/#/c/441522/
14:10:04 <apuimedo> :-)
14:10:28 <hongbin> that would be a good first relase for fuxi
14:10:39 <apuimedo> That's really good news
14:10:45 <hongbin> apuimedo: that is all from me
14:10:55 <apuimedo> #info A first fuxi release, 0.1.0 has been proposed
14:11:17 <apuimedo> hongbin: At some point we should define what 1.0.0 should be
14:11:26 <apuimedo> and if that should be in the Pike cycle
14:11:36 <hongbin> apuimedo: work for me
14:11:40 <apuimedo> thanks
14:11:55 <apuimedo> anybody else has some question about fuxi?
14:12:48 <apuimedo> #topic kuryr-libnetwork
14:13:08 <apuimedo> We had a very nice series of contributions this week
14:13:16 <apuimedo> fixing bugs and adding blueprints
14:13:18 <apuimedo> :-)
14:13:58 <irenab> regarding IPv6 support https://blueprints.launchpad.net/kuryr-libnetwork/+spec/ipv6-subnet
14:14:14 <apuimedo> #info oslo debug bugfix in https://review.openstack.org/436523
14:14:36 <apuimedo> #info gateway ip retrieval fix https://review.openstack.org/436705
14:14:51 <apuimedo> #info mac address setting fix https://review.openstack.org/432777
14:15:01 <apuimedo> irenab: please go ahead
14:15:12 <irenab> I suggest to address IPv6 support as a whole
14:15:35 <irenab> currently there some ptches to add support for existing IPv6 subnetpools
14:15:48 <apuimedo> I'm fine with delaying 1.0.0 for ipv6 support
14:15:54 <apuimedo> in fact, I propose we do just that
14:16:09 <irenab> sounds reasonable to me
14:16:26 <apuimedo> at the very least, I want the support for dual stack networking that hongbin has been pushing
14:16:55 <irenab> apuimedo: but this is fragmental, isn’t it?
14:16:58 <apuimedo> irenab: I also saw your comment to hongbin's https://review.openstack.org/#/c/426595/
14:17:26 <apuimedo> irenab: sort of. It only enables dual stack
14:17:32 <apuimedo> but not pure ipv6
14:17:33 <hongbin> irenab: it looks the support of existing ipv6 and kuryr-created ipv6 will be very different
14:18:05 <irenab> apuimedo: dual stack only if its neutron created subnet
14:18:15 <apuimedo> irenab: yes
14:18:32 <hongbin> it is more like a bug fix than a new feature (i think)
14:18:46 <apuimedo> I think that what hongbin proposes in regard to the change of semantics for specifying the subnetpool makes sense. Because it is consistent with what we do for specifying networks
14:18:53 <irenab> I think IPv6 never have been a priority till now
14:19:19 <irenab> apuimedo: I will revisit my comment, ned to recheck
14:20:18 <irenab> as long as there are no users, I guess we can change the API semantics, but in general I prefer to avoid it
14:20:30 <apuimedo> I know
14:20:54 <apuimedo> I'll take a second look
14:21:04 <apuimedo> but the consistency is important reaching 1.0.0
14:21:25 <irenab> so supporting container on existing IPv6 subnet will be included in 1.00?
14:21:33 <apuimedo> yes
14:21:45 <irenab> but no docker driver IPv6 subnet
14:21:46 <apuimedo> and I'd like also on creating new one
14:22:12 <irenab> apuimedo: what is the expected timeline for 1.0.0?
14:22:22 <apuimedo> yedongcan: hongbin: limao: is creating on new ipv6 something either of you want to work on?
14:22:36 <apuimedo> irenab: asap
14:22:50 <apuimedo> as soon as we support ipv6 we cut the release
14:22:55 <hongbin> apuimedo: yes, i saw yedongcan took the bp, i can work with him for this
14:23:01 <apuimedo> perfect
14:23:19 <apuimedo> hongbin: yedongcan: I love the collaboration you have
14:23:20 <apuimedo> :-)
14:23:35 <yedongcan> apuimedo, hongbin: thanks, will do that.
14:23:40 <limao> apuimedo: It is ok for me IPv6 not in 1.0.0
14:23:54 <irenab> apuimedo: to cut 1.0.0, what is DoD criteria?
14:24:06 <irenab> Full stack tests?
14:24:23 <apuimedo> irenab: I'm sorry. But since I was a teenager... DoD only means "Day of Defeat" to me
14:24:32 <irenab> :-)
14:24:32 <apuimedo> irenab: could you remind me what it means?
14:24:39 <irenab> Definition of Done
14:24:43 <apuimedo> ah, right
14:24:51 <apuimedo> I know remember it's not the first time I ask you this
14:24:57 <apuimedo> sorry about that
14:25:17 <apuimedo> irenab: IPv6 with full stack tests for dual stack and IPv6
14:25:35 <apuimedo> limao: would you prefer 1.0.0 be cut before?
14:25:41 <irenab> I asked yedongcan to list work items at the bp
14:25:52 <apuimedo> I ask because if it is helpful we can consider it for before
14:26:54 <limao> apuimedo: depend on what's the time line we can fix ipv6, maybe we can check the ipv6 patch status next weekly, to see if we include ipv6 in 1.0.0
14:27:02 <apuimedo> limao: agreed
14:27:17 <hongbin> limao: +1
14:27:21 <apuimedo> Let's try to have code either merged or almost ready
14:27:30 <apuimedo> so that in next week we only miss the fullstack tests
14:28:13 <yedongcan> I will work on the base code and unit test this week.
14:28:30 <apuimedo> yedongcan: thanks a lot!
14:28:52 <apuimedo> #info We will revisit IPv6 creation inclusion on 1.0.0 release on the next weekly
14:29:04 <apuimedo> anything else on kuryr-libnetwork?
14:29:25 <limao> apuimedo: one more
14:29:31 <apuimedo> go ahead
14:29:36 <limao> about the kuryr-libnetwork docker image
14:30:12 <limao> Will we create an offical image to upload to docker hub?
14:30:48 <limao> (Maybe as a part of 1.0.0 release?)
14:30:50 <apuimedo> limao: there was some discussion on the PTG about the OpenStack container registry
14:31:05 <apuimedo> dan prince said he'd help with the puppet to deploy it
14:31:22 <limao> apuimedo: oh, cool, thanks for the info.
14:31:42 <apuimedo> limao: before that, we can only have unofficial container, that I can publish again
14:32:06 <apuimedo> #topic kuryr-kubernetes
14:32:49 <apuimedo> ltomasbo: how is the work going on the resource management after the VTG discussion?
14:33:12 <ltomasbo> I'm modifying the already existing patches
14:33:27 <apuimedo> irenab: vikasc: we should be merging https://review.openstack.org/#/c/440248/1 as we did in the other repos
14:33:28 <ltomasbo> to increase the isolation between VIF and PortsPool drivers
14:33:39 <apuimedo> good
14:33:51 <ltomasbo> I already did for the baremetal one
14:33:54 <apuimedo> ltomasbo: is there anything you need?
14:33:58 <ltomasbo> and working right now in the nested one
14:34:10 <apuimedo> (from reviewers)
14:34:12 <ltomasbo> it would be really nice to have some reviews on these:
14:34:16 <irenab> apuimedo: why is this one manula update?
14:34:21 <ltomasbo> https://review.openstack.org/#/c/436875
14:34:27 <ltomasbo> https://review.openstack.org/#/c/436876/
14:34:33 <ltomasbo> https://review.openstack.org/#/c/436877/
14:34:47 <ltomasbo> and I will submit the ones for nested probably today
14:34:54 <ltomasbo> and hopefully update the devref tomorrow
14:35:03 <irenab> ltomasbo: will check them by tomorrow
14:35:28 <apuimedo> https://bugs.launchpad.net/openstack-requirements/+bug/1668848
14:35:28 <openstack> Launchpad bug 1668848 in tacker "PBR 2.0.0 will break projects not using constraints" [High,In progress] - Assigned to yong sheng gong (gongysh)
14:35:29 <ltomasbo> then I will work on the kuryr-controller reboot (discovering the already created ports)
14:35:36 <apuimedo> I thought there was an email on the ml about it too
14:35:40 <apuimedo> but I can't find it now
14:35:42 <ltomasbo> irenab, great, thanks
14:35:52 <apuimedo> thanks ltomasbo
14:35:59 <ltomasbo> apuimedo, about what?
14:36:09 <ltomasbo> (not the thanks but the ml thing)
14:36:22 <ltomasbo> :d
14:36:26 <apuimedo> ltomasbo: about the pbr thing I pointed irenab towards
14:36:29 <ivc_> apuimedo we have that pbr patch https://review.openstack.org/#/c/439321/
14:36:30 <ltomasbo> ahh, ok
14:36:57 <apuimedo> garyloug: mchiappero: I see irenab also posted some comments to https://review.openstack.org/#/c/440669/
14:36:58 <ivc_> apuimedo since it passes gates it seems it does not break anything
14:37:03 <apuimedo> keep up to good work
14:37:41 <apuimedo> ivc_: it may break us on indirect dependencies, but you are right, for kuryr-k8s it doesn't break us for now
14:37:47 <mchiappero> apuimedo: the main concern is actually the potential race you pointed out
14:38:00 <apuimedo> mchiappero: yeah... That's a tough onw
14:38:01 <apuimedo> *one
14:38:03 <apuimedo> :-)
14:38:23 <irenab> apuimedo: so about the prb patch, which one do you want to merge?
14:38:24 <apuimedo> mchiappero: did you get any inspiration for that?
14:38:47 <irenab> pbr
14:38:48 <mchiappero> apuimedo: other than a "allowed_address_pairs" lock?
14:38:53 <mchiappero> no
14:39:41 <apuimedo> irenab: I'll dig around
14:39:48 <mchiappero> I'm afraid that Neutron has nothing to offer, and on the dispatcher side I'm not sure whether there is something we can do (e.g. use a threaded controller in this config)
14:39:49 <irenab> ok
14:40:09 <irenab> mchiappero: what is the problem you are dealing with?
14:40:49 <apuimedo> mchiappero: irenab: Do you think there is any chance the address pairs Neutron API could be enhanced?
14:40:54 <mchiappero> irenab: the possibility that two threads might be updating the "allowed_address_pairs" on the parent port at the same time
14:40:58 <apuimedo> So instead of being a replacement we get additions?
14:41:17 <mchiappero> apuimedo: it should probably work as the openstack client
14:41:20 <mchiappero> get/set
14:41:32 <mchiappero> each with a commit approach
14:41:51 <irenab> mchiappero: on kuryr side?
14:41:53 <mchiappero> short term, maybe locking on the kuryr side
14:42:01 <apuimedo> ivc_: the problem here is we'd probably need the dispatcher to be able to grouping events into green threads according to a driver as well
14:42:23 <apuimedo> mchiappero: that would get rid of needing a lock
14:42:29 <mchiappero> apuimedo: yes, that the other approach I was talking about
14:42:48 <apuimedo> for example, for the current macvlan driver, we'd just group events for scheduled node
14:42:52 <mchiappero> I need to check though, or get feedback from any of you familiar with the dispatching code
14:42:56 <ivc_> apuimedo yup. but lets stay away from that for now. i'm still hoping for a generalised actor model that would solve those issues
14:43:26 <apuimedo> ivc_: any hint on how it would solve it? Without giving up pod creation concurrency
14:43:42 <ivc_> apuimedo mchiappero i'm probably ok with locking as a short-term workaround just for that
14:43:56 <mchiappero> apuimedo: long term if the nested port support for macvlan/ipvlan based on trunks will be accepted in Neutron we are ok
14:43:57 <ltomasbo> so, neutorn.update_port_address_pairs just replace the current set, instead of adding into it?
14:43:58 <ivc_> apuimedo you'll have an actor for 'update address pairs'
14:44:01 <apuimedo> irenab: well, the problem for the approach garyloug and mchiappero patch pushes
14:44:13 <apuimedo> exactly what ltomasbo said
14:44:14 <apuimedo> :P
14:44:21 <ltomasbo> sounds to me that the right place to fix it is on the neutron side then
14:44:25 <apuimedo> so the same we do for trunk ports can't be done
14:44:36 <apuimedo> as it's buying tickets for the hot potato game
14:44:51 <apuimedo> ltomasbo: I agree that it would be the nicest outcome
14:45:07 <apuimedo> ltomasbo: but that may not be a tractable problem
14:45:17 <ltomasbo> :(
14:45:38 <irenab> neutron works on API request basis, so every request should be served autonomously, isn’t it?
14:45:43 <ivc_> ltomasbo 'just replace' could race and loose some calls
14:45:55 <mchiappero> ltomasbo: agree, I'm not sure though how willing they are to change a public API
14:46:02 <apuimedo> #action apuimedo to reach out to Neutron folks about a non-replacing API for allowed address ports
14:46:18 <ltomasbo> I'm not in favor of replacing ivc_, rather the oposite
14:46:35 <ivc_> apuimedo ltomasbo or are we discussing 'commit' on neutron side. if so, i'd be agains that
14:47:04 <irenab> I am not sure I unnderstand what API change you propose for neutron
14:47:30 <mchiappero> as I said I think an 'openstack' client like API would be nice
14:47:46 <apuimedo> mchiappero: I don't understand what that means
14:47:52 <mchiappero> so atomic adds and removes rather a full replace
14:47:56 <ivc_> irenab i think they mean making 'allowed address pairs' a sub-resource so it can support add/remove instead of replace
14:48:24 <mchiappero> apuimedo: like add one or more pair
14:48:25 <irenab> ivc_: thanks for clarification
14:48:49 <mchiappero> so that you do not need to per form the Read-Modify-Update
14:48:56 <apuimedo> ivc_: yes, that's what I meant
14:49:01 <apuimedo> it's a REST change
14:49:07 <apuimedo> so I think it's unlikely
14:49:35 <ivc_> apuimedo in that case it does make sense, tho super unlikely to get that change in reasonable amount of time
14:49:45 <irenab> apuimedo: I tend to agree; unless itis addition and not replacement to the existing API
14:49:52 <apuimedo> agreed
14:50:20 <apuimedo> I can't see it happening unless it is a service plugin
14:50:21 <mchiappero> :D I'm not following you anymore
14:50:26 <apuimedo> or some other sort of extension
14:50:30 <ivc_> irenab apuimedo addition would mean neutron would provide 2 api's for the same function, which is kinda ugly
14:50:40 <apuimedo> mchiappero: discussing neutron api/maintenance/politics
14:50:48 <mchiappero> apuimedo: ok
14:51:23 <irenab> apuimedo: worth to check anyway, maybe same issues came from other use cases
14:51:50 <ivc_> apuimedo i'd say serialising updates on kuryr side is more realistic approach. so locks for now and actors later
14:52:27 <apuimedo> ivc_: I'll just ask if a plugin could make sense. If possible I prefer to lock in Neutron
14:52:29 <irenab> ivc_: so lock on call neutron to update port with address pairs?
14:52:43 <mchiappero> ok, so, to recap: 1) macvlan specific lock on allowed_address_pairs updates 2) attempt Neutron API extension 3)improve the dispatching logic
14:52:48 <apuimedo> irenab: I guess just lock on a per port basis
14:52:53 <mchiappero> is this ok in terms of priority?
14:53:01 <apuimedo> when doing the address pairs update
14:53:08 <apuimedo> as you say
14:53:20 <apuimedo> mchiappero: that's right
14:53:34 <ivc_> irenab lock per 'update_address_pair' call is the easiest, but could be narrowed down to per-port lock
14:53:39 <mchiappero> ok, let's try in that order and update according to the progress
14:54:15 <apuimedo> irenab: https://review.openstack.org/#/c/438367/1
14:54:24 <apuimedo> when you have a moment
14:54:47 <irenab> apuimedo: done
14:55:01 <ivc_> apuimedo irenab that one could have some better wording, but ok :)
14:55:03 <apuimedo> as ivc_ says. per port when doing the update_address_pair
14:55:22 <apuimedo> ivc_: I'm just glad I didn't have to write it :P
14:55:41 <irenab> lets follow up on the patch
14:55:51 <apuimedo> documentation patches warm my heart
14:56:26 <apuimedo> anything else on kuryr-k8s?
14:56:33 <ivc_> apuimedo i was lazy when documenting the function and that devref patch just copied that :)
14:56:59 <apuimedo> ivc_: we need to document better in this cycle. I had a diagram bug as well
14:57:16 <apuimedo> and we should start making release note patches to catch up to what we have
14:57:22 <apuimedo> with reno
14:57:46 <ivc_> apuimedo add another action item for tmoroz meeting :P
14:57:49 <irenab> apuimedo: I think we shoudl ahve a list what should be included for every added feature
14:58:05 <apuimedo> ivc_: That's a very good point
14:58:06 <apuimedo> I will
14:58:17 <apuimedo> irenab: even better point
14:58:20 <apuimedo> a checklist
14:58:34 <apuimedo> thanks irenab!
14:58:39 <irenab> I can add some feature DoD list to the devref
14:59:01 <apuimedo> irenab: that would be super great!
14:59:02 <ivc_> trello? or i remember there was some openstack-hosted todo list...
14:59:29 <apuimedo> ivc_: I think more like have a devref of: Things to check for when submitting a feature
14:59:38 <apuimedo> like people can use it for their own checklist
14:59:44 <irenab> I just though to add some rst into the devref , like kuryr feature addition plolicy or something like this
14:59:50 <apuimedo> ivc_: the action items from the VTG will end up on a trello most likely
15:00:06 <apuimedo> irenab: sounds perfect
15:00:11 <apuimedo> let me know if I can help you with that
15:00:15 <apuimedo> it's an excellent idea
15:00:21 <irenab> apuimedo: add AI for me please
15:00:24 <apuimedo> (especially for forgetful people like me
15:00:25 <apuimedo> )
15:00:37 <ivc_> apuimedo i'll try to find that openstack-hosted tool (to keep things under the same umbrella if possible)
15:00:40 <irenab> so I won’t forget :-)
15:00:43 <apuimedo> #action irenab to draft the feature contributor checklist
15:00:54 <apuimedo> ivc_: openstack stories
15:00:58 <apuimedo> storyboard
15:01:03 <apuimedo> or something like that
15:01:15 <apuimedo> irenab: we really need those checklists
15:01:17 <apuimedo> :P
15:01:26 <apuimedo> anyways. Out of time
15:01:30 <apuimedo> thank you all for joining!
15:01:31 <ivc_> apuimedo right, storyboard it is :)
15:01:35 <apuimedo> talk to you tomorrow
15:01:43 <apuimedo> ivc_: I'm proud I remembered it
15:01:45 <apuimedo> #endmeeting