22:00:52 <armax> #startmeeting neutron_drivers
22:00:53 <openstack> Meeting started Thu Jan 12 22:00:52 2017 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:57 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:01 <ihrachys_> o/
22:01:01 <njohnston> o/
22:01:13 <armax> hello
22:01:15 <haleyb> hi
22:01:16 <armax> everyone
22:01:29 <boden> howdy
22:01:30 <armax> I almost forgot what it means to run a neutron drivers meeting
22:01:30 * dasm goes into spectator mode
22:02:32 <armax> kevinbenton, amotoki ping
22:02:40 <amotoki> hi
22:02:43 <armax> hello!
22:05:18 * ihrachys_ checked connectivity just in case
22:05:24 <armax> no it’s me
22:05:34 <armax> I am being distracted
22:05:35 <armax> sorry
22:06:22 <armax> I have a relatively lax agenda
22:06:30 <armax> first I wanted to touch base on outstanding specs
22:07:31 <armax> #link https://review.openstack.org/#/c/203509/
22:08:25 <ihrachys> armax: what's DOA?
22:08:44 <armax> iptables-based security-groups with OVS
22:09:09 <armax> it’s a huge debt
22:09:33 <ihrachys> oh you mean we should encourage to work on ovs firewall for ovs case
22:09:38 <armax> yeah
22:09:46 <ihrachys> good, I read it as if you suggested it's ovs firewall that is DOA
22:09:47 <ihrachys> :)
22:10:01 <armax> I have not seen the code and I would expect that they logger should work irrespective of LB vs OVS
22:10:36 <armax> but I personally don’t think we should even expose this on OVS if they are targeting iptables
22:11:10 <armax> it could potentially give us yet another migration issue later on
22:12:44 <amotoki> your concern is that the implementation can be tightly coupled with iptables. right?
22:13:09 <armax> amotoki: yes
22:14:08 <amotoki> reasonable concern.
22:15:06 <armax> so I think this one has to spin again
22:15:12 <ihrachys> armax: so, reading your comments, you expect that driver will report back if the extension is not supported by it. which opens a question of what to do in multi driver setup. (we had similar problem in qos, and I don't think we actually tackled it)
22:16:39 <armax> ihrachys: that’s a good point
22:16:59 <armax> I suppose we can have a security group serving VMs connected via different ML2 drivers
22:17:03 <armax> and it’s a mess
22:17:09 <armax> is it not?
22:17:31 <armax> so this means that the information being collected is potentially partial?
22:17:48 <ihrachys> yeah
22:18:05 <armax> this is a can of worms ready to blow up into everyone’s face
22:18:11 <armax> which is a bit gross
22:18:42 <ihrachys> I actually think from API standpoint, we should try to avoid asking backends for permission. just allow the operation and allow drivers to fail delivering. but I am open for an elegant way to do it in a smarter way.
22:18:51 <armax> I wonder if this spec is ever gonna get implemented
22:19:29 <armax> amuller was actually advocating for the opposite
22:19:53 <ihrachys> yeah I know
22:20:01 <ihrachys> he is not supposed to maintain the code anymore
22:20:14 <armax> ah
22:20:31 <armax> ok
22:20:37 <armax> bottom line there are still open questions
22:20:39 <armax> on this one
22:20:50 <armax> I don’t think the spec as is is ready to merge
22:21:01 <armax> as for
22:21:02 <armax> #link https://review.openstack.org/#/c/373029
22:21:09 <armax> I sent it to spec heaven
22:21:26 <ihrachys> amen, it totally makes sense. not sure why we even needed a spec.
22:21:32 <armax> ihrachys: agreed
22:21:42 <armax> then there was
22:21:44 <armax> #link v
22:21:48 <armax> #undo
22:21:49 <openstack> Removing item from minutes: #link v
22:21:50 <armax> #link https://review.openstack.org/#/c/320439/
22:22:03 <armax> I haven’t had a pass at it, yet
22:22:15 <armax> but I’ll do after this meeting
22:22:35 <armax> the work for both these specs will most certainly spill over Pike
22:23:12 <armax> then there was
22:23:13 <ihrachys> I will read through the spec for flow management tomorrow. I hope it's ok to wait till then.
22:23:14 <armax> #link https://review.openstack.org/#/c/351675/
22:23:23 <armax> it had a +2 from kevin at one point
22:23:28 <armax> that one is also on my radar
22:23:44 <armax> of the list of open specs I don’t think there’s anything else we can squash
22:23:48 <armax> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
22:23:57 <armax> you folks spot anything I am missing?
22:24:12 <ihrachys> re port status one, I have my reservations on it. I still believe we try to solve a particular configuration while we already provide all the bits to cover the use case.
22:24:34 <armax> ihrachys: elaborate, pls
22:25:08 <ihrachys> armax: two points. first, it seems like we use neutron as a mere storage/proxy for signaling between other components.
22:25:27 <ihrachys> which could be avoided if those components talk to each other
22:25:46 <armax> ihrachys: it’s neutron as a fancy datastore
22:25:55 <ihrachys> second, we already have tags for such use cases, where external consumers want to attach info to resources
22:26:16 <ihrachys> armax: it's neutron as a fancy datastore, and another extension on our plate. I prefer not if possible.
22:26:17 <armax> ihrachys: tags introduce potential incompatibility
22:26:33 <armax> it was brought up during the spec review
22:26:40 <armax> as for the fancy datastare comment
22:26:43 <armax> I agree with you
22:26:47 <ihrachys> armax: I bet there will be a request two cycles down the line to expand possible values for the status field. ask me then about compatibility.
22:27:20 <armax> the datastore gives you the port UUID mapping though
22:27:32 <armax> I mean the status is associated to the life cycle of the port
22:27:37 <ihrachys> what was the exact problem with tags btw? I could have missed that one.
22:27:55 <armax> first off, we have no tags for ports
22:27:58 <armax> but that’s a technicality
22:28:29 <armax> but second of all, it’s like one system may say ‘status = DEAD’ another may say ‘state = DOWN’
22:28:31 <armax> and boom
22:29:00 <armax> with tags there’s no way of defining which one is correct unless you define an ontology
22:29:33 <ihrachys> so you say that neutron is a fancy data store AND schema validator
22:29:45 <armax> ihrachys: ah
22:30:09 <armax> ihrachys: I suppose that’s one to characterize the whole thing
22:30:18 <ihrachys> I choose vitrage handling that complexity instead of us, any day
22:30:47 <njohnston> +1
22:31:29 <ihrachys> the schema (validation) is itself fluid I believe, and will eventually require expansion. I don't want to get there.
22:31:46 <ihrachys> as I said in the review, I am not too negative to put -1, I am just sayin'
22:32:18 <armax> ihrachys: I am also not strongly opinionated on this one
22:32:35 <armax> ihrachys: the extra attribute on the port resource is the low-hanging fruit so to speak
22:32:44 <armax> but it’s not free either
22:33:18 <armax> ihrachys: if nothing else, it’s informational
22:33:26 <armax> and that does not hurt
22:34:06 <armax> if there’s a system around neutron that says ‘hey, this port’s data plane is indeed busted’, anyone consuming the neutron API is gonna see that
22:34:52 <amotoki> it is a tradeoff. who validates a value and who provides information. if neutron provides an attr like this, external systems assumes it. if not, who can define a common interface?
22:34:56 <ihrachys> armax: they could as easily use API of that other system to get the info.
22:35:07 <armax> ihrachys: is it though?
22:35:18 <armax> neutron’s API is kick ass :)
22:35:45 <armax> the other system needs to be in sync
22:35:54 <ihrachys> armax: you mean, have I actually checked vitrage to see if it's exposed there? no I didn't. that was more of a theoretical suggestion.
22:35:59 <armax> and it may need to go back to neutron anyway
22:36:23 <armax> I admit my ignorance in saying that I never looked at vitrage
22:36:39 <ihrachys> now we are two
22:37:32 <ihrachys> my point is, they build something very specific for very specific use case, and so it's not required to give them complete solution, building blocks should be enough.
22:37:55 <armax> they you mean who?
22:38:01 <ihrachys> anyhoo, I think we spent too much time on that. if there are resources and support from other members, let's do it.
22:38:15 <ihrachys> armax: they == vitrage
22:38:22 <ihrachys> or whoever drives that
22:38:36 <ihrachys> error detectors/orchestrators
22:39:00 <armax> ok
22:39:32 <armax> I think this one, as much as odd as it can be it’s many order of magnitudes less controversial than the security-logging API
22:39:49 <armax> not that the comparison can help anything
22:40:05 <armax> the other one I have on my radar is
22:40:07 <armax> #link https://review.openstack.org/#/c/309416/
22:40:17 <armax> we need to close this one by end of Ocata
22:40:21 <ihrachys> yes
22:40:24 <armax> hopefully
22:40:29 <ihrachys> that one is almost ready from my perspective
22:40:34 <armax> cool
22:40:49 <ihrachys> there are some small nits that may even not be worth a fix (can be left for implementation)
22:40:57 <armax> I have been meaning to go back and review it
22:41:05 <armax> for a while
22:41:24 <armax> any other spec worth talking about now?
22:42:05 * armax waits a tad longer
22:42:42 <armax> ok
22:42:49 <armax> it looks like we’re good spec-wise for this week
22:43:05 <armax> in terms of RFEs
22:43:18 <armax> we have a long list of confirmed RFEs
22:43:29 <armax> and a few others
22:44:01 <armax> we need to squash these lists
22:44:12 <armax> but we can never do in the 15 minutes left here
22:46:02 <armax> shall we call this short and take the time to go over the RFE lists offline?
22:46:16 <ihrachys> yes
22:46:20 <armax> ok then
22:46:26 <amotoki> yes
22:46:29 <armax> anything else from anyone else?
22:46:43 <njohnston> Nope
22:46:49 <armax> OK!
22:46:57 <armax> have a great rest of your day everyone
22:47:00 <armax> #endmeeting