14:03:48 <apuimedo> #startmeeting kuryr
14:03:49 <openstack> Meeting started Mon Dec 19 14:03:48 2016 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:52 <openstack> The meeting name has been set to 'kuryr'
14:03:59 <apuimedo> Hello everybody and welcome to another weekly IRC meeting!
14:04:02 <apuimedo> Who's here?
14:04:08 <ivc_> \o/
14:04:09 <janonymous> o/
14:04:11 <alraddarla_> o/
14:04:15 <mattmceuen> o/
14:04:17 <irenab> hi
14:04:17 <yedongcan> o/
14:04:18 <limao_> o/
14:04:25 <diga> o/
14:04:31 <mchiappero> o/
14:04:36 <garyloug> o/
14:04:45 <vikasc> o/
14:04:48 <apuimedo> That's a nice attendance :-)
14:05:05 <apuimedo> #topic kuryr-libnetwork
14:05:15 <hongbin> o/
14:05:31 <apuimedo> Alright then, let's get started
14:06:51 <apuimedo> We got some nice fixes last week
14:07:14 <apuimedo> I want to draw attention to one in particular from yedongcan
14:07:16 <apuimedo> https://review.openstack.org/404591
14:07:19 <apuimedo> #link https://review.openstack.org/404591
14:07:34 <apuimedo> thanks for the patch yedongcan!
14:08:13 <yedongcan> apuimedo: you're welcome
14:08:50 <apuimedo> heh, I actually wanted to talk about https://review.openstack.org/#/c/401874/5
14:08:53 <apuimedo> sorry about that
14:08:58 <apuimedo> I copied the wrong link
14:09:00 <apuimedo> :-)
14:09:03 <apuimedo> #link https://review.openstack.org/#/c/401874/5
14:09:09 <apuimedo> this was merged the previous week
14:09:26 <apuimedo> and it solved an ipam address release issue
14:10:08 <apuimedo> mchiappero brought up that this solution poses some difficulty for the ongoing nested work
14:10:26 <apuimedo> #link https://review.openstack.org/#/c/400365/
14:10:37 <apuimedo> that would otherwise be pretty ready for merging
14:10:47 <apuimedo> mchiappero: could you please describe the issue
14:11:52 <mchiappero> I'm not sure about where the problem is actually originated, but that code ends up returning no subnets for nested containers
14:12:15 <mchiappero> that means that neutron ports don't get deleted anymore with nested containers
14:12:40 <mchiappero> I'm wondering whether having a subnetpool_id in the subnet is now a requirement
14:12:55 <apuimedo> mchiappero: you mean that after this change, when a port was being used for nested, it can't be deleted, right?
14:13:22 <mchiappero> or whether there is another way to refactor that code in order to handle nested containers as well
14:13:27 <mchiappero> apuimedo: exactly
14:13:49 <mchiappero> it doesn't get deleted by kuryr anymore, of course you can delete it manually
14:13:58 <yedongcan> apuidemo: got it, i had disscuss it with ltomasho, and limao file a bug for this: https://bugs.launchpad.net/kuryr-libnetwork/+bug/1651015
14:13:59 <openstack> Launchpad bug 1651015 in kuryr-libnetwork "kuryr-libnetwork did not clearn neutron port when use existed neutron network" [Undecided,New]
14:14:20 <apuimedo> #link https://bugs.launchpad.net/kuryr-libnetwork/+bug/1651015
14:14:48 <mchiappero> what would be the best approach in your opinion?
14:15:35 <apuimedo> yedongcan: I just 'confirmed' the bug
14:17:02 <apuimedo> yedongcan: did you have something in mind to address the bug already?
14:17:21 <mchiappero> maybe we can continue offline, but it would be nice to get this sorted
14:18:47 <irenab> mchiappero: lets try to draft proposal at the bug description board
14:18:48 <mchiappero> I guess we have a number of other topic, let's continue on the kuryr channel :)
14:18:48 <apuimedo> mchiappero: we can devote a few more minues
14:18:50 <apuimedo> :-)
14:19:10 <yedongcan> I will sort some consideration in the LP, I think this need further discussion.
14:19:51 <apuimedo> yedongcan: mchiappero: irenab: Agreed
14:19:55 <mchiappero> irenab: I don't have a proposal yet, lately I have little time so I could not check the new code, but I'll trye
14:19:57 <limao> Yes, we can discuss it in channel later
14:20:00 <yedongcan> it's related neutron existing resource, overlapping cidrs and others.
14:20:02 <mchiappero> *try
14:20:12 <apuimedo> for now. Maybe we can put the workaround that the network for the VM be created first with Kuryr by running a container
14:20:22 <apuimedo> and linking the bug in mchiappero's patch
14:20:49 <apuimedo> this would be enough to allow us to merge mchiappero's patch IMHO, since it is not introducing a problem, just experiencing it harder
14:21:09 <apuimedo> since the normal flow to try nested is to create Nova instances on end user created neutron nets
14:21:25 <apuimedo> do you all agree with that?
14:21:55 <irenab> apuimedo: sounds reasonable
14:22:04 <mchiappero> ok by me
14:22:05 <yedongcan> Agree.
14:22:24 <apuimedo> mchiappero: I'll push an update of your patch with a link to the bug
14:22:32 <apuimedo> then I'll +2
14:22:40 <mchiappero> thank you
14:22:43 <apuimedo> and ping irenab and vikasc for review
14:22:57 <apuimedo> #topic kuryr-kubernetes
14:23:25 <apuimedo> #info ivc_ made a very nice demo of the services patch https://asciinema.org/a/51qn06lgz78gcbzascpl2du4w
14:23:31 <apuimedo> Thanks a lot for that ivc_
14:23:34 <ivc_> aye
14:23:46 <mchiappero> regarding the patch, the unit tests should be ok now, maybe some mock instances could be reused, anyone willing to have a look and improve is very welcome
14:23:48 <janonymous> +1
14:24:04 <apuimedo> as a reminder, this patch is not meant to be merged right now
14:24:16 <apuimedo> rather, it should be split into smaller patches
14:24:27 <apuimedo> so with master code you can't replicate the demo just yet
14:24:56 <ivc_> apuimedo in that thread http://lists.openstack.org/pipermail/openstack-dev/2016-December/109163.html
14:25:05 <apuimedo> #info irenab posted a WIP patch for adding OVS native support https://review.openstack.org/#/c/412215/
14:25:16 <ivc_> Alexander Stafeyev has a good point that we dont have a very informative user-facing docs
14:25:24 <apuimedo> up until now we only have ovs hybrid
14:25:58 <irenab> it is missing unit tests, but please review/try it is you have time
14:26:09 <apuimedo> #info irenab reports ovs native ~ 2x pod creation burst speed performance improvement when using ovs-native binding with Dragonflow
14:26:35 <ivc_> irenab i've skimmed over that patch and it does look good, but i've not tested it yet
14:26:39 <irenab> ivc_: docs in general or on k8s?
14:26:48 <apuimedo> irenab: May I suggest that you put a local.conf.df and a local.conf.ovsnative in devstack plugin dir?
14:27:02 <irenab> apuimedo: good idea, will add it
14:27:05 <apuimedo> It makes things easier for reviewers and people wanting to try it out
14:27:07 <apuimedo> thanks irenab
14:27:24 <irenab> apuimedo: will post as separate patch
14:27:27 <apuimedo> #action irenab to add local.conf.df and local.conf.ovsnative to the ovs native WIP patch
14:27:31 <ivc_> irenab i'm mostly speaking about kuryr-k8s now, i've not checked kuryr-libnetwork docs situation
14:27:31 <apuimedo> darn
14:27:35 <apuimedo> put the action too soon
14:27:37 <apuimedo> :P
14:27:57 <apuimedo> mchiappero: tests can be improved afterwards
14:28:11 <apuimedo> but let's put it in the list of low hanging fruit for new contributors
14:28:31 <ivc_> irenab apuimedo also our README.md for kuryr-k8s has some stubs/leftovers from template
14:28:33 <irenab> ivc_: lets add doc item to the critical tasks for the first k8s-kuryr relelase
14:28:43 <ivc_> ^ +1
14:28:43 <apuimedo> agreed
14:29:18 <apuimedo> #action put README.md and doc fixes for kuryr-kubernetes 1.0.0 milestone
14:29:42 <apuimedo> I'll be posting a Dockerfile for the controller
14:30:08 <ivc_> apuimedo we also still have some races with docker containers in devstack
14:30:09 <apuimedo> so we can have automatically built Docker containers of the controller
14:30:27 <apuimedo> I'm still considering whether making one for kubelet that inherits from hyperkube
14:30:37 <irenab> ivc_: maybe worth to add the demo dockerfile to the repo if someone wants to easily reproduce the demo you did
14:30:42 <apuimedo> ivc_: which?
14:31:06 <ivc_> apuimedo k8s-controller-manager starts before etcd is fully up and running and crashes
14:31:16 <apuimedo> irenab: agreed. I propose to make it into contrib
14:31:24 <ivc_> apuimedo we need some more 'wait_for' there
14:31:27 <apuimedo> ivc_: thanks
14:31:38 <apuimedo> I thought I had it. Anyways, I have code for that
14:31:40 <apuimedo> I'll fix it
14:32:01 <apuimedo> #action apuimedo to add the wait for dependencies in devstack container start
14:32:03 <ivc_> apuimedo it's not specific, its just that it is racy by its nature of being async with 'run_container'
14:32:26 <apuimedo> ivc_: sure, in the midonet PoC I had it already solved, so it won't be a big deal to move over what I did there
14:33:44 <apuimedo> #info vikasc posted a patch for bringing nested vlan vifs to kuryr-kubernets
14:33:50 <apuimedo> #link https://review.openstack.org/#/c/410578/
14:34:13 <apuimedo> vikasc: looking forward to the new patch set addressing the posted comments :-)
14:34:19 <vikasc> i still need to test changes locally
14:34:21 <vikasc> :)
14:34:35 <vikasc> soon will be updating
14:34:45 <apuimedo> vikasc: no worries. I know you are busy with deployments
14:35:08 <apuimedo> irenab: vikasc: https://review.openstack.org/#/c/409797/
14:35:22 <apuimedo> let's have the doc issue solved before it materializes
14:35:37 <ivc_> vikasc maybe we can have some doc 'how to run kuryr-k8s with nested mode' along with those patch?
14:36:01 <apuimedo> ivc_: agreed
14:36:08 <vikasc> ivc_, sure , good idea
14:36:21 <apuimedo> vikasc: please, make it part of the patch, and if it needs some local.conf changes, please, put a sample in devstack/
14:36:38 <apuimedo> and this goes in general for everybody
14:36:46 <vikasc> apuimedo, ack
14:36:48 <apuimedo> It's important to help people reproduce
14:36:49 <apuimedo> :-)
14:37:00 <irenab> +1
14:37:04 <ivc_> +1
14:37:04 <mchiappero> +1
14:37:13 <apuimedo> anything else about kuryr-kubernetes?
14:38:02 <ivc_> apuimedo pete from port-direct suggested that we could have some integration with kolla
14:38:06 <apuimedo> just as a reminder, some of the more burning items are the /run files for deletion and the fullstack tests
14:38:11 <apuimedo> ivc_: I agree
14:38:20 <apuimedo> I think this is a very interesting field to explore
14:38:34 <apuimedo> portdirect did already a similar experiment before
14:38:37 <apuimedo> with his 'harbor'
14:38:55 <ivc_> aye
14:39:00 <apuimedo> do we have anybody here directly interested in deploying openstack over kuryr-kubernetes/kubernetes ?
14:39:22 <irenab> apuimedo: not sure what it means. Can you please elaborate?
14:39:23 <mchiappero> me
14:39:30 <janonymous> i wanna give a try
14:39:33 <apuimedo> sure
14:39:38 <apuimedo> what it means is
14:39:52 <apuimedo> you deploy keystone and Neutron with K8s hostmode networking
14:40:03 <apuimedo> then, you deploy kuryr-kubernetes too in hostmode
14:40:10 <apuimedo> pointing to the aforementioned services
14:40:37 <apuimedo> from then on, the rest of OSt services, get deployed with kuryr/neutron providing the networking
14:40:56 <apuimedo> and potentially having a driver for having each service in a different subnet
14:41:02 <apuimedo> (by namespace)
14:41:14 <apuimedo> depending on the deployer architecture and needs
14:41:27 <apuimedo> that's why I'm asking for people directly interested
14:41:32 <irenab> apuimedo: thanks
14:41:43 <ivc_> apuimedo it's essentially a trippleO, right?
14:41:51 <apuimedo> because it'd be nice to have some requirements for the first plugin (set of resource drivers)
14:42:04 <apuimedo> ivc_: quite similar to what it does
14:42:21 <apuimedo> I believe in harbor case, for example, there was no second level neutron
14:42:57 <apuimedo> there's a lot of possibilities as to which deployment models you can serve
14:43:00 <ivc_> apuimedo we need to take ironic case into account too
14:43:06 <apuimedo> ivc_: Indeed
14:43:11 <janonymous> with keystone i had a question, is there a need to register kuryr endpoints in keystone also?
14:43:27 <apuimedo> janonymous: it is not necessary
14:43:28 <ivc_> janonymous for kuryr-k8s there are no endpoings
14:43:36 <apuimedo> but it is nice to do
14:43:42 <janonymous> ahh..okay
14:43:54 <apuimedo> ivc_: IIRC in devstack I registered it somewaht
14:43:57 <apuimedo> *somehow
14:44:07 <apuimedo> I don't remember if it is in the master version though
14:44:09 <janonymous> only username was registerred
14:44:15 <janonymous> okay
14:44:23 <apuimedo> ivc_: it will probably end up having an endpoint for reporting
14:44:25 <ivc_> apuimedo janonymous maybe we'd need to look at k8s integration with OSt keystone
14:44:28 <apuimedo> and watchdog
14:44:41 <apuimedo> but that's not the sort of stuff that keystone is interested on
14:44:43 <apuimedo> :-)
14:45:00 <apuimedo> ivc_: agreed
14:45:02 <janonymous> yeah,
14:45:26 <ivc_> i mean k8s already has it, we just need to leverage it
14:45:58 <apuimedo> ivc_: I think it is an ongoing thing, the k8s keystone support
14:46:26 <irenab> apuimedo: so the answer that we probably need to register kuryr as a service?
14:46:40 <apuimedo> alright then. As I said, please, let's use ivc_'s started thread on the ML that portdirect answered to to move this forward
14:46:58 <apuimedo> irenab: 'need' is a strong word
14:47:13 <apuimedo> I think we should in general register the service
14:47:41 <apuimedo> but we do not have it as a hard requirement
14:47:51 <apuimedo> nor are we likely to leverage it in this cycle
14:47:52 <ivc_> apuimedo we might eventually get to the point where kuryr-k8s has some restapi
14:48:00 <apuimedo> ivc_: I was hinting at that
14:48:14 <ivc_> apuimedo but imo thats not gonna happen before 1.0.0 release
14:48:21 <irenab> apuimedo: for libnetwork it is not needed, correct?
14:48:24 <apuimedo> for reports, watchdogs, (even for split daemon duty made by the controller)
14:48:46 <apuimedo> irenab: for libnetwork you can have a service without endpoints too
14:48:59 <apuimedo> but with our model, putting endpoints wouldn't work
14:49:12 <apuimedo> ok, let's move on
14:49:14 <apuimedo> #topic fuxi
14:49:28 <hongbin> hi
14:49:39 <apuimedo> hongbin: thanks for reaching out to cinder go
14:49:45 <apuimedo> #chair hongbin
14:49:46 <openstack> Current chairs: apuimedo hongbin
14:49:49 <hongbin> apuimedo: my pleasure
14:49:49 <apuimedo> you have the floor
14:50:19 <hongbin> apuimedo mentioned that i just sent a ML to jhon grifft for hte ciinder docker driver
14:50:37 <hongbin> we agreed to consolidate the effort into one (sort-of)
14:50:51 <hongbin> i think this is a good news, i will reach out to him about that
14:51:06 <hongbin> next one is
14:51:16 <apuimedo> it definitely is good news
14:51:18 <hongbin> The fuxi is switching to keystone v3
14:51:22 <apuimedo> hongbin: please, use 'info'
14:51:44 <apuimedo> hongbin: do you think you can reuse some of the openstack/kuryr library code for the keystone v3 support?
14:52:07 <hongbin> apuimedo: not sure exactly, need to look into that
14:52:19 <hongbin> #info The fuxi is switching to keystone v3
14:52:29 <apuimedo> hongbin: please do
14:52:33 <hongbin> apuimedo: here is the patch i proposed
14:52:34 <apuimedo> if we can reuse code, all the better
14:52:37 <hongbin> #link https://review.openstack.org/#/c/410403/
14:52:42 <hongbin> #link https://review.openstack.org/#/c/409982/
14:52:56 <hongbin> #action hongbin look into how to resue keystone v3 code in kuryr lib
14:53:21 <hongbin> apuimedo: however, we need to merge the v3 patches above to pass the gate
14:53:44 <apuimedo> hongbin: understood
14:53:53 <apuimedo> I'll take it into account for the reviews
14:53:54 <hongbin> The non-voting fullstack pipeline is complainting
14:53:59 <hongbin> apuimedo: thx
14:54:13 <hongbin> Here is a few fullstack tests patch:
14:54:14 <hongbin> #link https://review.openstack.org/#/c/403931/
14:54:19 <hongbin> #link https://review.openstack.org/#/c/403941/
14:54:31 <hongbin> In addition, we need to get hte lastest requirement
14:54:36 <hongbin> #link https://review.openstack.org/#/c/373745/
14:54:47 <hongbin> need to merge the patch above as well
14:55:00 <apuimedo> good
14:55:13 <hongbin> those are important items last week, there are a few fixes as well
14:55:19 <hongbin> #link https://review.openstack.org/#/c/408845/
14:55:24 <hongbin> #link https://review.openstack.org/#/c/409968/
14:55:47 <hongbin> the last thing is i submitted a patch to docker upstream to list fuxi in their docs
14:55:52 <hongbin> #link https://github.com/docker/docker/pull/29468
14:55:58 <hongbin> apuimedo: that is all from my side
14:56:03 <apuimedo> thanks hongbin
14:56:06 <apuimedo> #topic general
14:56:17 <apuimedo> Any other topic, issue, comment from anybody?
14:56:21 <alraddarla_> https://review.openstack.org/#/c/405203/  could use one more +2 :)
14:56:33 <apuimedo> alraddarla_: thanks!
14:56:38 <apuimedo> It went under my radar
14:56:42 <apuimedo> will get to it today
14:56:48 <apuimedo> anything else?
14:56:50 <alraddarla_> apuimedo, thanks!
14:57:01 * apuimedo is having mox/mock dreams
14:57:38 <apuimedo> if I have one more dream of mox appearing like a mushroom amidst a clean forest of mock, I'll take holidays
14:58:19 <janonymous> hahaha, bye bye mox just 1 more patch for cleanup
14:58:41 <alraddarla_> hahaha
14:58:52 <apuimedo> yay!
14:58:59 <apuimedo> THank you all for joining!
14:59:01 <apuimedo> #endmeeting