12:00:05 <alex_xu> #startmeeting nova api
12:00:06 <openstack> Meeting started Tue Jan 12 12:00:05 2016 UTC and is due to finish in 60 minutes.  The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:09 <openstack> The meeting name has been set to 'nova_api'
12:00:16 <alex_xu> who is here today?
12:00:50 <oomichi> o/
12:01:05 <alex_xu> oomichi: hey :)
12:01:14 <alex_xu> oomichi: are you already move to US?
12:01:21 <oomichi> alex_xu: hi :)
12:01:27 <jichen> o/
12:01:36 <oomichi> alex_xu: not yet. it is 11th/Feb :)
12:02:09 <alex_xu> oomichi: cool! but sad, we lost one core in asia timezone :(
12:02:25 <oomichi> alex_xu: ah, nice point
12:02:28 <cdent> o/
12:02:32 <alex_xu> emm...super quiet in community in the recently
12:02:40 <alex_xu> but let start the meeting
12:02:46 <alex_xu> #topic content patches up for review
12:02:53 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/complete-todo-in-api-concept-doc,n,z
12:03:01 <cdent> alex_xu: I think that's just the nature of january
12:03:27 <alex_xu> we have some patch about server query, user, microversion for api concept doc
12:03:42 <alex_xu> cdent: people didn't get work status yet?
12:03:58 <alex_xu> just need more review for those api concept doc
12:04:08 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/api-site+branch:master+topic:fix-compute-api-ref,n,z
12:04:14 <oomichi> alex_xu: yeah, +1
12:04:21 <sdague> o/
12:04:28 <alex_xu> there are some nice fix from jichen
12:04:50 <alex_xu> jichen: appreciate that, when I clear up the etherpad, also found a lot of review comment for the api ref :)
12:05:08 <alex_xu> #link https://etherpad.openstack.org/p/nova-v2.1-api-doc
12:05:25 <jichen> alex_xu: yeah, still need some patches for the comments :)
12:05:26 <alex_xu> I did some cleanup for these etherpad, hope it's more clear
12:05:36 <alex_xu> jichen: :)
12:05:49 <alex_xu> #topic most needed next content patches
12:05:56 <jichen> ok, thanks ~
12:06:03 <alex_xu> not sure, but I will begin to write something for extension in api concept
12:06:24 <alex_xu> free to sign up, still have few todo, then api concept is very close
12:07:09 <alex_xu> #topic remove project id
12:07:21 <sdague> given that extensions are now deprecated, I wouldn't write about them much
12:07:26 <sdague> we don't want people doing that
12:07:45 <alex_xu> sdague: yea, I want to clear that, to tell people extension are deprecated
12:08:09 <sdague> ok, on the remove project_id from urls effort, there is a wrinkle which has to do with overlapping routes
12:08:09 <alex_xu> that sounds like that part will more easy to write :)
12:09:15 <sdague> https://review.openstack.org/#/c/256089 I was trying to figure out why randomly we'd fail 1 functional test that was doing a get of 'extensions/os-agents'
12:09:16 <alex_xu> sdague: for legacy v2 mode?
12:09:21 <sdague> no, for v2.1
12:09:46 <sdague> and because of the way we parse out '{project_id}'
12:09:54 <sdague> which can be anything
12:10:33 <sdague> The following request: /v2.1/extensions/os-agents can either match to project_id == extensions, controller = os-agents
12:10:45 <sdague> or project_id = None, controller = extensions
12:11:01 <alex_xu> emm...ok
12:11:22 <sdague> there are about 5 extensions that produce this overlap
12:12:23 <sdague> this is because of how python routes module works
12:12:24 * alex_xu add that patch to review list
12:12:42 <sdague> where it builds a giant routing regex - http://paste.openstack.org/show/483489/
12:12:54 <sdague> and we just get match answers at the end
12:12:56 <cdent> sdague: were you able to roust anybody on that pull req?
12:13:16 <sdague> cdent: dhellmann is following up on it, he knows the maintainer
12:13:28 <cdent> dhellmann++
12:13:36 <alex_xu> cool
12:13:40 <sdague> to be clear, the routes pull request don't solve this issue for us, it just gives us some new options
12:14:19 <sdague> the problem is, project_id actually has no schema definition in openstack except string < 64 chars (keystone db constraint)
12:14:41 <sdague> so even though uuid is expected from keystone, you can wedge other things in there
12:14:44 <sdague> rax has ints
12:15:19 <cdent> Your suggestion of making it a configuration character class or something along those lines, makes sense. And make the default the most common (or better: most correct) thing?
12:15:29 <oomichi> sdague: project-id of rax is integer?
12:15:34 <sdague> oomichi: yes
12:15:43 <oomichi> sdague: oh, surprised..
12:16:17 <sdague> cdent: yes. Given this is only an issue during overlap, I'm thinking about the smallest possible fix now, instead of the right one
12:17:00 <sdague> so even just requring project_id to be [0-9a-f]+ (i.e. hex of any sort) would kill the overlap
12:17:09 <sdague> and would work fine for ints
12:17:29 <sdague> that regex doesn't work without the routes fix though
12:18:21 <sdague> anyway, this remains an unsolved problem right now
12:18:34 <alex_xu> sdague: ok, thanks for the update
12:18:54 <alex_xu> so lets move on
12:19:02 <alex_xu> #topic API futures - patches for approved specs
12:19:10 <alex_xu> #link https://review.openstack.org/257261
12:20:10 <alex_xu> I want to discuss this patch. I feel we are missing something. This patch adds the macs and ip type back to the API, due to we missing those fields when we port v2.1 API
12:20:33 <jichen> yeah, you said : We should have a patch remove those extension name from extension API https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/extension_info.py#L45-L46
12:20:38 <alex_xu> But the extension entry ExtendIPs and ExtendIPsMac still in the extension API
12:21:13 <alex_xu> jichen: yea, I think we should those extension entries from extension API, and backport that patch.
12:22:11 <alex_xu> because that will break the v2 legacy user. We assume legacy v2 user still use extension to detect whether the macs address and type in the API response
12:23:21 <jichen> um... so they won't need extention anymore, just use the API microversion from then on?
12:23:31 <oomichi> alex_xu: you are meaning we need to remove those extensions from "list extensions" API in this patch?
12:23:41 <alex_xu> oomichi: yes
12:23:49 <alex_xu> oomichi: no, a separated patch
12:24:12 <oomichi> alex_xu: ok, in long term, it is nice to remove extensions.
12:24:15 <alex_xu> jichen: yes, your patch just add two new fields in the api
12:24:29 <oomichi> alex_xu: but I agree with that should be done with separated patch.
12:24:38 <alex_xu> and we should backport it
12:25:00 <oomichi> alex_xu: difficult to do that. that is not a bug.
12:25:09 <sdague> honestly, I'm not thrilled with the changing of the ips sub resource
12:25:19 <sdague> it does what is expected today, lists ips
12:26:35 <alex_xu> mac address looks like close to ip address is fine
12:26:47 <sdague> I disagree.
12:27:10 <oomichi> I am fine on current implementation with bumping a microversion without removing those extensions.
12:28:58 <alex_xu> sdague: ok, you expected user get that from neutron?
12:29:18 <sdague> alex_xu: or a new resource entirely
12:29:39 <sdague> in the neutron case are we going to be making a call to neutron under the covers?
12:30:02 <alex_xu> sdague: that sounds like extend more network API in nova
12:30:14 <alex_xu> sdague: I guess that in the network cache
12:30:43 <sdague> yeh, I feel like we should be really careful about becoming the primary interface for more network info, and if we do, be really explicit about it.
12:31:12 <sdague> it's also not hugely clear to me what the mac address does for the end user
12:31:20 <cdent> I was going to ask that
12:31:33 <cdent> ip, sure. mac addr, huh?
12:31:48 <sdague> jichen: what was the use case you had here where you needed this data?
12:32:35 <jichen> I see this code used to be there with some comment and with an extension, so I think it would be helpful to add it
12:33:00 <sdague> jichen: because it was there once upon a time, isn't really a good reason
12:33:09 <sdague> what use case do you have for using this data
12:34:18 <cdent> sorry, I have to go, will catch up with the logs later
12:34:23 <jichen> sdague: yeah, you are right, it's not a reason ;   I just think ,someone might want to check mac address for some analysis purpose
12:34:56 <sdague> jichen: I think we should put this on hold without a use case for it
12:35:08 <sdague> because every interface we add we have to support forever
12:35:18 <sdague> so lets only do that if we really really need it
12:35:45 <oomichi> this patch doesn't get approval of the corresponding nova-spec?
12:36:03 <jichen> it's approved
12:36:08 <alex_xu> no, we have a spec...
12:36:18 <oomichi> can we see the url?
12:36:25 <sdague> maybe, but I think it's ok for us to realize that we made a mistake
12:36:47 <oomichi> as alex_xu said, the bp is not written on the commit message and we cannot see it easily now
12:36:49 <jichen> https://review.openstack.org/#/c/247496/1/specs/mitaka/approved/ips-add-max-and-type.rst
12:37:31 <sdague> the spec is not approved
12:37:45 <sdague> oh, old link
12:37:51 <oomichi> oh, the spec doesn't contain the use case.
12:38:23 <oomichi> even if I +1d..
12:38:24 <sdague> yeh, it just says this was in the v3 code
12:38:32 <alex_xu> ok, learn that...
12:38:42 <sdague> yeh, I want to reopen this conversation and have a use case for this
12:38:58 <alex_xu> ok
12:38:59 <oomichi> sdague: +1 for concrete use case
12:39:11 <jichen> ok, I agree I am going to search for more info on original code on the user case
12:39:27 <alex_xu> jichen: thanks
12:39:36 <jichen> thanks a ll
12:39:38 <jichen> all
12:39:59 <alex_xu> ok, any more want to bring up?
12:40:15 <oomichi> sdague: related to project-id change, it is great to approve https://review.openstack.org/#/c/181393/ faster.
12:40:35 <oomichi> sdague: how to get approve on the openstack-spec?
12:40:42 <sdague> oomichi: it's on the TC agenda today
12:40:51 <oomichi> it spec gets a lot of +2s already
12:40:58 <oomichi> sdague: cool :)
12:41:01 <sdague> yeh, we'll try to get that sorted
12:41:12 <alex_xu> cool:)
12:41:37 <alex_xu> #topic open
12:41:42 <sdague> jichen: so, honestly, I would say unless there is a really compelling reason, don't bother. We shouldn't just add code because it was there before.
12:41:51 <sdague> I -2ed the patch until we have a use case in the spec
12:42:33 <jichen> sdague: yeah, I will try to find more info on that then update the spec if I have, thanks for the help~
12:42:46 <alex_xu> cool
12:42:58 <alex_xu> we are close to mid-cycle, so anything we want to talk about that?
12:43:09 <sdague> who all is going to be there?
12:43:11 <sdague> o/
12:43:16 <alex_xu> o/
12:43:31 * alex_xu go to mid-cycle first time~
12:43:53 <oomichi> sdague: alex_xu: cool :) I cannot make it at this time
12:44:27 <alex_xu> oomichi: :(
12:44:35 <oomichi> for preparing my live-migration to US
12:44:53 <oomichi> anyways, enjoy the mid-cycle :)
12:45:01 <alex_xu> oomichi: cool, good luck for live-migration, I guess that is block migration...
12:45:03 <jichen> not far away but not able to :(   enjoy ~
12:45:08 <eliqiao> cool oomichi , when will you do `live-migration`?
12:45:34 <oomichi> eliqiao: 11th/Feb
12:45:37 <alex_xu> jichen: I thought you can, as you are more close to UK...
12:45:37 <eliqiao> and city?
12:45:57 <oomichi> San Jose, CA
12:46:21 <alex_xu> anything we want to discuss at mid-cyle about api?
12:46:59 <oomichi> alex_xu: how about fairy-slipper thing?
12:47:25 <oomichi> I cannot understand it yet
12:47:43 <sdague> yeh, that would be nice to know more about
12:47:51 <alex_xu> oomichi: yea
12:49:05 <alex_xu> looks like it's on very early stage yet
12:49:14 <jichen> any more info about fairy-slipper ? thanks
12:49:36 <alex_xu> sdague: does mid-cycle meetup is same as summit design session?
12:49:49 <jichen> just googled but not https://github.com/russell/fairy-slipper ?
12:50:10 <sdague> alex_xu: we typically have a rolling agenda of an etherpad
12:50:22 <alex_xu> jichen: yea, that one
12:50:35 <oomichi> jichen: https://github.com/openstack/fairy-slipper
12:50:55 <alex_xu> yea, it move to openstack project, cool
12:50:59 <jichen> oomichi: got it ,thanks~
12:51:05 <oomichi> jichen: and http://lists.openstack.org/pipermail/openstack-dev/2016-January/083670.html
12:52:01 <alex_xu> #link https://etherpad.openstack.org/p/mitaka-nova-midcycle
12:52:07 <alex_xu> ah, I found the link
12:52:27 <alex_xu> There is API discussion at first day
12:53:03 <alex_xu> ok, i guess people just free to put the idea
12:53:17 <alex_xu> if no more question, let us close the meeting early today
12:53:36 <oomichi> thanks all
12:53:43 <alex_xu> thanks all!
12:53:44 <sdague> ok, thanks folks
12:53:52 <jichen> thank you
12:53:53 <alex_xu> #endmeeting