14:01:21 <apuimedo> #startmeeting kuryr
14:01:21 <openstack> Meeting started Mon Jun 19 14:01:21 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:25 <openstack> The meeting name has been set to 'kuryr'
14:01:31 <apuimedo> Who's here for the meeting this week?
14:01:35 <vikasc> o/
14:01:39 <danil> o/
14:01:44 <irenab> o/
14:01:45 <ltomasbo> o/
14:01:46 <janonymous> o/
14:01:58 <limao_> o/
14:02:29 <apuimedo> #topic kuryr-libnetwork
14:02:32 <zengchen> #join #openstack-kuryr
14:02:38 <zengchen> sorry
14:02:39 <garyloug> o/
14:02:58 <apuimedo> The biggest thing happening in kuryr-libnetwork is hongbin's patch to add support for specifying subnets
14:03:06 <apuimedo> limao_ has been reviewing it
14:03:28 <limao_> apuimedo: yes, discussed with hongbin
14:03:32 <apuimedo> I defer to his good judgement
14:03:39 <apuimedo> limao_: I saw the points you made
14:03:42 <apuimedo> of the three cases
14:03:47 <apuimedo> no subnet, 1:1 and 1:N
14:03:49 <apuimedo> I agree
14:04:24 <apuimedo> does anybody else have some questions, points to make on kuryr-libnetwork?
14:05:51 <apuimedo> alright
14:05:53 <apuimedo> moving on
14:06:02 <apuimedo> #topic kuryr-kubernetes
14:06:10 <danil> I'd like to ask you opinion about my featute in kuryr-k8s project I work on currently.
14:06:18 <danil> This feature is based on feature of Kirill about Sriov support: https://review.openstack.org/#/c/462455/
14:06:29 <danil> It's about specific ports for SRIOV VFs. I want to specify specific ports (port ids) in pod spec manually while pod creating. Specific ports will be attached to requested VFs firstly. If amount of specific ports is less then amount of requested VFs than others (remaining) ports will be requested from neutron by ordinar way.
14:06:44 <danil> Also this specific ports will not be deleted after deployment deleting
14:07:03 <danil> It's an old version of feature: https://review.openstack.org/#/c/468032/ I work on changes now
14:07:12 <irenab> danil: can it be generic port_id request?
14:07:13 <apuimedo> danil: this sounds quite in line with what kzaitsev1pi was proposing
14:07:34 <irenab> not specific to SR-IOV?
14:07:47 <danil> it's specific to sriov
14:07:55 <apuimedo> irenab: danil: There's two things here
14:08:08 <apuimedo> one of them is that if you annotate the vifs directly in your spec
14:08:13 <apuimedo> then kuryr-controller should inhibit
14:08:17 <apuimedo> and cni should bind
14:08:32 <apuimedo> that works for both sr-iov and for any other kind of neutron port
14:08:37 <apuimedo> s/port/vif/
14:08:40 <irenab> apuimedo: agree, cni is pecific, but controller part seems generic enough
14:08:46 <apuimedo> the other thing is about requesting
14:09:24 <danil> about requesting. Specific ports are created manually
14:11:19 <irenab> I think requesting specific port ids may be useful if you want to map to some port with qos settings, sgs, etc.
14:12:00 <irenab> danil: apuimedo : added the patch to my review queue
14:12:09 <ltomasbo> in a similar discussion line
14:12:11 <danil> yes, exactly
14:12:14 <danil> thanks
14:12:25 <ltomasbo> could we also add something for the subnet (or network) the pod should be in?
14:12:39 <ltomasbo> so that instead of having to use the hardcoded one at the kuryr.conf
14:12:40 <apuimedo> and that, for now seems good
14:12:55 <danil> currently I worl only on specific ports
14:12:56 <apuimedo> but frankly
14:13:01 <ltomasbo> we could then decide on the subnet the pod should be in?
14:13:08 <apuimedo> I'd rather it'd be a separate driver
14:13:39 <apuimedo> the default subnet driver is meant to be simple, not with overrides
14:14:37 <irenab> apuimedo: correct. the ‘default’ driver was about getting options from config
14:14:48 <ltomasbo> apuimedo, I was thinking about having some annotation with the CIDR, so that we can create the container in the specified subnet (even create it if it does not exists)
14:14:57 <ltomasbo> similarly to how we do in kuryr-libnetowrk
14:15:40 <irenab> ltomasbo: what about having multiple networks in k8s? then it may be the network annotattion
14:15:41 <apuimedo> ltomasbo: that's fine
14:15:48 <apuimedo> but I'd rather that be a different driver
14:15:54 <vikasc> and if annotation not found, pick from config?
14:16:05 <apuimedo> honestly
14:16:14 <irenab> vikasc: it depends on the drivers in the deployment
14:16:21 <apuimedo> this is an area where I expect contribution
14:16:30 <apuimedo> people coming up with different and better drivers
14:16:36 <apuimedo> the ones right now are sample level
14:17:01 <irenab> apuimedo: it probably should come with the RFE/bp. Driver is just an implementation detail
14:17:04 <vikasc> like the one, "subnet_of_choice" driver
14:17:35 <vikasc> ofcource a better name :)
14:17:40 <ltomasbo> :D
14:17:42 <vikasc> s/ofcourse
14:17:44 <apuimedo> irenab: bp at most
14:17:55 <apuimedo> I'd require more to change the default
14:18:01 <apuimedo> for adding drivers... Not so much
14:18:54 <ltomasbo> irenab, that is a good point, how to handle both, specifying different subnets, but also enabling multi-networks
14:19:38 <irenab> I wonder if app devs would really wnat to deal with subnets
14:20:14 <ltomasbo> perhaps just network
14:20:33 <apuimedo> irenab: I think this is more of a ops thing
14:20:33 <irenab> especially on pod level. I think it better be defined on network/namespace level
14:20:35 <apuimedo> not app dev
14:20:37 <ltomasbo> I was thinking something like: I want this container in 10.10.0.0/24
14:20:52 <vikasc> i guess providing both, subnet of choice and multiple networks , would add both, lot of flexibility and confusion as well for app devel;oper
14:20:53 <apuimedo> or vnf dev
14:20:58 <irenab> apuimedo: exactly, so pod level is not really good option
14:21:45 <irenab> I think its more : I want this container of extra fast network
14:22:16 <vikasc> wondering what are the use cases which can only be addressed by having subnet_of_choice and not by multiple_networks
14:23:34 <vikasc> network-subnet 1-1 mapping
14:23:57 <apuimedo> frankly, apart of dual stack, I don't really have any idea why would somebody want multiple subnets on a net
14:24:19 <vikasc> +1
14:24:34 <ltomasbo> agree
14:24:39 <irenab> me too
14:25:10 <apuimedo> but as usual, we're open to hear otherwise
14:25:13 <apuimedo> :-)
14:25:33 <vikasc> so instead of focussing on providing a way to request multiple subnets per network, i would vote for focussing on multiple networks
14:25:48 <apuimedo> vikasc: that's right
14:25:48 <irenab> vikasc: +1
14:25:54 <ltomasbo> agree too
14:26:00 <vikasc> wondering how multiple networks effort is converging upstream k8s
14:26:11 <apuimedo> what we really need is somebody to follow the progress of the upsream PoC and make our own based on it
14:26:15 <irenab> vikasc: Are you in details of the k8s multi network implementation status?
14:26:19 <vikasc> if anyone is updated with current state
14:26:46 <vikasc> i could not check in last two weeks irenab
14:26:55 <irenab> apuimedo: I can  try to check it for next week
14:27:03 <apuimedo> irenab: that'd be great
14:27:10 <apuimedo> danil: you're welcome to do that as well
14:27:29 <danil> ok, thanks a lot
14:27:47 <irenab> anyway, it seems ortogonal to requesting specific port, that seems to be useful feature
14:27:54 <vikasc> and may be if we see that it seems to be taking still a lot longer
14:28:13 <danil> I will complete and will send to review
14:28:13 <vikasc> we can try implementing multinetwork support using annotations in kuryr
14:28:25 <vikasc> that call we can take
14:29:28 <vikasc> because IIRC , we said last time to wait because it lloke like it was going to come natively in k8s
14:29:45 <apuimedo> vikasc: it's annotations + tpr upstream
14:29:55 <apuimedo> I really would like to know how they are using tpr
14:29:59 <apuimedo> in that workflow
14:30:00 <vikasc> apuimedo, yeah it was around month back
14:30:24 <vikasc> apuimedo, tpr for just holding network object
14:30:51 <vikasc> apuimedo, and propagate info through annotations
14:31:03 <apuimedo> so network reference in the pod
14:31:07 <apuimedo> and netowrk object as tpr
14:31:10 <apuimedo> right
14:31:13 <vikasc> apuimedo, yes
14:31:22 <vikasc> its pretty simple
14:31:43 <apuimedo> I don't see how network object serve us though
14:32:22 <vikasc> its for holding network metadata i guess
14:32:30 <apuimedo> yeah
14:32:35 <apuimedo> but we have it in Neutron
14:32:42 <apuimedo> I remember ivc_ had a proposal for moving most annotations to tprs
14:32:43 <vikasc> for k8s user
14:33:16 <ltomasbo> vikasc, do you have any link with useful information about this? (status, target, design, ...)
14:33:42 <vikasc> i will seach and send
14:33:49 <vikasc> s/search
14:33:55 <vikasc> and share ok kuryr channel
14:34:00 <vikasc> s/on
14:34:13 <apuimedo> thanks vikasc
14:34:15 <vikasc> ltomasbo, it is on google groups , signetwork
14:34:28 <vikasc> i will find out
14:34:39 <ltomasbo> vikasc, thanks!
14:34:44 <vikasc> yw!
14:35:34 <irenab> apuimedo: regarding https://review.openstack.org/#/c/472763/
14:36:09 <irenab> still does not work for me completely, but all the trunk setting is very useful
14:36:15 <apuimedo> #info Installation instructions were merged  https://docs.openstack.org/developer/kuryr-kubernetes/installation/index.html
14:36:53 <apuimedo> irenab: I'll try to get some time this week to go step by step with you so I can spot where I put the bug
14:37:11 <irenab> I also posted some question there
14:37:19 <apuimedo> ah, cool
14:37:21 <apuimedo> I'll check
14:37:51 <irenab> regarding the installation instructions
14:38:21 <irenab> where the special configuration of the service account/role/service-router is supposed to be covered?
14:38:23 <apuimedo> #info janonymous fixed vagrant devstack
14:39:19 <apuimedo> #info Also work is progressing into making kuryr-kubernetes deployable in containers https://review.openstack.org/466675
14:39:38 <apuimedo> #info We're also getting the tempest plugin soon
14:39:48 <apuimedo> It should be merged this week
14:40:32 <janonymous> Please have a look at https://review.openstack.org/#/c/454555/ patch also in free time :)
14:41:02 <apuimedo> janonymous: yes. We should get that by pike-3
14:41:17 <apuimedo> I would like to run it a few days before I'm comfortable with it
14:41:26 <janonymous> apuimedo: cool, thanks!
14:41:36 <janonymous> apuimedo: agree
14:41:50 <apuimedo> Hopefully I'll get machines to test the SR-IOV kzaitsev is working on
14:42:06 <apuimedo> Anything else on kuryr-k8s
14:43:09 <apuimedo> alright. Moving on
14:43:20 <apuimedo> #topic general
14:43:27 <ltomasbo> apuimedo, irenab: https://review.openstack.org/#/c/474576/
14:43:29 <apuimedo> Any other topic to close today's meeting?
14:43:34 <ltomasbo> take a look when you have time ^^
14:43:41 <irenab> apuimedo: fuxi?
14:43:43 <apuimedo> Next week we'll maybe skip due to business travel
14:43:53 <janonymous> Any updates on ptg?
14:43:53 <apuimedo> irenab: darn. I checked if hongbin was present
14:43:56 <apuimedo> and didn't see him
14:43:57 <hongbin> hi
14:43:59 <apuimedo> Le'ts to fuxi
14:44:02 <apuimedo> #topic fuxi
14:44:25 <hongbin> last week, i believe zengchen is working on several patches on fuxi-k8s
14:44:33 <hongbin> zengchen: want to give a brief update?
14:44:41 <zengchen> ok
14:45:01 <zengchen> I am working on flex-volume driver.
14:45:18 <zengchen> i believe i will finish cinder-driver this week
14:45:25 <apuimedo> zengchen: Hi! Didn't notice you were here too :-)
14:45:54 <zengchen> i am seeing you are taling about kuryr
14:46:06 <zengchen> s/taling/talking
14:46:09 <apuimedo> :-)
14:46:20 <apuimedo> any updates on fuxi-golang?
14:46:36 <hongbin> apuimedo: i believe the first task is for you to setup the core team: https://review.openstack.org/#/admin/groups/1784,members
14:46:48 <zengchen> i am afraid i don't hava enough time.
14:47:03 <zengchen> maybe next week i will start on it
14:47:04 <apuimedo> hongbin: good point
14:47:17 <apuimedo> #action apuimedo to set up fuxi-golang core team
14:47:22 <apuimedo> #link https://review.openstack.org/#/admin/groups/1784,members
14:47:33 <hongbin> zengchen: thanks zengchen , apuimedo i have nothing else from my side
14:47:39 <apuimedo> very well
14:47:51 <apuimedo> zengchen: anything else from your side?
14:48:15 <zengchen> maybe we should invite more guys from cinder/manila to contribute on fuxi-go
14:49:29 <apuimedo> zengchen: agreed. Let's try to reach out
14:49:35 <apuimedo> #topic general
14:49:42 <apuimedo> Anything else?
14:49:53 <apuimedo> #action apuimedo to look at https://review.openstack.org/#/c/474576/
14:50:08 <janonymous> Any updates on ptg?
14:50:28 <apuimedo> VTG
14:50:50 <janonymous> :D
14:50:57 <apuimedo> that's the only update
14:51:00 <apuimedo> I don't have a date
14:51:15 <apuimedo> but I'll send some email about it in a week or two
14:52:44 <apuimedo> Thanks all for joining
14:52:47 <apuimedo> #endmeeting