14:01:49 <apuimedo> #startmeeting kuryr
14:01:50 <openstack> Meeting started Mon Jan  9 14:01:49 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:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:54 <openstack> The meeting name has been set to 'kuryr'
14:01:59 <apuimedo> Hello everybody!
14:02:05 <apuimedo> Welcome to another kuryr meeting?
14:02:10 <apuimedo> s/?/!/
14:02:12 <apuimedo> xD
14:02:14 <irenab> hi
14:02:17 <apuimedo> Start on the wrong foot
14:02:20 <qwebirc69418> hi
14:02:22 <alraddarla_> o/
14:02:26 <mchiappero> o/
14:02:29 <ivc_> o/
14:02:31 <apuimedo> let's see how many typos I can make today
14:03:03 <ltomasbo> o/
14:03:12 <apuimedo> vikas messaged me that he most likely won't be able to attend today
14:03:34 <apuimedo> thank you all for showing up
14:03:37 <apuimedo> #topic kuryr-lib
14:03:50 <apuimedo> #info We released kuryr-lib 0.3.0
14:04:12 <apuimedo> #info it includes a refactor of the keystonauth1 code so now fuxi can leverage it too
14:04:31 <apuimedo> In other news
14:05:19 <apuimedo> #info svinota pushed a new release of pyroute2 https://github.com/svinota/pyroute2/releases/tag/0.4.12 which includes the namespace fixes we needed
14:05:35 <apuimedo> #action apuimedo to send a patch to up the pyroute2 upper constraints
14:06:21 <ivc_> apuimedo what exactly did we need from those?
14:07:20 <apuimedo> #link https://github.com/svinota/pyroute2/commit/db97c896c12d4aee555fd182b97e426cb561e29b
14:07:34 <apuimedo> #link https://github.com/svinota/pyroute2/commit/0aff806bd504172ddc8bb951cc707a1d390a7043
14:07:35 <ivc_> apuimedo thats https://github.com/svinota/pyroute2/issues/317
14:07:39 <apuimedo> and there was one more important
14:07:50 <apuimedo> right
14:08:09 <apuimedo> ivc_: that's the issue, and all the patches that fix it were finally part of a release last week
14:08:24 <ivc_> i mean we could use net_ns_pid instead of net_ns_fd
14:08:57 <ivc_> instead of /proc/self
14:09:30 <apuimedo> I prefer we move to use paths, isn't it better?
14:09:56 <ivc_> either one is fine
14:10:22 <ivc_> afaik net_ns_pid were available in kernel before net_ns_fd
14:10:32 <apuimedo> I think vikasc's patch for k8s container-in-vm used the paths, and hence why I ask svinota to cut a new release
14:11:28 <apuimedo> anything more on kuryr-lib?
14:12:27 <hongbin> o/
14:12:57 <apuimedo> hi hongbin!
14:13:01 <apuimedo> #topic kuryr-libnetwork
14:13:23 <apuimedo> we got quite a few patches to review irenab :-)
14:13:32 <irenab> apuimedo: indeed
14:13:47 <apuimedo> ltomasbo's https://review.openstack.org/402462 is passing the gates, so we should try to get it in soon
14:14:28 <apuimedo> also we should review this new tests
14:14:29 <irenab> are we waiting to get few fullstack tests or they will come as a folowup?
14:14:35 <apuimedo> #action irenab apuimedo to review https://review.openstack.org/414903
14:14:45 <apuimedo> for container-in-vm?
14:14:48 <apuimedo> Follow-up
14:15:22 <apuimedo> we probably want them as a separate gate with a beefier node
14:15:33 <irenab> the documentation for setting the environment for the nested should be included
14:16:02 <irenab> similar to the one in kuryr-k8s
14:16:31 <apuimedo> agreed
14:16:34 <apuimedo> ltomasbo: ^^
14:16:51 <apuimedo> #action ltomasbo to include docs for testing out the container-in-vm
14:17:05 <ltomasbo> ok, I can add something similar, but please do the review on the rest
14:17:11 <apuimedo> sure
14:18:47 <apuimedo> anything more on kuryr-libnetwork (apart from vikas, irenab and I having to finish the review queue)?
14:19:28 <mchiappero> uhm, I would like to ask whether it could be interesting to change the subnetpool request logic
14:19:43 <apuimedo> mchiappero: go ahead
14:20:18 <mchiappero> currently when a pool is requested: if the name is passed in it always creates a new subnetpool (never reuses)
14:20:37 <mchiappero> without the name useses the default but fails if already present
14:20:47 <mchiappero> so, there is no way to reuse a pool by providing the name
14:20:57 <mchiappero> this can be useful for nested containers
14:21:12 <apuimedo> mchiappero: can you link the code sections
14:21:15 <apuimedo> ?
14:21:22 <mchiappero> of the existing code?
14:21:34 <apuimedo> yeah
14:21:46 * apuimedo thinking about meeting logs :P
14:21:47 <mchiappero> I'm referring to the whole RequestPool function
14:22:03 <irenab> mchiappero: are you talking about the case when provided name matches already existing name?
14:22:43 <mchiappero> it would be nice to find a clean way to let different containers in different VMs use consistent docker networks, so essentially sharing the same network and subnetpool resources
14:22:58 <mchiappero> irenab: right
14:23:23 <irenab> mchiappero: sounds to me like its a bug in current impementation
14:23:25 <mchiappero> well whatever method that is deemed appropriate to allow this
14:23:34 <mchiappero> is that interesting?
14:23:50 <apuimedo> #link https://github.com/openstack/kuryr-libnetwork/blob/f44c3603802af9918fa9021e64eb1add425ba41e/kuryr_libnetwork/controllers.py#L1181-L1272
14:24:16 <apuimedo> yes
14:24:17 <mchiappero> irenab: I'm not to sure about the rationale behind this, maybe there is a reason I ignore :)
14:25:32 <mchiappero> ok, so, I don't have a proposal and lack time these days, but if you have one let's discuss about it in the chat
14:25:44 <apuimedo> "This API is for registering an address pool with the IPAM driver. Multiple identical calls must return the same result. It is the IPAM driver's responsibility to keep a reference count for the pool."
14:26:07 <apuimedo> mchiappero: so we are violating the contract of "Multiple identical calls must return the same result" ?
14:26:39 <mchiappero> uhm, probably...
14:26:45 <irenab> mchiappero: can you please report a bug?
14:27:05 <mchiappero> ok, I'll double check and report in case
14:27:43 <mchiappero> (I'm done on this topic)
14:28:17 <apuimedo> thanks
14:28:21 <apuimedo> moving on
14:28:35 <apuimedo> #topic kuryr-kubernetes
14:29:48 <apuimedo> #action ivc_ to review Irena's services doc patch https://review.openstack.org/#/c/416228/
14:30:03 <apuimedo> irenab: do you know why dragonflow gate fails?
14:30:31 <irenab> apuimedo: I think the patch to infra that fixesthis, was just merged. Let me retriger the gate
14:31:27 <apuimedo> irenab: thank
14:31:29 <apuimedo> *thanks
14:32:34 <apuimedo> #action ivc_ to review vikas container-in-vm patch https://review.openstack.org/#/c/410578/
14:33:16 <ivc_> apuimedo sure
14:33:48 <apuimedo> thanks ivc_ !
14:35:07 <apuimedo> ok
14:35:47 <apuimedo> vikasc has also been working on a demo that shows kuryr-kubernetes with openshift  and openstack in baremetal
14:36:00 <apuimedo> I think next week he'll probably share an asciicinema link ;-)
14:36:04 <irenab> apuimedo: any video available?
14:36:11 <irenab> thanks :-)
14:36:25 <apuimedo> we're still shortening the video
14:36:27 <apuimedo> :-)
14:36:38 <apuimedo> but the good news is that everything works well
14:36:45 <apuimedo> he'll send some patches upstream
14:37:01 <apuimedo> about connecting to SSL kubernetes API servers and other things
14:37:15 <apuimedo> that he just hacked on the environment
14:37:47 <ivc_> apuimedo it's probably time to move to some real k8s client in kuryr-k8s
14:38:00 <ivc_> apuimedo pykube maybe
14:38:23 <irenab> ivc_: for devstack?
14:38:29 <apuimedo> ivc_: that's the one we used for the fullstack tests on Midokura's PoC
14:38:53 <apuimedo> the problem with using that for the "watch" functionality is that there's doubts on pykube's mainatenance
14:39:06 <apuimedo> I, at least, haven't checked how they maintain it
14:39:09 <ivc_> irenab no, to replace 'requests' in https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/k8s_client.py
14:39:25 <apuimedo> and unless we are at peace with how that is done
14:39:34 <apuimedo> I'd not be in favor
14:39:52 <apuimedo> (as much as I want to drop code)
14:40:13 <apuimedo> #action apuimedo study pykube maintainership and distros presence
14:40:34 <irenab> ivc_: is there any recomended clients by k8s guys?
14:40:44 <ivc_> apuimedo what i mean is that extending k8s_client.py into a full-featured client does not seem to be a good idea
14:40:55 <irenab> ivc_: agree
14:40:57 <apuimedo> irenab: we can move to grumpy and use existing k8s go client xD
14:41:22 <apuimedo> ivc_: did you hear about grumpy?
14:41:28 <irenab> apuimedo: maybe not a bad idea :-)
14:41:48 <apuimedo> not at all, but we'd have to get rid of any c extensions we have
14:41:56 <apuimedo> and grumpy is alpha
14:42:19 <apuimedo> ivc_: for the short term, my concern is that if we pick pykube, we have to be able to contribute to it
14:42:25 <irenab> yea, seems abit early to use it
14:42:35 <apuimedo> and add things we may need, like SSL, websockets, etc
14:42:36 <ivc_> apuimedo isn't grumpy a python -> go?
14:42:48 <apuimedo> ivc_: it allows you to use Go classes as well
14:42:50 <apuimedo> :-)
14:42:54 <ivc_> ah ok
14:43:27 <ivc_> i wonder what TC would have to say about python running on golang env
14:43:31 <apuimedo> but it's a very good point on the k8s client code. It's something that ideally shouldn't be part of openstack/kuryr-kubernetes
14:43:41 <apuimedo> ivc_: I'll let you guess :P
14:43:45 <ivc_> :P
14:44:20 <apuimedo> alright
14:44:23 <apuimedo> anything else?
14:44:45 <apuimedo> ivc_: I suppose you'll start splitting up the services patch
14:44:52 <ivc_> apuimedo yup
14:45:05 <apuimedo> cool, hopefully we can merge container-in-vm soon too
14:45:20 <apuimedo> I'll go to PTG and see if magnum can start using kuryr-kubernetes too
14:45:32 <apuimedo> once that is merged
14:45:52 <hongbin> magnum requires the trust feature AFAIK
14:45:53 <ivc_> i hope to finish most of the services patch split this/next week
14:46:07 <apuimedo> hongbin: I thought that's transparent if we support keystoneauth1
14:46:12 <apuimedo> isn't it?
14:46:33 <hongbin> apuimedo: not sure, need to do an investigation on that
14:46:41 * janonymous got late for meeting, reading backlogs
14:46:51 <apuimedo> janonymous: welcome
14:46:53 <apuimedo> ivc_: cool
14:47:18 <apuimedo> I'm hoping next week I can start work on the port file patch
14:47:33 <apuimedo> and we can start planning the cni split
14:47:50 <apuimedo> (which is almost a precondition for the port reusal driver)
14:48:03 <apuimedo> s/reusal/reuse/
14:48:52 <janonymous> i saw another k8s client here few days back : https://github.com/kubernetes-incubator/client-python
14:49:15 <apuimedo> :O
14:49:19 <hongbin> great
14:49:22 <apuimedo> #link https://github.com/kubernetes-incubator/client-python
14:49:27 <apuimedo> we gotta check that out!
14:50:05 <hongbin> it looks very young though (3 months history)
14:50:27 <janonymous> yeah! thought to mention to avoid double efforts
14:50:27 <apuimedo> interesting, urllib3 directly instead of requests
14:50:48 <ivc_> apuimedo it also uses swagger to generate code similar to https://github.com/openstack/python-k8sclient
14:51:27 <apuimedo> :O
14:52:09 <apuimedo> I'm in principle against code generation... Makes for unidiomatic APIs, but let's check it
14:52:27 <ivc_> apuimedo in this case swagger is the right thing imo
14:52:33 <apuimedo> noted
14:52:36 <apuimedo> #topic general
14:52:44 <apuimedo> any other topic before we close for today?
14:53:05 <hongbin> apuimedo: i would spend a few minutes to give a update on fuxi :)
14:53:36 <hongbin> apuimedo: might i ?
14:54:05 <apuimedo> hongbin: of course
14:54:08 <apuimedo> sorry
14:54:09 <apuimedo> #topic fuxi
14:54:14 <apuimedo> #chair hongbin
14:54:14 <openstack> Current chairs: apuimedo hongbin
14:54:31 <hongbin> during the holiday, we got the gate voting on dsvm jobs
14:55:01 <hongbin> besides that, there are several small fixes proposed
14:55:44 <hongbin> most importantly, we relseased a new kuryr-lib, which make the keystoneauth patch passed the gate
14:55:46 <hongbin> #link https://review.openstack.org/#/c/410403/
14:55:56 <hongbin> apuimedo: that is it from me
14:56:06 <apuimedo> very well
14:56:21 <apuimedo> thanks hongbin
14:56:28 <apuimedo> and sorry that I forgot the section
14:56:33 <hongbin> apuimedo: oh, btw, zhangni was looking for feedback for the manila integration: https://review.openstack.org/#/c/375452/
14:56:53 <hongbin> apuimedo: np
14:57:01 <apuimedo> #action irenab apuimedo to review manila integration patch
14:57:16 <apuimedo> Thank you all for joining today!
14:57:18 <apuimedo> #endmeeting