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