14:00:28 <mlavalle> #startmeeting neutron_drivers
14:00:29 <openstack> Meeting started Fri Apr  6 14:00:28 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:32 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:12 <mlavalle> Hi!
14:04:45 <amotoki> hi
14:04:57 <mlavalle> hi amotoki
14:05:19 <mlavalle> let's give yamamoto a few minutes
14:05:36 <mlavalle> I know haleyb has a medical appointment today
14:05:46 <mlavalle> so he may not make it to the meeting
14:05:46 <yamamoto> hi
14:05:52 <yamamoto> sorry for being late
14:06:05 <mlavalle> np
14:06:22 <mlavalle> we have quorum today, so let's get going
14:07:03 <mlavalle> These are the triaged bugs we have today:
14:07:10 <mlavalle> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe-triaged
14:08:13 <mlavalle> First one is https://bugs.launchpad.net/neutron/+bug/1715386
14:08:14 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,In progress] - Assigned to zhaobo (zhaobo6)
14:09:01 <mlavalle> I see that the submitter uploaded a new revision of the spec: https://review.openstack.org/#/c/523658
14:09:40 <mlavalle> That was last week. I didn't have time to go over it. Did you have time to look at it?
14:10:03 <yamamoto> i haven't noticed the new rev. i need to read.
14:10:52 <amotoki> I haven't looked thru it yet. I need to refresh my memory on this.
14:11:02 <amotoki> how is it going in general?
14:11:17 <mlavalle> progress has been slow
14:11:25 <mlavalle> since Dublin
14:12:02 <mlavalle> I propose we take the homework of going through the latest revision of the spec and we discuss it next week
14:12:08 <mlavalle> does that work?
14:12:13 <amotoki> +1
14:12:54 <yamamoto> sounds good, except that i will be away next week :-)
14:13:16 <mlavalle> yamamoto: ah, yeah. going anywhere fun?
14:13:44 <yamamoto> midokura barcelona. i'm not sure it will be fun.
14:13:55 <mlavalle> yamamoto: if you have time before leaving for vacation, please leave your comments in the spec
14:14:19 <mlavalle> Barcelona can be enjoyable anyways, so try to have fun!
14:14:31 <amotoki> yamamoto: enjoy your trip and barcerona!
14:14:32 <yamamoto> it's unlikely but if i have time, sure
14:15:03 <amotoki> it might be mixed in business and vacation though :)
14:15:55 <mlavalle> and amotoki is an expert doing that. I understand he had a great time in Dublin, snowstorm notwithstanding
14:16:15 <amotoki> :)
14:16:28 <mlavalle> ok, let's move on
14:16:41 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1723026
14:16:42 <openstack> Launchpad bug 1723026 in neutron "[RFE]Support get device_ids from floatingips" [Wishlist,Confirmed] - Assigned to Hongbin Lu (hongbin.lu)
14:17:57 <amotoki> IIRC I need to comment yamamoto's suggestion, but I failed to have time to comment it
14:18:30 <mlavalle> Yeah, he proposed to have a new /ip_address resource
14:19:22 <mlavalle> on my employer side, the idea was shared with the team and was well received
14:19:57 <mlavalle> if yamamoto's suggestion is accepted by the community, we would be happy to go with it
14:20:15 <amotoki> yamamoto: in your idea of /ip_address resource, how is IP address overlapping handled?
14:20:49 <amotoki> is it scoped into a project?
14:21:21 <yamamoto> i don't know :-)
14:21:28 <mlavalle> LOL
14:21:35 <mlavalle> it probably should
14:22:25 <amotoki> I am wondering how we can handle this RFE and /ip_address resource idea, together or separately.
14:22:57 <amotoki> In my understanding, the idea of /ip_address is to allow users to query IP address detail regardless of fixed or floating IP, right?
14:23:10 <mlavalle> Right
14:23:41 <amotoki> thanks for the input.
14:24:00 <mlavalle> Maybe we can add as a comment to the RFE the discussion we had a couple of weeks ago (and also this week) and then let the submitter further develop it
14:24:13 <amotoki> yeah, I will comment it this week.
14:24:43 <amotoki> also we need to add some links to the meeting logs
14:25:09 <mlavalle> yeah, we probably need to flesh it out a little bit in the RFE
14:25:19 <hongbin_> I also feel that the idea of /ip-address has a much broader scope of the original RFE, handle it separately might be better
14:25:40 <amotoki> hongbin_: tend to agree with you.
14:26:26 <mlavalle> hongbin_: would you help us flesh it out in a separte RFE?
14:26:54 <hongbin_> mlavalle: yes, I can try
14:27:43 <mlavalle> hongbin_: great! my concern wasn't as much the RFEs itself. it was rather how to give continuity to the idea.
14:27:59 <mlavalle> The other point then is, what do we do with the current RFE?
14:28:26 <mlavalle> do we close it and point to the new one?
14:28:39 <hongbin_> one option is to follow amotoki's idea to add port detailed information to the floating ip resource with an API extension
14:28:40 <mlavalle> close it after amotoki's comments maybe?
14:29:27 <mlavalle> hongbin_: yeah, that is an option too
14:29:27 <amotoki> mlavalle: does 'close' mean 'approved' or 'superseded by others'?
14:29:56 <mlavalle> amotoki: when I wrote my comment, I was thinking "superseded'
14:30:05 <amotoki> my understanding is that this RFE would like to provide more information on associated port.
14:30:23 <mlavalle> but maybe, as hongbin_ suggested, not necessarily. we can follow your comment in #18
14:30:25 <amotoki> so it sounds reasonable to provide more information
14:31:00 <hongbin_> yes, we have two RFEs, one RFE is for adding information to /floatingip resource, the other RFE is for introducing the /ip-address endpoint
14:31:08 <amotoki> it allows us to do like "openstack floating ip show <IP>" to get port detail
14:31:43 <mlavalle> yeah that makes sense
14:33:04 <mlavalle> so maybe we approve this one and let hongbin_ propose the new one
14:33:08 <mlavalle> would that work?
14:33:19 <amotoki> works for me.
14:33:23 <hongbin_> +1
14:35:07 <amotoki> hongbin_: btw, do you mean 'resource' by 'endpoint'?
14:35:24 <mlavalle> yamamoto: what do you think?
14:35:34 <yamamoto> the sole purpose of this rfe is to save the number of api calls, right?
14:35:56 <hongbin_> amotoki: yes :)
14:36:17 <amotoki> yamamoto: that's my understanding.
14:36:44 <yamamoto> i wonder if there will be a trade off.
14:36:59 <amotoki> there are two point: (1) more detail on port for a specific IP address and (2) to provide an easy way to query resources by IP address
14:37:00 <yamamoto> i.e. returning more stuff might make the call slower
14:37:41 <hongbin_> yes, this is a good point
14:37:47 <mlavalle> but currently we return port data anyways
14:37:59 <amotoki> good point. i think it depends on how two resources are coupled tightly
14:38:05 <hongbin_> one option is to introduce a config to disable this behavior
14:38:51 <mlavalle> I think we are retrieving the port anyway. sending the device_id of the port in the response won't add much
14:38:52 <amotoki> it is potentially confusing if API behavior changes depending on a config
14:38:55 <yamamoto> mlavalle: which port data?
14:39:43 <hongbin_> amotoki: yes, agree with that
14:40:41 <amotoki> yamamoto: as an operator, when we look up FIP, we usually query a port associated with that FIP, so I think it is a reasonable compromise to include a port data in a FIP response.
14:42:01 <amotoki> we can discuss whether we will return extended attributes though as  it needs more db joined query.
14:42:08 <yamamoto> if it's common for the API user to query the port anyway, i have no problem with the rfe. (i don't know if it's so common)
14:43:05 <mlavalle> in this case, the specific interest of the RFE is to return the device_id, which is in the Port table
14:43:33 <mlavalle> so no extended attributes would be needed
14:43:39 <hongbin_> yes, the cost is possibly an addition 'join'
14:44:05 <amotoki> I agree device_id is most interesting field. in most cases, we would like to know which server is associated.
14:44:32 <mlavalle> exactly
14:44:48 <mlavalle> in the L3 code this is where we get the fip: https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L1047
14:46:21 <amotoki> yeah, if we go to this route, the next question would be whether _get_floatingip() should fetch a port or FIP.get_object() should do it.
14:46:42 * mlavalle digging in the code
14:48:20 <amotoki> in other words, it is in API layer only vs in the object layer, but it might be beyond the RFE scope.
14:48:49 <yamamoto> ideally we can make the rest api powerful enough to represent a join :-)
14:49:57 <hongbin_> we could have a query parameter called --extra-info, then neutron server can read this parameter and do a 'join' with the Port table
14:51:02 <mlavalle> I personally think it is not much extra overhead
14:51:47 <hongbin_> yes, possibly
14:51:52 <mlavalle> Looking at the FIP OVO code https://github.com/openstack/neutron/blob/master/neutron/objects/router.py#L232
14:52:24 <mlavalle> we already do enough joins there with port for this to make much of a difference
14:52:53 <mlavalle> case in point https://github.com/openstack/neutron/blob/master/neutron/objects/router.py#L282
14:53:42 <yamamoto> get_scoped_floating_ips is for l3 agent rpc, not for the rest api, right?
14:54:10 <mlavalle> yeah, you may be right
14:54:32 <amotoki> yes, it is for l3-agent, but the number of l3-agent calls tend to be more than the number of API calls.
14:55:03 <amotoki> so I don't think it introduces extra much cost
14:55:13 <mlavalle> yeah, me neither
14:55:28 <yamamoto> if you have l3 agents, it might be.
14:55:40 <mlavalle> especially if we limit this to just the attributes in the Port table
14:56:18 <amotoki> agree
14:56:37 <mlavalle> which addresses the needs of the current RFE
14:57:24 <mlavalle> I say +1 on the RFE
14:57:38 <amotoki> me too
14:57:42 <hongbin_> +1
14:57:44 <yamamoto> honestly, i can't say if the cost matters or not without having numbers.
14:58:07 <mlavalle> so let's move ahead with it
14:58:29 <mlavalle> scoping it to the attributes in the Port's table
14:58:59 <mlavalle> ok, cool
14:59:05 <mlavalle> we ran out of time
14:59:11 <mlavalle> great discussion
14:59:15 <amotoki> at least we can say FIP API (even with Port joined query) would less cost compared to network or port APIs
14:59:45 <mlavalle> the discussion is the point of this meeting
14:59:53 <amotoki> :)
14:59:56 <mlavalle> See you next week
15:00:07 <mlavalle> #endmeeting