14:02:24 <mlavalle> #startmeeting neutron_drivers
14:02:24 <openstack> Meeting started Fri Feb 15 14:02:24 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:27 <openstack> The meeting name has been set to 'neutron_drivers'
14:02:33 <mlavalle> Hi there
14:02:59 <slaweq> hi
14:03:02 <amotoki> hi
14:03:17 <mlavalle> let's wait a minute
14:05:08 <haleyb> hi
14:05:59 <mlavalle> ok, let's get going
14:06:04 <mlavalle> #topic RFEs
14:06:46 <mlavalle> First up is https://bugs.launchpad.net/neutron/+bug/1815361
14:06:47 <openstack> Launchpad bug 1815361 in neutron "[RFE] Add support for binding activate and deactivate in sriov mechanism driver" [Wishlist,In progress] - Assigned to Adrian Chiris (adrian.chiris)
14:09:05 <slaweq> I'm not an sriov expert but for me this one looks reasonable and pretty easy - no API changes, no DB changes, only backend implementation
14:09:23 <mlavalle> yes, I also think it makes perfect sense
14:09:36 <amotoki> yeah, i think so.
14:09:48 <mlavalle> when I implemented multiple port binding, I didn't do this one because I didn't have a way to test it
14:10:22 <amotoki> that's fair enough
14:10:28 <mlavalle> Adrian (submitter) works for Mellanox in Israel. I met him personally in Berlin. So he has all he needs to test it
14:11:14 <amotoki> I am not sure whether we really need to bump RPC version but it can be discussed in a review. otherwise it sounds reasonable and is limited to a driver.
14:11:55 <mlavalle> yeap
14:12:00 <mlavalle> so my vote is +1
14:12:05 <slaweq> amotoki: yes, that is IMO implementation detail to discuss during review
14:12:09 <slaweq> +1 from me :)
14:12:11 <amotoki> me too
14:12:12 <haleyb> +1
14:12:29 * mlavalle documenting approval
14:14:19 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1815827
14:14:20 <openstack> Launchpad bug 1815827 in neutron "[RFE] neutron-lib: rehome neutron.object.base along with rbac db/objects" [Wishlist,New]
14:16:00 <mlavalle> and submitter, boden, just joined us
14:16:07 <boden> howdy
14:16:59 <mlavalle> boden: the pace in this meeting is a bit slower than in the weekly meeting. We give time to drivers to read and ponder
14:17:16 <mlavalle> and then ask
14:17:18 <boden> no worries... got coffee and code here to keep me busy
14:19:11 <slaweq> for me it looks completly reasonable - neutron ovo objects are used in many stadium/3rd party projects so it should be moved to neutron-lib IMO
14:19:31 <slaweq> but this will be probably same long process as rehoming db api and extensions, right?
14:19:56 <boden> to me the main thing we haven't agreed upon before is the rehoming of the RBAC DB stuff... we have previously agreed to most of the other stuff like object API, etc.
14:20:18 <boden> slaweq yes it will likely take awhile... mostly due to the velocity of code reviews
14:20:35 <amotoki> generally speaking, it sounds reasonable, but looking at the referred review https://review.openstack.org/#/c/621000/, we see several extensions (as slaweq mentioned)
14:21:12 <mlavalle> and what is your concern about RBAC?
14:21:21 <boden> amotoki yes pulled in via dependencies unfortunately
14:21:51 <amotoki> most of such extensions are now fundamentals of neutron behavior, so I am okay if we can agree.
14:22:15 <boden> mlavalle I have no concern per say.. I just dont want to spend a bunch of time rehoming only to find out folks don't think it makes sense... if people think from a high level this is reasonable we can disucuss details on the actual code reviews once I get them rolling
14:22:51 <mlavalle> I do think it makes sense at high level and think we can discuss details in the corresponding reviews
14:23:06 <boden> works for me, that's all I needed
14:23:36 <mlavalle> so are the other members of the team ok moving ahead with this
14:23:42 <mlavalle> I say +1
14:23:44 <amotoki> what I am not sure is which plugin(s) does not work with RBAC. we sometimes concern plugin supports but it is hard to catch up (if their maintainers do not join the discussion).
14:23:48 <amotoki> I say +1 too
14:24:09 <slaweq> +1
14:24:25 <haleyb> +1, more in neutron-lib the better
14:24:58 <mlavalle> boden: go ahead. I am going to dcument this agreement in the RFE to make it official
14:25:09 * mlavalle documenting approval
14:25:09 <boden> great thank you all for the time/consideration
14:25:25 <slaweq> thanks boden to taking care of it :)
14:26:58 <mlavalle> boden: don't think it is like this all the time. Sometimes we have looooong discussions. This was easy becuase we have previous agreements in the general direction ;-)
14:27:45 <mlavalle> Next one up for discussion today is https://bugs.launchpad.net/neutron/+bug/1815933
14:27:45 <openstack> Launchpad bug 1815933 in neutron "[RFE] Allow bulk-tagging of resources" [Wishlist,New]
14:29:50 <slaweq> this one was reported by dulek from kuryr team but I guess someone else will have to take care of it if it will be accepted
14:30:29 <amotoki> it looks like a request of tagging support when creating a port.
14:30:41 <mlavalle> we are already implementing bulk port creation
14:30:55 <slaweq> mlavalle: but You can't set tag while creating port
14:31:05 <slaweq> so You create ports in bulk
14:31:13 <mlavalle> which is also a request that came from the kuryr world
14:31:14 <amotoki> slaweq is correct.
14:31:16 <slaweq> and then have to iterate over them to set same tag on each
14:31:19 <mlavalle> slaweq: agree with you
14:31:25 <amotoki> we cannot set tags when creating a port.
14:31:29 <amotoki> The current tagging API comes from the nova implementation and API-SIG guidance (from nova API)
14:31:39 <mlavalle> agree with you all
14:31:49 <amotoki> it is not ideal. IMHO we should allow to specify tags when creating a resource.
14:32:06 <mlavalle> all I'm trying to say is that it seems to me to be a logical follow up
14:32:46 <slaweq> mlavalle: yep, that is how it looks for me too :)
14:33:35 <mlavalle> it doesn't make sense to create the ports in bulk and then get stuck with their tagging
14:34:05 <slaweq> amotoki: so IIUC what You said we have to have such tagging api because nova API has it done this way, right?
14:34:22 <haleyb> i thought you could set a tag when creating a port, at least the cli shows it
14:34:23 <amotoki> slaweq: yes
14:34:26 <amotoki> this request is reasonable. my suggestion is to support 'tags' attribute in POST operation. I can also propose a discussion to API-SIG if we go to this route.
14:35:03 <slaweq> haleyb: You can't, https://github.com/openstack/neutron/blob/master/neutron/extensions/tagging.py#L41
14:35:51 <haleyb> slaweq: hmm, then the api doc is wrong, https://developer.openstack.org/api-ref/network/v2/?expanded=create-port-forwarding-detail,create-port-detail#ports
14:35:56 <haleyb> that shows tags in POST
14:35:57 <slaweq> amotoki: I'm all for that - this should be changed IMO
14:36:07 <amotoki> slaweq: totally agree
14:36:18 <amotoki> this API-SIG document on tag API https://specs.openstack.org/openstack/api-wg/guidelines/tags.html
14:36:27 <slaweq> haleyb: yes, I think that dulek even told me that when we talked about this
14:37:21 <haleyb> then i guess we should fix it :)
14:37:54 <slaweq> haleyb: agree
14:38:51 <slaweq> amotoki: so there is described only way to create many tags for one resource, IMO this should be discussed in API-SIG to allow setting tags during creation of resources and/or set tags in bulk
14:39:28 <mlavalle> amotoki: so this guideline doesn't seem to support the proposal in  the RFE
14:39:37 <mlavalle> at least at first glance
14:39:46 <mlavalle> or am I mis-reading?
14:39:46 <amotoki> mlavalle: yes, it does not now.
14:40:17 <amotoki> IMHO we should allow to specify tags when creating a resource in the guideline.
14:40:46 <mlavalle> yeah, probably that guideline doesn't consier use cases like containers
14:40:54 <amotoki> mlavalle: yes
14:41:29 <amotoki> slaweq: IMO at least tags should be specified when creating a resource. I am not sure we need bulk update of tags.
14:42:11 <mlavalle> slaweq: based on what you know, is dulek planning to work on this implementation? or is he asking the Neutron team to implement it?
14:42:43 <slaweq> mlavalle: he will probably not work on this
14:42:56 <mlavalle> ok so we need a champion
14:43:01 <mlavalle> for this
14:43:02 <slaweq> but I think I can raise it on our internal meetings
14:43:13 <amotoki> the RFE submitter requests bulk tagging, so we need to check the submitter whether tagging support in bulk create works or not.
14:43:30 <slaweq> amotoki: give me a sec, maybe dulek can join
14:44:12 <slaweq> I pinged him on openstack-pl channel, maybe he will join
14:44:39 <mlavalle> for the time being we need to assume, it is up to us, right?
14:45:32 <mlavalle> slaweq: is that a Poland specific channel?
14:45:37 <amotoki> mlavalle: i think so
14:45:39 <slaweq> yes
14:45:48 <mlavalle> cool
14:45:55 <amotoki> my comment is about "up to us"
14:46:13 <slaweq> my "yes" was about Poland channel :P
14:46:26 <slaweq> but I also agree that it's "up to us" :)
14:46:38 <mlavalle> so the first step would be to have a conversation with API-SIG
14:46:49 <mlavalle> right?
14:46:50 <slaweq> +1
14:47:09 <slaweq> this proposal looks like much wider than only Neutron
14:47:17 <mlavalle> I agree
14:47:38 <amotoki> yeah, I can take care of the discussion. do we start a ML discussion?
14:48:05 <mlavalle> amotoki: yes, let's do that. we can point to the RFE in the initial message
14:48:31 <amotoki> okay, I will send a mail this weekend
14:48:33 <mlavalle> as an example of use cases that require a broadening of the community's approach to tagging
14:48:50 <mlavalle> I think they meet on Thursdays
14:48:59 <mlavalle> at a time unfriendly to you amotoki
14:49:22 <mlavalle> so if we need to discuss in their meeting, I can attend
14:49:33 <mlavalle> but let's start in the ML
14:49:37 <amotoki> mlavalle: do you mean API-SIG meeting?
14:49:51 <slaweq> they have office hours: http://eavesdrop.openstack.org/#API_Special_Interest_Group_office_hours
14:50:29 <amotoki> thanks for the info.
14:50:50 <amotoki> anyway ML and #-sdks channel work for us :)
14:51:19 <mlavalle> yeah I attended a meeting on Thursday at 1600 when we were discussing the topic of API filtering
14:51:34 <mlavalle> let's start in the ML, amotoki
14:51:41 <mlavalle> as you proposed
14:51:45 <amotoki> sure
14:51:51 <slaweq> +1
14:52:23 <mlavalle> I'll leave a note in the RFE, pointing to the guidelines ^^^^^ and indicating what the next step is
14:53:11 <mlavalle> ok, moving on
14:53:19 <mlavalle> #topic On demand agenda
14:54:04 <mlavalle> slaweq: you proposed to discuss https://review.openstack.org/#/c/571899/
14:54:23 <slaweq> mlavalle: it was long time ago
14:54:37 <slaweq> and I think we already talked about it few months back
14:54:44 <mlavalle> ah ok, I'll clean up the agenda
14:54:45 <slaweq> sorry that I forgot to remove it
14:54:52 <mlavalle> I'll take care of it
14:54:55 <slaweq> thx
14:54:56 <mlavalle> np
14:55:05 <mlavalle> ok guys, that's it
14:55:10 <mlavalle> thanks for attending
14:55:22 <mlavalle> have a great weekend
14:55:31 <mlavalle> #endmeeting