14:02:24 #startmeeting neutron_drivers 14:02:24 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:27 The meeting name has been set to 'neutron_drivers' 14:02:33 Hi there 14:02:59 hi 14:03:02 hi 14:03:17 let's wait a minute 14:05:08 hi 14:05:59 ok, let's get going 14:06:04 #topic RFEs 14:06:46 First up is https://bugs.launchpad.net/neutron/+bug/1815361 14:06:47 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 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 yes, I also think it makes perfect sense 14:09:36 yeah, i think so. 14:09:48 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 that's fair enough 14:10:28 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 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 yeap 14:12:00 so my vote is +1 14:12:05 amotoki: yes, that is IMO implementation detail to discuss during review 14:12:09 +1 from me :) 14:12:11 me too 14:12:12 +1 14:12:29 * mlavalle documenting approval 14:14:19 Next one is https://bugs.launchpad.net/neutron/+bug/1815827 14:14:20 Launchpad bug 1815827 in neutron "[RFE] neutron-lib: rehome neutron.object.base along with rbac db/objects" [Wishlist,New] 14:16:00 and submitter, boden, just joined us 14:16:07 howdy 14:16:59 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 and then ask 14:17:18 no worries... got coffee and code here to keep me busy 14:19:11 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 but this will be probably same long process as rehoming db api and extensions, right? 14:19:56 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 slaweq yes it will likely take awhile... mostly due to the velocity of code reviews 14:20:35 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 and what is your concern about RBAC? 14:21:21 amotoki yes pulled in via dependencies unfortunately 14:21:51 most of such extensions are now fundamentals of neutron behavior, so I am okay if we can agree. 14:22:15 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 I do think it makes sense at high level and think we can discuss details in the corresponding reviews 14:23:06 works for me, that's all I needed 14:23:36 so are the other members of the team ok moving ahead with this 14:23:42 I say +1 14:23:44 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 I say +1 too 14:24:09 +1 14:24:25 +1, more in neutron-lib the better 14:24:58 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 great thank you all for the time/consideration 14:25:25 thanks boden to taking care of it :) 14:26:58 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 Next one up for discussion today is https://bugs.launchpad.net/neutron/+bug/1815933 14:27:45 Launchpad bug 1815933 in neutron "[RFE] Allow bulk-tagging of resources" [Wishlist,New] 14:29:50 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 it looks like a request of tagging support when creating a port. 14:30:41 we are already implementing bulk port creation 14:30:55 mlavalle: but You can't set tag while creating port 14:31:05 so You create ports in bulk 14:31:13 which is also a request that came from the kuryr world 14:31:14 slaweq is correct. 14:31:16 and then have to iterate over them to set same tag on each 14:31:19 slaweq: agree with you 14:31:25 we cannot set tags when creating a port. 14:31:29 The current tagging API comes from the nova implementation and API-SIG guidance (from nova API) 14:31:39 agree with you all 14:31:49 it is not ideal. IMHO we should allow to specify tags when creating a resource. 14:32:06 all I'm trying to say is that it seems to me to be a logical follow up 14:32:46 mlavalle: yep, that is how it looks for me too :) 14:33:35 it doesn't make sense to create the ports in bulk and then get stuck with their tagging 14:34:05 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 i thought you could set a tag when creating a port, at least the cli shows it 14:34:23 slaweq: yes 14:34:26 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 haleyb: You can't, https://github.com/openstack/neutron/blob/master/neutron/extensions/tagging.py#L41 14:35:51 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 that shows tags in POST 14:35:57 amotoki: I'm all for that - this should be changed IMO 14:36:07 slaweq: totally agree 14:36:18 this API-SIG document on tag API https://specs.openstack.org/openstack/api-wg/guidelines/tags.html 14:36:27 haleyb: yes, I think that dulek even told me that when we talked about this 14:37:21 then i guess we should fix it :) 14:37:54 haleyb: agree 14:38:51 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 amotoki: so this guideline doesn't seem to support the proposal in the RFE 14:39:37 at least at first glance 14:39:46 or am I mis-reading? 14:39:46 mlavalle: yes, it does not now. 14:40:17 IMHO we should allow to specify tags when creating a resource in the guideline. 14:40:46 yeah, probably that guideline doesn't consier use cases like containers 14:40:54 mlavalle: yes 14:41:29 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 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 mlavalle: he will probably not work on this 14:42:56 ok so we need a champion 14:43:01 for this 14:43:02 but I think I can raise it on our internal meetings 14:43:13 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 amotoki: give me a sec, maybe dulek can join 14:44:12 I pinged him on openstack-pl channel, maybe he will join 14:44:39 for the time being we need to assume, it is up to us, right? 14:45:32 slaweq: is that a Poland specific channel? 14:45:37 mlavalle: i think so 14:45:39 yes 14:45:48 cool 14:45:55 my comment is about "up to us" 14:46:13 my "yes" was about Poland channel :P 14:46:26 but I also agree that it's "up to us" :) 14:46:38 so the first step would be to have a conversation with API-SIG 14:46:49 right? 14:46:50 +1 14:47:09 this proposal looks like much wider than only Neutron 14:47:17 I agree 14:47:38 yeah, I can take care of the discussion. do we start a ML discussion? 14:48:05 amotoki: yes, let's do that. we can point to the RFE in the initial message 14:48:31 okay, I will send a mail this weekend 14:48:33 as an example of use cases that require a broadening of the community's approach to tagging 14:48:50 I think they meet on Thursdays 14:48:59 at a time unfriendly to you amotoki 14:49:22 so if we need to discuss in their meeting, I can attend 14:49:33 but let's start in the ML 14:49:37 mlavalle: do you mean API-SIG meeting? 14:49:51 they have office hours: http://eavesdrop.openstack.org/#API_Special_Interest_Group_office_hours 14:50:29 thanks for the info. 14:50:50 anyway ML and #-sdks channel work for us :) 14:51:19 yeah I attended a meeting on Thursday at 1600 when we were discussing the topic of API filtering 14:51:34 let's start in the ML, amotoki 14:51:41 as you proposed 14:51:45 sure 14:51:51 +1 14:52:23 I'll leave a note in the RFE, pointing to the guidelines ^^^^^ and indicating what the next step is 14:53:11 ok, moving on 14:53:19 #topic On demand agenda 14:54:04 slaweq: you proposed to discuss https://review.openstack.org/#/c/571899/ 14:54:23 mlavalle: it was long time ago 14:54:37 and I think we already talked about it few months back 14:54:44 ah ok, I'll clean up the agenda 14:54:45 sorry that I forgot to remove it 14:54:52 I'll take care of it 14:54:55 thx 14:54:56 np 14:55:05 ok guys, that's it 14:55:10 thanks for attending 14:55:22 have a great weekend 14:55:31 #endmeeting