22:00:03 <mlavalle> #startmeeting neutron_drivers
22:00:05 <openstack> Meeting started Thu Nov 30 22:00:03 2017 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:08 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:55 <mlavalle> hi there!
22:01:04 <haleyb> hi
22:01:05 <boden> howdy
22:01:08 <oanson> Hi
22:01:41 <mlavalle> armax: ping
22:02:34 <mlavalle> amotoki: ping
22:02:36 <armax> hi
22:04:02 <mlavalle> let's wait one or two minutes for ihrachys and / or amotoki
22:04:32 <ihrachys> o/
22:04:45 <ihrachys> sorry folks :)
22:04:51 <ihrachys> was too excited reading some code
22:05:37 <mlavalle> ihrachys: that's good :-) welcome
22:06:03 <mlavalle> list of RFEs to discuss today are here: https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:06:36 <mlavalle> last time we discussed https://bugs.launchpad.net/neutron/+bug/1705755
22:06:36 <openstack> Launchpad bug 1705755 in neutron "[RFE] Plugin support for API resource attribute extensions" [Wishlist,Triaged]
22:07:01 <mlavalle> and boden asked to join the meeting, so let's start there
22:07:50 <mlavalle> boden: you want to start
22:08:17 <boden> I read through the logs from last weeks driver’s meeting, and I wasn’t really sure the problem was understood.. so earlier this week I tried to simplify the description in the bug report
22:08:49 <boden> anyone have a chance to pre-parse?
22:09:55 <armax> I have briefly
22:10:00 <mlavalle> I did
22:10:17 <ihrachys> just did
22:10:27 <boden> from last weeks driver’s meeting, I didn’t really understand how neutron-lib came into the picture TBH
22:10:28 <armax> boden: this is a problem that prevents something like https://review.openstack.org/#/c/516701/ from landing at the moment, no?
22:11:21 <ihrachys> boden, neutron-lib is related in as much as it is a source of 'official' neutron apis that we can vouch/ask SDK/OSC folks to support.
22:11:23 <boden> armax: appears that way
22:11:53 <amotoki> hi sorry for late
22:11:55 <armax> to me the clear example of bypassing this hurdle is to elevate extension attributes to 1st level resources
22:12:27 <armax> and make extension attributes just read-only for resources that they are related to
22:12:38 <armax> unfortunately this is not an approach that would work on existing APIs
22:12:51 <armax> but new APIs should be designed with that principle in mind
22:13:41 <armax> if I bring the trunk API as an example, integrating it with OSC didn’t require any extra support from OSC or the OSC SDK
22:14:25 <armax> if I understand boden’s problem the issue stems solely from extension attributes to core resources whose OSC support is directly in the OSC repos
22:14:25 <ihrachys> ok. let's say you add data_plane_status to a port. you won't have a separate resource will you?
22:14:52 <boden> armax: I beleive you understand correctly
22:15:27 <armax> ihrachys: you could, it just looks clunky
22:15:35 <armax> boden: ack, thanks
22:16:24 <ihrachys> armax, but afaiu you can't specify an attribute value for an unknown attribute in OSC
22:16:29 <ihrachys> you can in neutronclient though
22:16:47 <armax> yeah
22:17:02 <armax> but that’s because the client just pass that along to the server
22:17:09 <ihrachys> right. but it works.
22:17:11 <armax> while OSC drops unknown attributes right?
22:17:14 <ihrachys> yea
22:17:15 <armax> sure, sure.
22:17:28 <amotoki> OSC only processes known options
22:18:15 <ihrachys> so what OSC folks tell us is they are not flexible in terms of how we implement our api when they need to then support it. Mike specifically mentions micro-versions in the gerrit link posted above
22:18:21 <ihrachys> here: https://review.openstack.org/#/c/516701/
22:18:51 <ihrachys> well, he makes an argument that dns should be in core.
22:19:02 <armax> so I think for that one, where my review is due, we should unblock it to grant it some sort of exception to the rule
22:19:30 <armax> as for other extension attributes, like vendor ones that may be unknown to us to, we clearly need to come up with a solution
22:20:28 <armax> if there was a way to enable OSC to be able to parse something like --extension-attr key=value —extension-attr key=value
22:20:36 <armax> that might solve the jam
22:20:40 <armax> not sure if it was discussed
22:20:54 <mlavalle> no haven't discussed that here
22:20:54 <ihrachys> for vendor attributes, I think we should gather answers to Akihiro's question: "What will vendor API extensions want to do then [when support for unofficial extensions is killed]?"
22:21:44 <armax> it’s never gonna get killed, let’s be realistic, IMO
22:21:46 <ihrachys> armax, it would unblock but not ideal. you have no indication of support in help text, or docs...
22:22:02 <ihrachys> armax, I dunno, I never saw a list of actual things external to stadium
22:22:16 <ihrachys> could be it's not big / can be upstreamed
22:23:09 <boden> armax: I’m not sure just the ability to pass extera kwargs is enough.. perhaps it’s part of the solution, but there’s still no way to extend existing OSC commands (like sec group create)
22:23:40 <armax> boden: to do what?
22:24:02 <armax> to quote your example
22:24:08 <armax> neutron security-group-create --logging=blah
22:24:25 <boden> armax: see #b2 and #b3 from the rfe
22:24:29 <armax> one could do osc security group create —extension-attr logging=blah
22:25:00 <boden> you still need the sec group command to do its thing, you just want to add some logic atop it
22:25:31 <mlavalle> it's similar to what we have with neutron client
22:25:34 <amotoki> in this case, we need an extra hook point to convert --extension-attr key=value to a propose data type and populate it into a req body
22:25:40 <armax> that logic would just involve to passthrough the extra argument, but the more talk about this the more I don’t like it
22:26:07 <armax> and I am sure the OSC team wouldn’t like it either
22:26:28 <amotoki> openstacksdk team either
22:26:49 <mlavalle> no, they won't like it
22:28:07 <ihrachys> maybe if they have even worse (in their mind) alternatives, they can bend
22:28:16 <mlavalle> lol
22:28:46 <armax> I think there’s no alternative on the table
22:30:17 <armax> the problem affects the core resources alone, right?
22:30:32 <armax> we should probably spell it out in capital cases on the bug description
22:30:55 <armax> no?
22:31:17 <amotoki> what do you mean by 'core resources'? (network, subnet, port only?)
22:31:24 <ihrachys> btw do OSC folks realize that they already support non-core APIs? I read maybe no from what Mike wrote: " In the OSC experience, I just want the feature set to be supported. I would like to first see neutron supporting this in their core api first."
22:31:29 <armax> core resources == resources whose OSC support is in the OSC repos
22:32:12 <amotoki> As far as I can tell, OSC team considers API defined in neutorn-lib as official networking API
22:32:23 <armax> ihrachys: I think the confusion stems from the fact that non-core APIs OSC plugin contributions never get seen by the OSC teams
22:32:44 <ihrachys> ok. but then dns is there too, so why the patch abandoned?
22:32:56 <armax> like bgpvpn, trunk, dynamicrouting, etc
22:33:11 <armax> ihrachys: at the PTG we talked about it
22:33:20 <armax> and said that DNS is likely gonna get an exception
22:33:24 <armax> to the rule
22:35:56 <armax> if we kept the neutronclient for these usecases, how would the user experience look like?
22:36:14 <mlavalle> meaning forever?
22:36:26 <armax> how could that change to keep a good demarcation from the experience of using the OSC?
22:38:08 <mlavalle> but is the longer term, isn't this also related, as amotoki points out in the RFE, to the future of extensions in openstack in general?
22:39:26 <mlavalle> if we are going to move away from extensions at some point in time, maybe the plan for this issue is to maintain neutron client up to that point
22:39:30 <mlavalle> no?
22:39:57 <boden> wouldn’t a “unified” networking API take into considerations of extensions as well? or we’re just saying too bad for them and all the users they bring
22:40:22 <armax> I can’t see us ever moving away from extensions, but that’s my opinion
22:40:24 <mlavalle> I know I am not saying that
22:41:47 <mlavalle> boden: in the short term you are happy if we maintain neutron client, right?
22:41:55 <boden> mlavalle: yes
22:42:02 <boden> but also need those extra kwargs it supports
22:42:11 <boden> so we can’t drop support for those
22:42:26 <mlavalle> understood
22:42:27 <armax> I think there was never a threat to pull the rug from neutronclient without a completed transition strategy to OSC
22:42:28 <amotoki> "unified" and "free to extend" are different in my opinion. If we allow to extend API freely, it is not a "unified" API. it is just an "unified" API endpoint
22:43:40 <boden> amotoki: yes.. unified I was thinking is a single API, but I was saying the construction of building that API, its resources, what it supports, etc. would consider extensions
22:43:46 <mlavalle> sso why don't we decide today that we are not going to remove neutron client until we find a plan / solution to the extensions / unified api coonundrum
22:43:58 <mlavalle> ?
22:44:08 <ihrachys> right. you can bring even more users if you expose (I assume) useful api to everyone, and with guarantees of cross-compatibility
22:44:28 <armax> mlavalle: we never have decided to remove and we are not going to remove the client
22:44:45 <mlavalle> boden: does that help?
22:44:48 <armax> if we can’t reply on the OSC CLI to address extension attributes
22:44:59 <mlavalle> rely^^^
22:45:07 <armax> mlavalle: thanks
22:45:10 <boden> mlavalle: yes, sounds like a fun longer term topic
22:45:25 <armax> then the path forward is to envision how the neutronclient experience can change
22:45:43 <armax> to embrace the use case of addressing the need of passing attribute extensions
22:45:52 <armax> or extension attributes, I shall say
22:46:52 <mlavalle> so I think we have a short term decision, keeping support for neutronclient with the extra kwargs
22:47:19 <mlavalle> and then we have a longer term decision that involves the future of extensions and a unified API
22:47:30 <armax> but the decision was already made when we kept the deprecation of the client open ended
22:47:41 <armax> the short term decision that is
22:48:14 <mlavalle> mhhhh, but I think that part of boden's concern is the deprecation message that users get
22:48:17 <mlavalle> right?
22:48:21 <armax> the longer term decision is also sorta made IMO
22:48:31 <boden> mlavalle, I think we are OK with it for now
22:48:34 <armax> mlavalle: correct, and my suggestion at the time was not to drop the message but rephrase it
22:49:19 <boden> whatever works :)  as long as the client’s supported
22:49:22 <armax> if we think about this RFE as ‘how the neutronclient can change to address the extension use case'
22:49:29 <armax> then I could ensivision a use case where
22:50:26 <armax> the neutronclient is stripped down bare bone and only capable of accepting requests that involve extension attributes
22:50:53 <armax> and we could even rename it to be openstack-net-ext
22:51:30 <armax> to signal that the neutron client itself is gone
22:51:39 <armax> crazy thought, I know
22:51:45 <armax> just tossing it out there
22:52:03 <mlavalle> ok, we would need to flesh this out
22:52:16 <mlavalle> in the meantime, we have a path forward
22:52:24 <armax> at least with this demarcation is clear which tool is for what
22:52:37 <mlavalle> do we all agree?
22:52:47 <amotoki> in that case, it might be better to have more structure extra argument support though
22:52:47 <armax> and if a user attempts to use openstack-net-ext to create a resource without extension, the client would barf at the user
22:53:03 <boden> mlavalle: +1
22:53:17 <armax> the drawback to this is that we’ll have to maintain parts of the neutronclient indefinitely when we had hoped we were going to get rid of it
22:53:39 <armax> but the maintainance cost has been pretty minimal in a while
22:53:45 <armax> ameade: totally
22:53:49 <armax> amotoki: totally
22:53:53 <armax> ameade: sorry
22:54:53 <mlavalle> ok, let's move on then
22:55:01 <amotoki> note that one big problem on attribute extension by vender extension is we cannot avoid name conflicts. if someone adds an extension in the neutron official API which has the same name as an attribute by vendor ext, there is no way to address it.
22:55:39 <amotoki> this is just a note.
22:55:47 <armax> amotoki: yup
22:55:47 <mlavalle> noted, thanks
22:56:02 <armax> namespacing is an issue with OSC too
22:56:42 <amotoki> yes. at now OSC is testing namespaces by loading all osc plugins... it is a bit hacky
22:57:34 <mlavalle> ok, we are left with only 3 minutes. so probable we won't be able to go through the next RFE
22:57:50 <mlavalle> let's return a whopping 3 minutes to our agendas
22:57:57 <mlavalle> thanks for attending
22:58:08 <ihrachys> o/
22:58:18 <mlavalle> remember that next time our meeting is on Friday at 1400utc
22:58:35 <mlavalle> #endmeeting