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