14:28:24 <mlavalle> #startmeeting neutron_drivers 14:28:25 <openstack> Meeting started Fri Dec 8 14:28:24 2017 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:28:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:28:28 <openstack> The meeting name has been set to 'neutron_drivers' 14:28:59 <mlavalle> This is the list of triaged bugs we have for today 14:29:07 <mlavalle> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe 14:29:37 <mlavalle> first one is https://bugs.launchpad.net/neutron/+bug/1531103 14:29:38 <openstack> Launchpad bug 1531103 in neutron "can update the gateway of ipv6 subnet with ipv6 address which has a leading "0" via cli" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee) 14:30:20 <mlavalle> I read it last night and pretty much am in agreement with amotoki 14:30:54 <amotoki> I have one thing to discuss on this. what value should be returned as API response. 14:31:03 <amotoki> *? 14:31:21 <yamamoto> i'd say always normalized one 14:31:28 <mlavalle> meaning when the user specifies 2::0001? 14:31:36 <amotoki> yes 14:31:52 <mlavalle> I also think the normalized one 14:32:08 <mlavalle> how could that be backwards incompatible? 14:32:25 <amotoki> previously we return a string specified in a request 14:32:43 <amotoki> if 2::0001 is specified 2::0001 is returned 14:33:21 <mlavalle> is your concern that we might be breaking scripts that return un-normalized responses? 14:33:39 <amotoki> yes, if some API user checks he gets a value he specified in a req, it breaks his script 14:33:51 <amotoki> but it might be really a corner case 14:34:09 <amotoki> perhaps we made similar small fixes in API 14:34:23 <amotoki> so i think it is okay to normalize a response into 2::1 14:35:32 <amotoki> if we agree it should be normalized, I think it is no longer a RFE. it is a normal bug i think. 14:35:39 <mlavalle> amotoki, yamamoto: approve? 14:36:14 <amotoki> mlavalle: okay to me 14:36:23 <yamamoto> fine for me 14:37:52 <mlavalle> yeah, scripts that normalize on their own are most likely to be able to handle the case when they get a response already normalized 14:39:00 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1543756 14:39:01 <openstack> Launchpad bug 1543756 in neutron "[RFE] RBAC: Allow user to create port from specific subnet on shared network" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee) 14:40:01 <amotoki> looking at the restored patch https://review.openstack.org/#/c/432850/, it looks like a topic on the default policy. 14:41:29 <mlavalle> yes, the only concern I have is what kevinbenton expressed in #1 14:42:49 <amotoki> agree, especially on the second paragraph whether we should allow to specify subnet_id 14:42:54 <mlavalle> so maybe we want to relax the policy to allow the selection of the subnet, but not specific fixed ip 14:43:55 <amotoki> I don't see any other problem on relaxing the policy on subnet_id so far 14:44:05 <mlavalle> me neither 14:44:18 <mlavalle> let's see what yamamoto thinks 14:45:08 <yamamoto> thinking 14:45:16 <mlavalle> take your time 14:45:18 <mlavalle> no rush 14:45:45 <mlavalle> thinking is what we are expected to do 14:47:04 <yamamoto> today a user can create many ports until he gets one with the subnet he wanted? 14:48:42 <amotoki> he can, but it needs some luck 14:48:49 <mlavalle> yeah 14:49:10 <mlavalle> what would be the implication? 14:49:44 <yamamoto> i'm just trying to remember the current allocation logic 14:50:33 <yamamoto> i think it's safe to allow to specify subnet_id. 14:50:46 <amotoki> IIRC if we have two IPv4 subnets, neutron tries to allocate a random IP address from one subnet 14:51:01 <mlavalle> ok, amotoki, yamamoto I think we all agree on this one 14:51:21 <mlavalle> I will leave a note to that effect in the RFE at the end of the meeting 14:51:49 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1705467 14:51:50 <openstack> Launchpad bug 1705467 in neutron "[RFE] project ID is not verified when creating neutron resources" [Wishlist,Triaged] 14:53:44 <mlavalle> we suggested to check typos in the client, last time we discussed this 14:54:08 <mlavalle> would it mean to check from the client the project exists? 14:54:34 <amotoki> in OSC implementation '--project' option always queries keystone, so I think it does not happen with OSC (plugin) 14:54:46 <mlavalle> or check that the string provided is a UUID? 14:55:05 <mlavalle> so that leave only neutron client 14:55:07 <mlavalle> right? 14:55:34 <amotoki> i think so. 14:55:49 <amotoki> the server side already check a passed string is UUID too 14:57:26 <mlavalle> is auto allocated topology supported in OSC? 14:57:29 <amotoki> hmmm... auto-allocated-topology in OSC is an exception. it has no check..... 14:57:30 <yamamoto> which server are you talking about? 14:58:05 <amotoki> yamamoto: API impl on the neutron server 14:58:39 <mlavalle> so that explains this RFE, maybe 14:58:50 <mlavalle> OSC doesn't support his use case either 14:59:04 <amotoki> I think auto-allocated-topology in OSC should be considered as a bug 14:59:16 <mlavalle> and fix there 14:59:24 <amotoki> yes 14:59:37 <mlavalle> ok, maybe next step is propose that in the RFE 14:59:47 <mlavalle> and see if we can move it forward 14:59:52 <mlavalle> thoughts? 14:59:56 <amotoki> +1 15:00:02 * mlavalle looking at the clock 15:00:27 <mlavalle> ok team time is up 15:00:32 <mlavalle> #endmeeting