14:00:09 <dmellado> #startmeeting kuryr
14:00:10 <openstack> Meeting started Mon May  7 14:00:09 2018 UTC and is due to finish in 60 minutes.  The chair is dmellado. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:14 <openstack> The meeting name has been set to 'kuryr'
14:00:54 <dmellado> o/ Hi fellow kuryrs, who's here today to enjoy the exciting world of meetings?
14:00:57 <dulek> I've made it. :)
14:01:16 <danil> o/
14:01:32 <dmellado> #chair dulek
14:01:32 <openstack> Current chairs: dmellado dulek
14:01:49 <yboaron> Hi !
14:01:56 <dmellado> #chair yboaron
14:01:57 <openstack> Current chairs: dmellado dulek yboaron
14:03:27 <ltomasbo> o/
14:03:35 <dmellado> #chair ltomasbo
14:03:36 <openstack> Current chairs: dmellado dulek ltomasbo yboaron
14:03:39 <dmellado> all right
14:03:44 <dmellado> #topic kuryr-kubernetes
14:04:14 <dmellado> So, folks, besides all the terror stories that we've been having as of lately with the upstream infra, who has something to share on the topic? ;)
14:04:54 <ltomasbo> on the infra topic?
14:04:56 <ltomasbo> xD
14:05:03 <dulek> I'm back from PTO today, I'll be catching up with reviews.
14:05:13 <dulek> Don't worry, I don't delete any emails from Gerrit. ;)
14:05:28 <dmellado> dulek: lol
14:05:39 <dmellado> does that mean that you deleted mine? caught you
14:05:41 <dmellado> xD
14:05:51 <dmellado> ltomasbo: hopefully not on the infra topic
14:06:11 <ltomasbo> dmellado, then, reviews on https://blueprints.launchpad.net/kuryr-kubernetes/+spec/network-namespace are welcome!
14:06:11 <dmellado> I just noticed a race condition on the tempest plugin devstack plugin
14:06:14 <dmellado> heh, metaplugin
14:06:20 <ltomasbo> I'm working on the tempest tests for that
14:06:39 <dmellado> when it tries to install the plugin, it doesn't get off with the docker image built before installing docker so it fails
14:07:00 <dmellado> I'm testing a patch that just delays that creation to the very end of the devstack installation
14:07:12 <dmellado> #link https://blueprints.launchpad.net/kuryr-kubernetes/+spec/network-namespace
14:08:15 <dmellado> now that we speak about reviews, danil, do you need anything taken a look into?
14:08:24 <danil> yeah
14:08:27 <danil> I would like to ask some questions about multi-vif & sriov patches in kuryr-k8s. I have fixed the most part of problems, core developers have mentioned
14:08:36 <danil> What do you think, is it worth to merge these patches sequentially. I mean , first patch (https://review.openstack.org/#/c/471012/) is fully ready as I can see. It only changes a type of pod annotation, without changes in other functionality (it is specified in commit message)
14:08:38 <dmellado> danil: shoot then ;)
14:08:56 <danil> If not, I would like to hear my forward steps in work with these patches
14:09:34 <dmellado> #link https://review.openstack.org/#/c/471012/
14:10:30 <dulek> Aww, I was supposed to propose an alternative to maybe_callback for that one… I'll need to do it ASAP.
14:10:36 <dmellado> danil: if it just adds a type of pod annotation I'd be fine
14:10:45 <dmellado> in any case zuul and dulek give you -1
14:10:47 <dmellado> :)
14:11:01 <dmellado> dulek: ltomasbo I see that you've been addressing comments there
14:11:10 <dmellado> could you follow up so we can iterate and start merging this soon?
14:11:20 <dulek> dmellado: Heh, the maybe_callback thing can be addressed by refactor later if I won't come up with solution now. ;)
14:11:24 <danil> i've changed this patch according to dulek's remarks, as I remember
14:11:29 <dmellado> otherwise we'll be celebrating these patch's anniversary
14:11:38 <dulek> dmellado: So no -1 until I know exactly if there's a better way.
14:11:42 <dmellado> dulek: in any case please do leave some comment regarding that
14:11:45 <zhangoic> I have a question. When using kuryr, the kube-proxy is not necessary, is it right?
14:11:47 <dulek> For now it's just a wild hunch. :P
14:11:57 <dmellado> danil: please address the patch so it passes CI and I'll get some eyes on it ;)
14:12:29 <yboaron> zhangoic, that's correct
14:12:47 <dmellado> yboaron: go ahead ;)
14:12:50 <zhangoic> thanks
14:12:57 <ltomasbo> danil, I have another comment about the patch, as it only adds support for the daemon based cni, perhaps it is worthy to add it to the documentation
14:12:58 <danil> dmellado:  I don't understand what ddo you mean, sorry
14:13:05 <dmellado> danil: the link that you passed to me
14:13:06 <ltomasbo> otherwise we will forget about it...
14:13:07 <dmellado> https://review.openstack.org/#/c/471012/
14:13:25 <dmellado> is currently not passing CI
14:13:31 <dmellado> see zuul verified -1 there
14:13:46 <dmellado> it could be a glitch on the CI but nothing will get merged until it gives +1 there ;)
14:14:13 <dmellado> yboaron: could you elaborate on this? otherwise it's just yes - no
14:14:15 <dmellado> xD
14:14:46 <danil> yeap, I see. What should I cahange for that?
14:14:53 <danil> how to pass CI ?
14:15:22 <yboaron> dmellado, kube-procy is used in K8S for mapping service-name/IP to service's pods (actually by setting IP table rules)
14:15:31 <yboaron> proxy
14:15:36 <dmellado> yboaron: I'm aware that we just use neutron for that
14:15:44 <dmellado> but I wonder if it would make sense to add that to the docs
14:15:59 <yboaron> so with kuryr we use Neutron LBaaS or Octavia for that purpose
14:16:46 <zhangoic> kuryr support the type of clusterIP for service?
14:17:05 <dmellado> danil: so, for example
14:17:06 <dmellado> http://logs.openstack.org/12/471012/37/check/openstack-tox-lower-constraints/0001367/ara-report/
14:17:20 <ltomasbo> zhangoic, that's right, and LoadBalancer type
14:17:25 <zhangoic> How about nodeport service in k8s
14:17:34 <dmellado> that seems to be an issue on the infra
14:17:40 <ltomasbo> zhangoic, there is no support for nodeport
14:17:41 <dmellado> so just recheck it for now
14:17:55 <danil> sure, thanks
14:18:03 <dmellado> you can also go to the openstack-infra channel
14:18:07 <dmellado> and ask any cores
14:18:16 <yboaron> zhangoic, try this link #link https://docs.openstack.org/kuryr-kubernetes/latest/installation/services.html
14:18:25 <danil> dmellado: thanks a lot
14:18:25 <zhangoic> OK
14:18:33 <dmellado> and also when you're waiting for it, you can check zuul.openstack.org
14:18:40 <dmellado> and see in real time what's going on with that exact gate
14:19:04 <danil> dmellado: sure, I see. Thanks. Hope this patch to be merged soon
14:19:26 <dmellado> danil: https://www.youtube.com/watch?v=fowBDdLGBlU
14:19:33 <dmellado> slightly old but I guess watching that would still be useful
14:20:23 <dmellado> danil: in any case if you get stuck at it feel free to ping  us on the kuryr channel
14:20:32 <dmellado> I would also like to start getting the feature merged
14:20:49 <danil> dmellado: sure, thank you
14:22:29 <yboaron> I can update on ingress controller patches..
14:22:53 <dmellado> yboaron: go ahead
14:22:56 <dmellado> thanks!
14:23:19 <yboaron> So, I received comments from Luis&Toni, Toni's suggested to have a single driver for both endpoints and ingress/routes
14:24:19 <dmellado> hm, it's true that I'd also like to tidy up the driver section as it's quite widespread, so opverall +1 on that
14:24:34 <yboaron> and it sound reasonable, my first patch is just to prepare LBasS driver before extending it to support ingress
14:24:48 <yboaron> #link https://review.openstack.org/#/c/566175/
14:25:19 <dmellado> yboaron: thanks, I will put that to my review queue too
14:25:26 <yboaron> second patch just adds support for the ingress controller LB manual creation fir devstack deployment
14:25:37 <ltomasbo> 'just' xD
14:25:45 <dmellado> lol
14:25:55 <yboaron> #link https://review.openstack.org/#/c/564051/
14:26:00 <dmellado> ltomasbo: don't tell me that is one of 'these' patches
14:26:06 * dmellado opens it waiting for 300+ loc
14:26:31 <dmellado> ltomasbo: 117, could've been much bigger
14:26:43 <yboaron> I have two more patches in the oven to support ingress controller and the second for ocp-route handler
14:26:49 * dmellado just recalls about .zuul.yaml and the fact that he needs to rebase the split patch
14:26:51 <ltomasbo> I thought it was the next one!
14:27:40 <yboaron> ltomasbo, did you mean to the ingress controller patches or something else
14:27:51 <dmellado> heh, you were surprised, just like me when I was told that apuimedo passed customs in the end
14:28:05 <ltomasbo> yep! I already took a look at both patches you just posted and they look ok
14:29:24 <yboaron> ltomasbo, thanks!, I need to update #link https://review.openstack.org/#/c/536387/  with Toni's comments
14:29:50 <dmellado> yboaron: do you have a gerrit topic for the whole effort?
14:30:05 <ltomasbo> yboaron, yep, I saw that, please ping me when you have done so (I want to test it too!)
14:30:06 <yboaron> I have BP
14:30:27 <yboaron> ltomasbo, I"ll ping you
14:30:32 <ltomasbo> thanks!
14:30:34 <dmellado> yboaron: awesome, I'll put some comments as well
14:30:44 <dmellado> so, anything else folks?
14:31:01 <yboaron> Q: do we support devstack deployment for the nested case ?
14:31:21 <dmellado> yboaron: we're waiting for a patch on zuul to get merged
14:31:26 <dmellado> and then we'll have multinode support
14:31:36 <dmellado> please do notice that by multinode I mean several compute nodes
14:31:53 <dmellado> once that that's done I'll add the nested scenario as we'll have enough capacity
14:31:56 <ltomasbo> yboaron, we have the local.conf files for it, but it is not tested right now on the gates
14:32:10 <dmellado> I'm not sure on the  speed, though, as the upstream infra doesn't support nested kvm
14:32:14 <dmellado> so it might be quite sluggish
14:32:21 <dmellado> so that's the current status
14:32:31 <dmellado> ofc as ltomasbo said, you can try on your own if you've a machine big enough
14:32:33 <dmellado> ;)
14:32:33 <yboaron> ltomasbo, it's seems that it not tested
14:32:59 <ltomasbo> yboaron, it is not tested due to gate limitations
14:33:16 <ltomasbo> yboaron, but you can try it on your machine (if you have 16Gb or so)
14:33:20 <dmellado> https://review.openstack.org/#/c/558762/
14:33:24 <dmellado> ^^
14:33:32 <dmellado> so, that's the patch which is waiting on its dependant to get merged
14:33:46 <dmellado> we'll be able to add more capacity and test nested upstream after it
14:33:55 <dmellado> as well as openshift-ansible installation, hopefully
14:33:59 <yboaron> ltomasbo, I meant from code prespective , we don't 'clean' kuryr openstack infra resources (LB, etc) on unstack
14:34:29 <ltomasbo> ahh, that is most probably the case
14:34:42 <dmellado> yboaron: what usecase you have in mind?
14:34:50 <dmellado> if it's for CI I'd say we just 'don't care'
14:34:59 <ltomasbo> yboaron, but usually I have to do 2 stacks (one for the undercloud, one for the overcloud)
14:35:04 <yboaron> stack+unstack+stack for nested
14:35:20 <ltomasbo> so, it is hard to have a complete cleanup, though I guess if you remove the undercloud, everything is gone anyway
14:35:21 <yboaron> all for the overclpoud
14:35:33 <yboaron> overcloud
14:35:37 <ltomasbo> ahh, no, for just the overcloud it will not work
14:37:30 <yboaron> OK, 10x!, do u think we should support such use case ?
14:37:37 <dmellado> hmmm
14:37:44 <dmellado> yboaron: for the CI part, not really a need tbh
14:37:57 <dmellado> just for dev side it'd be nice but I don't think it's a must-have
14:38:19 <yboaron> OK, I file a bug for that, and we"ll see
14:38:28 <ltomasbo> please do!
14:38:54 <dmellado> yboaron: also ltomasbo looked like he wanted to volunteer for this
14:39:01 <dmellado> so you can assign him
14:39:03 <dmellado> :D
14:39:05 <ltomasbo> yboaron, though I guess that is not easy to do unless we have kuryr resources on CRDs
14:39:58 <yboaron> ltomasbo, I thought to 'clean' just the infra resources first
14:40:15 <yboaron> by infra I mean kury-kubernets LB, SG, etc
14:40:46 <yboaron> BTW, do we have solution for that in openshift-ansible case?
14:40:51 <ltomasbo> but how do you know what LBs belong to one or the other?
14:41:32 <ltomasbo> yboaron, in openshift-ansible I proposed this (as it is simpler as we deploy with heat templates):  https://github.com/openshift/openshift-ansible/pull/8254/files
14:42:01 <ltomasbo> but it is slightly different, as we have real overcloud/undercloud also, here we call it undercloud/overcloud
14:42:11 <ltomasbo> but it is more like worker node on a VM
14:42:11 <yboaron> the deployment code should know which resources were created for the deployment , right ?
14:42:44 <yboaron> ltomasbo, anyhow, let's take it offline, is it OK with you ?
14:42:46 <ltomasbo> yboaron, yep, but if you have a sg being used by a kuryr created pod, it will not be able to delete it
14:42:51 <ltomasbo> sure sure
14:42:59 <ltomasbo> let's move to the next topic!
14:43:19 <dmellado> so next topic it's easy
14:43:33 <dmellado> #topic open discussion
14:44:01 <dmellado> Just wanted to let you know that after getting the feedback from the PTG
14:44:25 <dmellado> we won't be going there as a group, and instead we'll get to talk about whether we do a mid-cycle elsewhere, a VTG again or even both
14:45:13 <dmellado> I might go to Denver (choo-choo) again just to interact with another projects, such as infra and QA (and probably Octavia) though
14:45:40 <dmellado> if you didn't get to know the choo-choo then you were lucky and didn't get to attend that PTG xD
14:47:22 <dmellado> and I guess this finishes today's meeting
14:47:31 <dmellado> I'll save you 13 minutes of your life
14:47:35 <dmellado> thanks for attending everyone!
14:47:58 <ltomasbo> xD
14:48:08 <dmellado> #endmeeting
14:48:12 <dmellado> #endmeeting