22:02:36 <kevinbenton> #startmeeting neutron_drivers
22:02:38 <openstack> Meeting started Thu Apr 20 22:02:36 2017 UTC and is due to finish in 60 minutes.  The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:41 <openstack> The meeting name has been set to 'neutron_drivers'
22:03:25 <trevormc> o/
22:03:28 <armax> hi
22:03:46 <haleyb> hi
22:03:55 <kevinbenton> let's cruise through some RFE's
22:03:59 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:04:42 * armax jumps on the boat
22:05:07 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1558812
22:05:09 <openstack> Launchpad bug 1558812 in neutron "[RFE] Enable adoption of an existing subnet into a subnetpool" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
22:05:39 <kevinbenton> this one has been discussed before and Carl gave a nice outline of what needs to be done
22:05:49 <mlavalle> yep, really nice
22:06:15 <armax> I thought that was approved at some point
22:06:28 <mlavalle> and there is a patchset that was started by tidwellr
22:06:38 <armax> yeah
22:06:39 <kevinbenton> armax: looks like it went from approved to postponed
22:06:47 <armax> well the implementation is hairy
22:06:58 <armax> and it stalled in making it robust enough to races etc
22:07:08 <kevinbenton> was the issue locking?
22:07:21 <armax> I don’t recall, but Ryan struggled for a while
22:07:39 <armax> since we lost both carl and ryan in the process this stalled
22:07:57 <kevinbenton> the revision plugin may now offer us more guarantees with protection from races now
22:08:12 <kevinbenton> since all subnet updates increment the network revision as part of their update
22:09:59 <kevinbenton> i'm okay with approving this and re-examining the implementaiton
22:10:19 <armax> I am thinking if we want to take a step back
22:10:45 <armax> and look at all RFEs on the radar and try to stab at giving priorities
22:10:58 <mlavalle> yeap, I was about to propose the same
22:11:04 <armax> and then assess only those we feel like are higher priority for us
22:11:25 <mlavalle> with all the causalties lately, we need to look at the big picture
22:11:29 <armax> as much as I still believe that priorities are hard to estimate
22:11:32 <mlavalle> and regroup
22:11:35 <armax> mlavalle: exactly
22:11:38 <armax> I was ognna say
22:11:39 <ihrachys> right. we need to understand what's the state for things like port bindings and such.
22:11:51 <armax> the landscape changed drastically in just a few months
22:12:00 <mlavalle> just in this week
22:12:20 <armax> we can’t just let folks work on what they fancy
22:12:32 <armax> as much as it’s useful
22:12:32 <kevinbenton> well we can
22:12:37 <armax> we have stuff that’s standing incomple
22:12:40 <armax> incomplete
22:12:48 <kevinbenton> and they won't necessarily work on what we fancy is the issue
22:12:51 <armax> and that hurts more than something that’s not even started
22:13:15 <armax> kevinbenton: I understand
22:13:42 <armax> we can force people to work on stuff we want them to work
22:14:03 <mlavalle> can't^^^ I think
22:14:08 <armax> what I am saying is that out of the lot of open RFEs
22:15:13 <armax> rather than treating them at the same priority, we should perhaps look at those that are more critical
22:16:04 <kevinbenton> isn't that what the priority field is for on blueprints?
22:16:19 <armax> at this point these are not blueprints yet though
22:16:33 <kevinbenton> i like to think of RFEs as sanity checks to see if we can allow them in the platform
22:16:41 <armax> ok
22:16:42 <kevinbenton> setting to rfe-approved doesn't mean we need to land them all
22:16:47 <armax> sure
22:16:55 <armax> but we approved this one already
22:17:04 <armax> so it already makes sense
22:17:18 <kevinbenton> ok, then we should get rid of rfe-postponed tag probably
22:17:25 <armax> no
22:17:33 <kevinbenton> and just track that with blueprint status
22:17:35 <armax> if we have an owner it shoudl go straight back to approved
22:17:44 <armax> there’s no point in going back to rfe
22:17:51 <armax> the discussion has already happened
22:18:17 <kevinbenton> then why did we spend 5 minutes talking about approving it?
22:18:22 <kevinbenton> :)
22:18:31 <armax> not this one
22:19:31 <armax> never mind, carry on
22:19:32 <kevinbenton> so what would you like to spend the meeting doing?
22:19:40 <kevinbenton> we can prioritize blueprings
22:19:44 <kevinbenton> blueprints
22:20:03 <kevinbenton> #link https://blueprints.launchpad.net/neutron
22:20:15 <kevinbenton> #link https://blueprints.launchpad.net/neutron/+spec/adopt-oslo-versioned-objects-for-db
22:20:15 <armax> that’s fine, let’s go back to RFEs
22:20:47 <kevinbenton> so this one got hit pretty hard by cut back of intel/rackspace
22:21:43 <kevinbenton> ihrachys: how many people do we have left working on OVO?
22:21:49 <ihrachys> 1.5
22:22:01 <ihrachys> me and manjeet (I am .5 if you ask)
22:22:01 <kevinbenton> ack
22:22:07 <ihrachys> but that I am going to close. but I will fall back on some other upgrade related things.
22:22:16 <ihrachys> like the api extensions convergence
22:22:25 <ihrachys> I am going to postpone/defer/abandon that one
22:22:32 <mlavalle> wasn't manjeets hit by the OSIC debacle?
22:22:44 <ihrachys> mlavalle, he is one of those lucky who are not OSIC
22:22:47 <ihrachys> but ODL
22:22:50 <kevinbenton> electrocucuracha has this handy spreadsheet he sent me https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8/edit#gid=1434170112
22:22:51 <ihrachys> so he stays (for now)
22:22:54 <mlavalle> ahhh nice!
22:24:03 <kevinbenton> ihrachys: is it possible for you to write-up an email highlighting what patches need volunteers to take over?
22:24:09 <kevinbenton> ihrachys: and send it to the list
22:24:12 <ihrachys> ok ok
22:25:14 <kevinbenton> #link https://blueprints.launchpad.net/neutron/+spec/neutron-lib-networking-l2gw
22:25:24 <kevinbenton> armax: that is still in progress, right?
22:25:37 <ihrachys> the link doesn't reflect the title
22:25:43 <armax> let me fix tht
22:26:02 <armax> I am heavily behind
22:26:07 <armax> but I still intend to work on it
22:26:09 <armax> if time lets me
22:26:24 <kevinbenton> do you think high priority status is necessary?
22:26:30 <armax> kevinbenton: btw we should bump the milestones
22:26:35 <armax> we’re in p-2 right?
22:26:47 <kevinbenton> this isn't blocking anything other than stopping neutron imports
22:27:07 <kevinbenton> armax: you broke that link above
22:27:11 <armax> I did
22:27:12 <kevinbenton> armax: share us the new one please
22:27:19 <armax> https://blueprints.launchpad.net/neutron/+spec/neutron-lib-dynr
22:28:37 <kevinbenton> armax: so what do you think about lowering the priority of this one since it's not operator/user visible
22:29:51 <kevinbenton> ok
22:29:54 <kevinbenton> leaving it for now
22:29:55 <armax> fine by me
22:30:00 <kevinbenton> this one is the worrying one now
22:30:02 <kevinbenton> #link https://blueprints.launchpad.net/neutron/+spec/live-migration-portbinding
22:30:13 <armax> the sense of urgency came from the idea of accelerating the adoption of neutron-lib
22:30:18 <armax> but that’s not going to happen
22:30:22 <kevinbenton> i think we need to higher the priority of this portbinding work
22:30:36 <kevinbenton> because it's actually going to address multiple things
22:30:45 <ihrachys> ++
22:30:46 <kevinbenton> migrations between vif types IIUC requires this
22:30:59 <mlavalle> and Anindita was affected by the OSIC stuuf
22:31:04 <kevinbenton> and we need migrations between vif types to switch between mech drivers (as part of an upgrade)
22:31:13 <ihrachys> and also firewalls afaik
22:31:15 <kevinbenton> or as part of a switch between technologies (e.g. ref impl to OVN)
22:31:25 <kevinbenton> (iptables -> ovs native)
22:31:28 <kevinbenton> ihrachys: ++
22:32:20 <ihrachys> I totally agree that should get High, but we need to understand if nova still thinks the same about it.
22:32:34 <kevinbenton> johnthetubaguy: you awake?
22:32:40 <armax> probably not
22:33:02 <armax> we should ask ijw if he has resources he can spare
22:33:05 <armax> to work on this
22:33:14 <armax> he has a stake in this
22:33:41 <kevinbenton> +1, he was adamant at the PTG that all was needed was approval of the work
22:33:42 <ihrachys> armax, we may also have someone for the cause
22:34:15 <armax> woot
22:34:22 <ihrachys> but not nova side :)
22:34:29 <ihrachys> (at least I am not aware of anyone yet)
22:35:46 <kevinbenton> i would like to put the priority of this one at medium
22:35:46 <kevinbenton> https://blueprints.launchpad.net/neutron/+spec/instance-ingress-bw-limit
22:35:49 <ihrachys> kevinbenton, I think Anindita is with us till end of next week, so it may make sense to dump her brain on the matter before she potentially leaves us
22:36:04 <kevinbenton> ihrachys: ack
22:36:19 <kevinbenton> ihrachys: i will reach out to her
22:36:39 <armax> kevinbenton: two priorities to chose from
22:36:41 <armax> low and higj
22:36:46 <armax> high
22:36:50 <kevinbenton> i see more
22:36:54 <kevinbenton> i will use more!
22:36:56 <ihrachys> for that qos one, we have a patch I believe
22:37:00 <kevinbenton> ihrachys: right
22:37:06 <kevinbenton> ihrachys: i've looked at it a couple of times
22:37:09 <ihrachys> https://review.openstack.org/#/c/449831/
22:37:13 <ihrachys> yeah, it's pretty good
22:37:15 <ihrachys> I did too
22:37:16 <armax> kevinbenton: it’s pointless to use more than two
22:37:33 <kevinbenton> armax: well pretend all of them are low that aren't high
22:37:36 <kevinbenton> armax: problem solved
22:37:48 <ihrachys> it doesn't implement backend though I believe
22:37:56 <armax> (facepalm)
22:38:12 <ihrachys> oh there is another one for ovs bits https://review.openstack.org/#/c/457816/
22:39:33 <kevinbenton> i've heard multiple requests for this qos one, so it would be good if we can land it
22:39:36 <ihrachys> re prio, I am fine with High but will review nevertheless
22:39:50 <kevinbenton> MEDIUM
22:40:18 <mlavalle> que qos guys have a bi-weekly meeting, which I've been attending lately
22:40:28 <mlavalle> next one is this coming Tuesday
22:40:36 <mlavalle> I can communicate to them
22:40:43 <mlavalle> this bump in priority
22:40:57 <armax> I am moving them back to LOW :)
22:41:13 <kevinbenton> mlavalle: looks like they are moving along pretty well already, but yeah tell them we are targeting PIke for sure
22:41:17 <kevinbenton> #link https://blueprints.launchpad.net/neutron/+spec/port-data-plane-status
22:41:22 <kevinbenton> IIRC this merged
22:41:27 <mlavalle> yes, it is done
22:41:44 <ihrachys> docs/tests/all good?
22:41:53 <kevinbenton> hmm, not sure about docs
22:41:59 <kevinbenton> i think tests and whatnot were part of it
22:42:07 <ihrachys> api-ref?
22:42:13 <mlavalle> api ref was merged
22:42:20 <ihrachys> yeah I see it
22:42:27 <mlavalle> in neutron lib before the neutron side
22:42:27 <armax> as this is assigned to me as approved
22:42:29 <ihrachys> then I guess can be closed
22:42:29 <armax> approver
22:42:35 <armax> I should know the answer to these questions
22:42:44 <armax> I’ll find out and provide an update on teh whiteboard
22:42:46 <kevinbenton> armax: ok, i'll let you go through and identify the gaps
22:42:46 <mlavalle> the only missing piece is docs
22:43:30 <kevinbenton> #link https://blueprints.launchpad.net/neutron/+spec/native-l2pop
22:43:37 <kevinbenton> this may need a priority bump
22:44:00 <armax> is the assignee still around?
22:44:01 <kevinbenton> i'm still working out the issues, but trying to trigger l2pop functionality inside of push notiifcations is becoming really hacky and burdensome
22:44:14 <kevinbenton> ihrachys: we still have venkata right?
22:44:18 <kevinbenton> or is he OVN?
22:44:18 <ihrachys> kevinbenton, ofc
22:44:25 <ihrachys> I think he is mostly with us
22:44:43 <ihrachys> but I can check
22:44:46 <kevinbenton> ack
22:44:53 <armax> I’ll like you to expand on teh hackiness but offline
22:45:26 <kevinbenton> well the issue is l2pop does things based on a magical hidden state machine of (STATUS, host_id) tuples
22:45:44 <armax> OFFLINE!
22:45:58 <kevinbenton> so if you fail to perform the correct incantations, the doors to connectivity fail to open
22:46:01 <kevinbenton> ok :)
22:46:26 <kevinbenton> everything else on that list is fine with me for priority
22:46:38 <kevinbenton> #link https://blueprints.launchpad.net/neutron/+spec/fetch-hostkey-from-port
22:46:50 <kevinbenton> that belongs to an RFE mlavalle and i discussed last week a bit
22:47:11 <kevinbenton> monty has even volunteered to help work it
22:47:14 <mlavalle> modred showed up yesterday in the Neutron channel
22:47:32 <mlavalle> thinking the meeting was yesterday
22:47:37 <armax> not sure what that means
22:47:41 <ihrachys> do we have anything written beyond this one sentence description?
22:47:44 <armax> is there more documented somewhere?
22:47:45 <kevinbenton> ihrachys: yeah
22:47:46 <kevinbenton> rfe
22:47:47 <kevinbenton> one sec
22:47:58 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1682247
22:48:00 <openstack> Launchpad bug 1682247 in neutron "Neutron should be able to fetch hostkeys for ports" [Wishlist,Triaged]
22:48:15 <clarkb> tl;dr is give users of booted instances a secure ish way to get the hostkey so that you don't have to blindly trust on first boot
22:48:18 <kevinbenton> which has a link to an even more detailed spec
22:48:21 <mlavalle> yeah, he submitted the spec before the rfe
22:48:56 <armax> I am not sure I appreciate why that service must be neutron
22:49:13 <armax> I’ll look at https://review.openstack.org/#/c/456394/
22:49:24 <kevinbenton> it requires a network probing of some sort
22:49:33 <kevinbenton> here is the digital ocean RFE :) https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/9307569-return-the-droplet-s-ssh-public-key-as-part-of-api
22:50:41 <armax> kevinbenton: probing such as?
22:51:06 <kevinbenton> armax: connecting to the instance on a TCP port to retrieve the ssh key
22:51:17 <ihrachys> so something from inside neutron (that would guarantee correct endpoint) fetch ssh fingers and expose via api?
22:51:26 <kevinbenton> ihrachys: yep
22:51:37 <kevinbenton> ssh-keyscan as a service
22:51:42 <kevinbenton> SKaaS
22:51:48 <mlavalle> lol
22:51:52 <armax> kevinbenton: this makes no sense
22:52:05 <armax> at least at first glance
22:52:26 <kevinbenton> armax: i want an API to retrieve the ssh key of a server
22:52:27 <armax> you poke a TCP port and an ssh key is handed over to you?
22:52:34 <kevinbenton> armax: yes, this is how ssh works
22:52:40 <armax> but then why neutron?
22:52:47 <armax> this might as well be nova
22:52:49 <ihrachys> armax, I am not sure you can safely do that from outside neutron (or nova) perimeter.
22:52:52 <kevinbenton> armax: neutron is the thing with access to the network
22:53:01 <kevinbenton> armax: nova does not have access
22:53:03 <armax> the service runs in a vm
22:53:18 <ihrachys> unless it doesn't
22:53:20 <kevinbenton> armax: what service?
22:53:26 <kevinbenton> the scanning thing?
22:53:27 <armax> assh
22:53:29 <armax> ssh
22:53:42 <armax> that’s ok, I’ll look at the spec
22:53:49 <armax> no need to digress here
22:54:05 <kevinbenton> I, as a user, want to know the SSH hostkey of a new instance so I don't have to trust the first thing i get when i connect
22:54:44 <armax> I understand, all I am wondering at this point is whether this logic actually resides in neutron or not
22:54:58 <armax> I can have many ports connected to a VM
22:55:13 <armax> wouldn’t I get the same key for if two ports were connected to the same VM?
22:55:31 <kevinbenton> most of the time, yes
22:55:34 <ihrachys> I suspect it's configurable
22:55:45 <kevinbenton> i'm sure you could configure sshd to listen differently on different ports
22:56:06 <armax> dunno if I ever saw that in practice
22:56:11 <armax> sounds like a nightmare
22:56:31 <ihrachys> quoting someone from stackoverflow "You can actually change where the SSH server looks for the key in the /etc/ssh/sshd_config file with the HostKey /path/to/host/key setting."
22:56:33 <armax> anyway I am surprised we bypassed the RFE process altogether and give this blueprint for granted
22:56:45 <kevinbenton> we didn't
22:56:48 <kevinbenton> pay attention!
22:56:51 <armax> I see no RFE bug
22:56:59 <armax> linked here
22:57:00 <armax> https://blueprints.launchpad.net/neutron/+spec/fetch-hostkey-from-port
22:57:11 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1682247
22:57:12 <openstack> Launchpad bug 1682247 in neutron "Neutron should be able to fetch hostkeys for ports" [Wishlist,Triaged]
22:57:13 <mlavalle> armax: that is because modred didn't know about the RFE process
22:57:21 <mlavalle> so he submitted the spec first
22:57:26 <armax> I see
22:57:38 <mlavalle> in fact, he wants to attend the meeting next week
22:57:53 <mlavalle> he couldn't make it today (he thought it was yesterday)
22:58:03 <mlavalle> and discuss the rfe
22:58:12 <kevinbenton> well that will give everyone time to read the RFE and think about it
22:58:18 <armax> sounds good
22:58:38 <kevinbenton> a project could potentially live outside of neutron an leverage the neutron interface drivers to attach to tenant networks with admin privileges
22:59:13 <ihrachys> kevinbenton, or os-vif? :)
22:59:44 <kevinbenton> ihrachys: yeah, if they are willing to accept use cases that aren't VMs
23:00:16 <ihrachys> time
23:00:18 <kevinbenton> ihrachys: early on i had suggested in a review to address agent-style plugging and they weren't interested
23:00:19 <kevinbenton> ack
23:00:27 <kevinbenton> #endmeeting