22:05:05 <armax> #startmeeting neutron_drivers
22:05:07 <openstack> Meeting started Thu Jul 13 22:05:05 2017 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:05:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:05:11 <openstack> The meeting name has been set to 'neutron_drivers'
22:05:49 <armax> let’s go over the list of triaged RFEs
22:05:52 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:06:34 <armax> we discussed bug #1667877 last week
22:06:35 <openstack> bug 1667877 in neutron "[RFE] Allow DVR for E/W while leaving N/S centralized" [Wishlist,Triaged] https://launchpad.net/bugs/1667877
22:06:36 <armax> there’s a new comment
22:06:45 <armax> from Swami
22:07:29 <armax> replied
22:07:40 <armax> but irrc balls was in kevinbenton’s court
22:07:48 <armax> to go approve the RFE and sprinkle his magic
22:07:51 <armax> kevinbenton?
22:08:12 <armax> same for bug #1669630
22:08:13 <openstack> bug 1669630 in neutron "Network RBAC acceptance workflow" [Wishlist,Triaged] https://launchpad.net/bugs/1669630
22:08:21 <armax> but no action since last week
22:08:42 <armax> let’s look at a new one
22:08:43 <armax> bug 1672852
22:08:44 <openstack> bug 1672852 in neutron "[RFE] Make controllers with different list of supported API extensions to behave identically" [Wishlist,Triaged] https://launchpad.net/bugs/1672852
22:08:50 <kevinbenton> Slow!
22:08:52 <armax> dear to ihrachys…no longer
22:08:56 <armax> oh sorry
22:09:03 <armax> kevinbenton: you have the floor
22:09:28 * armax goes and buys a decent LTE plan for kevinbenton
22:09:45 <kevinbenton> Ok. Proceee
22:09:55 <ihrachys> d
22:09:58 <kevinbenton> I thought I needed to say something
22:10:15 <armax> oh boy
22:10:17 <ihrachys> yeah, it helps to show who's the boss
22:10:42 <kevinbenton> When you said ball was in my court
22:10:43 <armax> kevinbenton: OK
22:10:50 <armax> bug #1672852
22:10:51 <openstack> bug 1672852 in neutron "[RFE] Make controllers with different list of supported API extensions to behave identically" [Wishlist,Triaged] https://launchpad.net/bugs/1672852
22:10:52 <kevinbenton> I was reading spec to see what I needed to do
22:11:08 <ihrachys> this RFE, I suggest to scrap and get back to idea in 6 cycles or so
22:11:09 <armax> ihrachys’s suggestion is to make this ‘postponed'
22:11:45 <armax> ihrachys: yeah but what does this mean for the overall rolling upgrade strategy for neutron?
22:11:51 <armax> ihrachys: is that stalled as well?
22:11:56 <kevinbenton> +1 for defer
22:12:00 <ihrachys> it means that we will get there a tad later
22:12:17 <armax> this RFE is instrumental to make that happen without side-effects
22:12:26 <armax> drop the hyphen between side and effects
22:12:28 <ihrachys> no, we work on database layer and stuff; just api may behave a tad different during rolling upgrade; that can be mitigated by sticky lb and such
22:12:28 <armax> no?
22:12:58 <armax> OK
22:13:15 <armax> ihrachys: mind you perhaps make that recommendation and mark it rfe-postponed?
22:13:31 <ihrachys> ok
22:13:35 <armax> danke
22:13:38 <armax> next one
22:13:42 <armax> bug #1682247
22:13:43 <openstack> bug 1682247 in neutron "Neutron should be able to fetch hostkeys for ports" [Wishlist,Triaged] https://launchpad.net/bugs/1682247
22:14:10 <ihrachys> have we resolved the concern around why it's neutron and not nova?
22:14:14 <armax> I think we spec stalled, but I think there’s a good consensus that this stuff does make sense and we want to do that in neutron-land
22:14:16 <armax> mordred: ^
22:14:24 <armax> ihrachys: yes,
22:14:41 <armax> ihrachys: I think there were a number of comments on the initial draft for the spec
22:15:03 <ihrachys> is it about different finger per port?
22:15:15 <ihrachys> in multiport vm
22:15:19 <armax> and so long as we don’t make neutron bloat into a certificate authority this is enough of an enhancement that makes certain security attacks a thing of the past
22:15:31 <kevinbenton> I remember they were discussing in infra
22:15:49 <armax> ihrachys: it shouldn’t be IMO, but that’s a detail for the spec
22:15:56 <kevinbenton> And there was still question about whether there should be a more general way to get info to API
22:15:59 <mlavalle> did modred respond to your question, kevinbenton?
22:15:59 <kevinbenton> From instance
22:16:29 <kevinbenton> Not yet
22:17:02 <mlavalle> so I say let's hold on this one until we hear back from modred
22:17:15 <armax> so kevinbenton this one is to be approved, assumed we have mordred respinning the spec and potentially prototyping the neutron code?
22:17:22 <armax> mlavalle: ok
22:17:45 <armax> I guess we can agree the use case and the proposal makes sense
22:17:49 <armax> ?
22:17:52 <mlavalle> I do
22:17:55 <mordred> I think kevinbenton may have actually convinced me that thereis a viable alternative
22:18:06 <mordred> but I do still want to respin/update it
22:18:21 <armax> mordred: do share!
22:18:26 <mordred> I also owe a blog post/write up of the summary of the kevinbenton discussion
22:19:06 <armax> mordred: what alternative are you referring to, if you can summarize it in a few words
22:19:07 <armax> ?
22:19:07 <mordred> armax: it would take too long to do in irc - I'll write it up and post it and then ping you - it took us AGES to get all theway to the meat of th eissue
22:20:21 <mordred> hrm. I can _try_ real quick - tl;dr is that as long as you don't expose secrets over the connection, an initial key-based (and only key-based) connection can be foud to be safe...
22:20:23 <armax> mordred: OK, but was the alternative suggesting that this be done outside neutron?
22:20:40 <mordred> if you can verify content on the host that would also identify the host as being the correct host and not a mitm honeypot
22:21:12 <armax> mordred: I suppose that would potentially lead to a more convoluted user experience?
22:21:14 <mordred> with a config-drive attached to a vm, you could, with a single command that does not send secrets over the wire, verify that content you expect to be on the host is, in fact, on the host - and therefore that the host is not a honeypot
22:21:17 <mordred> yes
22:21:19 <armax> or at least with more steps involved?
22:21:25 <mordred> it's a thing you have to do precisely correctly
22:21:43 <mordred> BUT - it _is_ possible to do precisely correctly and have confidence
22:21:56 <mordred> so I still think we should have the other thing- bcause many cloud users would like help with stuff
22:22:14 <mordred> and the more help we can give them on topics where they're more than likely otherwise to get stuff wrong the better
22:22:16 <armax> I see
22:22:32 <mordred> but the spec needs a respin - sorry I haven't followed up with it
22:22:40 <armax> I suppose it’s an alternative, but probably not as viable :)
22:23:11 <armax> in the sense that is a lot more labor intensive in the number of steps required on the user to ascertain that the host is not indeed a bogus one
22:23:13 <armax> ?
22:23:58 <mordred> yah
22:24:16 <mordred> and there's a bunch of "this only works in these exact conditions"
22:24:16 <armax> I think this might be my initial though when thinking to have this done in nova itself, either way you could potentially capture this in the alternatives section in the spec
22:24:25 <mordred> ++
22:24:26 <mordred> will do
22:24:30 <armax> mordred: thansk
22:24:47 <mordred> in fact, honestly, I thnk having good and thorough documentation on the process that can be used wold be good
22:25:17 <armax> +
22:25:21 <armax> makes sense
22:25:44 <armax> mordred: OK, look forward to a new patchset! thanks a lot
22:26:01 <armax> if there’s nothing else on this subject
22:26:10 <armax> moving on to...
22:26:12 <armax> bug #1689830
22:26:13 <openstack> bug 1689830 in neutron "[RFE] advanced policy for allowed addres pairs" [Wishlist,Triaged] https://launchpad.net/bugs/1689830
22:28:07 <kevinbenton> So it seems like they want the allowed address pairs
22:28:11 <kevinbenton> But a subset
22:28:18 <kevinbenton> Safe to use on a shared network
22:28:41 <kevinbenton> IIUC
22:29:10 <armax> right now allowed address pairs is admin or network owner only
22:29:27 <armax> but there’s no validation on which  IP is put in the pair correct?
22:29:33 <kevinbenton> Yeah
22:29:44 <armax> anyone else happens to recall this important detail? :)
22:30:04 <kevinbenton> But that validation isn't really needed
22:30:51 <armax> so the proposal is about relaxing the constraint, ie. allowing anyone to create an AAP for a port on a shared network only if it matches a specifc IP on that network?
22:31:07 <kevinbenton> Yeah, that was my interpretation
22:31:19 <kevinbenton> Allow regular users on shared network
22:31:41 <kevinbenton> To use allowed address pair for address they own
22:32:17 <armax> from a policy engine standpoint the implementation may look hairy
22:32:20 <armax> no?
22:32:24 <kevinbenton> Yeah
22:32:42 <kevinbenton> Would require full get_ports call
22:32:47 <armax> can RBAC be of any help here?
22:33:01 <kevinbenton> I don't think so
22:33:12 <kevinbenton> It might be easier to add another attr
22:33:20 <kevinbenton> To port
22:33:38 <kevinbenton> That is validated differently but treated like an allowed address pair
22:33:53 <armax> if the policy were to be relaxed
22:35:04 <kevinbenton> The new attr would have the relaxed policy
22:35:10 <armax> allowing any regular user to handle allowed address pairs
22:35:18 <armax> what difference would it make?
22:35:41 <kevinbenton> New attr would only allow addresses of ports the userown
22:35:45 <kevinbenton> User owns
22:36:47 <mlavalle> right, he referes to already allocated ip addresses
22:36:50 <mlavalle> to the user
22:38:09 <armax> a new attribute would create some confusion though
22:38:59 <kevinbenton> Yeah
22:39:45 <armax> is this something that might be addressed using a different policy rule?
22:40:07 <armax> like if the account has a special service role?
22:40:20 <armax> like we did for some of the advanced services?
22:40:24 <kevinbenton> Yeah, but they are basically admitted
22:40:31 <kevinbenton> Admin on the network
22:40:43 <kevinbenton> They could use service role
22:40:48 <armax> right
22:40:51 <armax> that’s what I am thinking
22:40:59 <kevinbenton> But I got the impression the user was untrusted
22:41:27 <armax> probably we need more input about the use case
22:41:29 <kevinbenton> Maybe we need that clarified
22:41:31 <kevinbenton> Yeah
22:41:32 <mlavalle> yes
22:41:38 <armax> OK
22:41:46 <mlavalle> I don't think we have enough understanding of his use case
22:41:54 <armax> I’ll capture these notes and put in o the report
22:42:14 <armax> bug #1690921
22:42:15 <openstack> bug 1690921 in neutron "[RFE] Manage Broadcast, Unicast, and Multicast traffic" [Wishlist,Triaged] https://launchpad.net/bugs/1690921
22:43:05 <armax> I suppose this is one of those RFEs that is a slippery slope
22:43:08 <ihrachys> this seems to be a job for CCF integration with sg? I understand that's vaporware right now though.
22:43:57 <armax> ihrachys: don’t think so
22:44:20 <armax> the way I understand this is that the proposal is to have more fine grained control over packet filtering
22:44:54 <armax> I suppose traffic classification would be needed in the solution
22:44:54 <mlavalle> by adding more fiedls to security group rules
22:45:04 <ihrachys> is classifier all about fine grained?
22:45:48 <ihrachys> *isn't
22:46:13 <ihrachys> I mean this in case it's not clear: https://review.openstack.org/#/c/333993/
22:46:19 <kevinbenton> I think classifier might make sense though
22:46:31 <kevinbenton> Rather than bolt on more options to sg directly
22:46:56 <armax> ihrachys: right, I think a classifier would be needed in the solution, but the user facing API would still be security groups
22:47:04 <armax> at least in this RFE, no?
22:47:18 <ihrachys> that's what's proposed but I don't think we should go there
22:47:24 <kevinbenton> Well the API is the classifier
22:47:30 <ihrachys> CCF provides a api resource that you tangle to sg
22:47:56 <kevinbenton> So only change to sg is maybe reference to CCF
22:48:20 <mlavalle> why not suggest to the submitter to look at the CCF spec and provide feedback?
22:48:25 <ihrachys> yeah. problem is, there is no CCF api right now, and realistically, we can only hope for Q if not R
22:49:12 <armax> ihrachys: I’d be wary to use that as an argument though
22:49:38 <armax> to allow an RFE such as this to proceed
22:49:48 <armax> wouldn’t you agree?
22:49:54 <ihrachys> no I don't suggest that at all. I feel CCF is the way to go.
22:50:21 <mlavalle> so let's steer the submitter in that direction....
22:50:54 <armax> ihrachys: do you know that the CCF proposal is enough to allow the classification of the traffic as proposed by this RFE?
22:51:26 <ihrachys> would need to look at details but that shouldn't stop us if some small bit is missing
22:51:32 <ihrachys> we can extend
22:51:48 <ihrachys> I can dig and report to LP tomorrow with proper reply
22:51:59 <armax> ihrachys: ack
22:52:06 <armax> so shall we leave this to you?
22:52:19 <ihrachys> yea
22:52:27 <ihrachys> made a todo note
22:52:28 <armax> okey-dokey
22:52:44 <armax> bug #1690937
22:52:45 <openstack> bug 1690937 in neutron "[RFE] Support allowed address pairs without ip address" [Wishlist,Triaged] https://launchpad.net/bugs/1690937 - Assigned to Ruslan Gustomyasov (rusik)
22:53:19 <armax> btw can I make a general remark?
22:53:46 <ihrachys> sure
22:53:55 * ihrachys is prepared for a slap
22:53:58 <armax> RFEs are supposed to provide use cases, benefits to the use cases etc
22:53:59 <armax> not solutions
22:54:06 <armax> with no context whatsoever
22:54:14 <mlavalle> ++
22:54:27 <armax> this is the second if not the third RFE that is marked as triaged without comments
22:54:36 <armax> that tend to clarify what the proposal is for
22:54:54 <ihrachys> ack, my fault. :)
22:54:55 <armax> that I am seeing right now
22:55:08 <armax> ihrachys: I still love you
22:55:39 <mlavalle> Timecheck: we have 5 minutes left
22:55:52 <armax> mine is just a suggestion so that we can have more meat on the bone when we do come to talk about the RFE during this meeting
22:56:01 <mlavalle> we all love ihrachys
22:56:33 <ihrachys> this one totally slipped through cracks somehow, I feel embarrassed. don't we allow 0.0.0.0/0 already?
22:56:34 <armax> in this case, I am not sure I am able to parse this RFE
22:57:15 <armax> also this one
22:57:18 <armax> bug #1694165
22:57:19 <openstack> bug 1694165 in neutron "Improve Neutron documentation for simpler deployments" [Wishlist,Triaged] https://launchpad.net/bugs/1694165
22:57:21 <armax> why is it even an RFE?
22:57:53 <armax> I removed the RFE tag
22:58:25 <armax> OK, 3 mins left let’s ask on bug 1690937  more clarity
22:58:27 <openstack> bug 1690937 in neutron "[RFE] Support allowed address pairs without ip address" [Wishlist,Triaged] https://launchpad.net/bugs/1690937 - Assigned to Ruslan Gustomyasov (rusik)
22:58:33 <armax> for now I suppose we shall wrap up
22:58:42 <ihrachys> ok. you want me to ask?
22:58:49 <armax> ihrachys: yes, please
22:58:51 <ihrachys> ok
22:58:54 <armax> I’ll commetn as well
22:59:01 <armax> anything else before we close?
22:59:06 <armax> #chair kevinbenton
22:59:07 <openstack> Current chairs: armax kevinbenton
22:59:10 <armax> close the meeting
22:59:16 <armax> kevinbenton: ^
22:59:18 <armax> :)
22:59:27 <armax> show us you were paying attention
22:59:32 <kevinbenton> #endmeeting