13:00:38 #startmeeting nova api 13:00:39 Meeting started Wed Jul 26 13:00:38 2017 UTC and is due to finish in 60 minutes. The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:42 The meeting name has been set to 'nova_api' 13:00:47 o/ 13:00:51 who is here today? 13:00:53 o/ 13:02:03 ok, let us start the meeting :) 13:02:45 I guess we have no more microversions can be merged in these two days? 13:03:00 there still have few client side patches 13:03:07 #link https://review.openstack.org/#/c/485435/5 13:03:17 ^ start from this one 13:03:37 mriedem: the client won't be freeze at tomorrow, right? 13:04:05 it is 13:04:05 27 is final release right 13:04:08 * johnthetubaguy wonders in several months late 13:04:10 tomorrow is final client release 13:04:33 alex_xu: i just pushed up the test impl for that service delete test in the client patch 13:04:41 johnthetubaguy: :) welcome back 13:04:48 johnthetubaguy: welcome back :) 13:05:00 mriedem: ok, we need to speed up the review 13:05:18 alex_xu: yeah if you can go over it again before you end your day, 13:05:25 then i can have sdague take a look later today again too 13:05:38 or talk to andrey or Vek 13:05:43 mriedem: yea, I will do that after the meeting 13:05:55 thanks 13:06:24 for no more extension, I only expect this patch merge https://review.openstack.org/#/c/486414/2 13:06:34 other cleanup can be done in next release 13:07:04 mriedem: this one need +w https://review.openstack.org/#/c/485061/, then we finish the goal of no more extension in pike 13:07:16 sorry, just wandering in 13:08:19 alex_xu: nice! 13:08:20 sdague: thanks :) 13:09:29 I want to remove the objects related to extension, but I still found a lot of garbage in our unittests. so I think we can continue those in next release 13:10:01 alex_xu: looks like https://review.openstack.org/#/c/486416/ is the only other thing in that series that needs a +W 13:10:09 but the series needs to be rebased in order 13:10:51 alex_xu: yea, we do not have anything in functional tests 13:10:55 well maybe it'll go 13:11:00 i'll just rebase today as needed 13:11:14 do we have release notes for any of this at a high level 13:11:24 like, how is this different from when extensions were 'disabled' in newton? 13:11:35 because i know some people.....that have api extensions 13:11:48 mriedem: the plumbing for extensions is now removed 13:12:03 honestly, I don't think it's release note material 13:12:20 this is internals that we said were not to be used a couple of releases ago, that are now deleted 13:12:29 but if i have an extension in my forked nova code repo, don't i just now register the route like everything else in here? 13:12:57 mriedem: we used to provide infrastructure to let you do that in the system 13:13:02 i guess the stevedore extension stuff is gone, 13:13:06 right 13:13:08 so my api extension could be a separate git repo 13:13:15 or easily maintained 13:13:18 ok, yeah, i was thinking more about people that just have them in a forked nova branch 13:14:03 if you have forked nova code... this is basically going to be a giant amount of work for you to get through 13:14:16 but, that's never supposed to have been our target audience 13:15:01 still seems like it should be a release note 13:15:19 i don't expect people to keep all of the newton release notes in mind when reading the pike release notes 13:15:29 especially if they just installed openstack for the first time in ocata 13:15:36 do we release note internals changes to objects? 13:15:53 no, but we release note the removal of deprecation options and hook points 13:15:55 if they installed for the first time in ocata, this doesn't impact them 13:15:59 we have release note for the extension related configure options 13:16:23 mriedem: the docs were all scrubbed of that a while ago 13:16:45 alex_xu: this: "Deprecated config options to enable/disable extensions extensions_blacklist and extensions_whitelist have been removed. This means all API extensions are always enabled. If you modifed policy, please double check you have the correct policy settings for all APIs." 13:17:11 mriedem: yea 13:17:24 it's honestly going to be more confusing to release note this because it will say "we removed the ability to side load extensions through setup.cfg, that was never documented, and was officially removed 2 releases ago." 13:17:26 ok, and there is one about discoverable policy for extensions too 13:17:57 the API plugin stuff was documented in the devref before 13:18:08 or was that just bad naming 13:18:29 https://docs.openstack.org/nova/newton/api_plugins.html 13:18:51 yea 13:18:53 https://docs.openstack.org/nova/latest/contributor/api.html 13:19:23 we still have something to update 13:19:59 yea those doc we can update 13:20:07 but, on the plus side, 13:20:15 there is nothing in there about stevedore loading out of tree API plugins/extensions 13:20:19 that's what i was looking for 13:20:35 so i think these docs are basically ok, they are just talking about how to add new APIs into the compute API 13:20:42 they need to be updated for the route map 13:20:46 but that's probably about it? 13:21:00 yes 13:21:02 yea. 13:21:04 ok cool 13:21:09 mriedem: yeh, definitely should be updated with the route map 13:21:09 let's move on then 13:21:10 remove the 'extensions.V3APIExtensionBase' 13:21:31 alex_xu: oh... interesting thing I found in running tests on the request logger 13:21:40 should we delete this also - https://docs.openstack.org/nova/latest/reference/stable-api.html 13:21:51 this talks about old extension background 13:21:57 sdague: still have interesting thing happened? 13:22:03 the handler for / requests inherits from the v2.0 legacy handler 13:22:10 which means that microversions are stripped 13:22:31 which, might be something that we should change 13:23:17 gmann_: I need to reread those doc, if they just say something changed in the compatible v2.0 legacy API, that will be ok 13:23:18 gmann_: i wouldn't remove it, but i'd update it to say the ability to load API extensions via stevedore and blacklist/whitelist them is gone in pike 13:23:19 it mostly just made writing the tests a little hard 13:23:19 this one ? https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/versions.py#L75 13:23:28 gmann_: that doc is mostly history 13:23:32 gmann_: yes 13:23:34 so let's just make it current 13:24:02 mriedem: ok, make sense 13:25:16 sdague: you mean no microversion info in the log when request to '/'? 13:26:46 alex_xu: correct 13:26:59 sdague: alex_xu we have for v2.1 also - https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/versionsV21.py#L24 13:27:02 but that also means it's not possible to do mv negotiation on that endpoint 13:27:17 https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/routes.py#L412-L413 13:27:37 which, with some of mordred's stuff on standardizing version docs, might be appropriate 13:27:41 just a thought 13:28:08 we still need this deprecation in - https://review.openstack.org/#/c/486623/ 13:28:59 I think the python-novaclient do mv negotiation on the '/' now 13:30:28 right, using https://developer.openstack.org/api-ref/compute/?expanded=list-all-major-versions-detail#list-all-major-versions 13:30:33 you get back the min/max versions 13:30:45 to determine if you can do 2.53 or just 2.20 13:31:03 do we need microversion negotiation for handling a 2.1 vs 2.53 request to / ? 13:31:07 the response is the same isn't it? 13:32:43 mriedem: yes, it is same 13:33:05 ok, so doesn't seem like a major issue right now 13:33:11 yeh, it was more of an fyi 13:33:32 ok 13:33:59 so to recap, 13:34:05 1. novaclient 2.53 change needs review 13:34:19 2. remaining no more api extensions patches are approved, we just need to shephard through the gate 13:34:29 3. need to update the api plugins / stable api docs for the route map stuff 13:34:39 4. deprecate wsgi_log_format 13:34:54 yeah? 13:35:14 yea 13:35:43 yes. 13:35:44 and one bug from Kevin_Zheng https://review.openstack.org/486850 13:36:19 only #1 and #2 need to be done before freeze 13:36:39 o/ 13:36:39 is href so useful ? can we just have base url with version 13:36:57 i can do 3. 13:37:02 gmann_: that sounds like a API behaviour change 13:37:12 gmann_: thanks 13:37:16 alex_xu: humm 13:37:37 I think we can get correct url by 'req.environ['PATH_INFO']' 13:37:45 Kevin_Zheng: worth a try ^ 13:38:18 alex_xu: but if we put some random string there. 13:38:30 i tried like GET http://10.76.150.17/compute/xyz 13:38:52 then how we know what is actual endpoint patch till 'compute' or / 13:39:04 patch->path 13:40:50 gmann_: I see 'PATH_INFO' will return 'xyz' 13:41:29 yea 13:41:47 we should also filter /compute 13:42:05 or anything was set to be the endpoint 13:42:15 Kevin_Zheng: /compute is not all time thing. it can be anything 13:42:22 yea 13:42:25 so we left with base url 13:42:45 We should probably actually reach back into the keystone catalog to get the right value 13:42:49 that's where it's really stored 13:42:52 I understand, I mean, path will also include this 13:43:00 and it will got duplicated 13:43:09 after that what is wrong version coming for / request is not known to be bad version or bad string 13:43:10 that being said, this seems like a pretty minor bug, right? 13:43:40 oh, I guess we're returning more garbage than I was expecting 13:43:42 sdague: for me too, i never read href :) 13:43:57 yeh, we do document it, I don't think anyone uses it 13:44:19 the real issue is the 300 multiple choice docs 13:44:27 those aren't really useful 13:44:52 yea 13:45:06 always pick "C" if you don't know the answer 13:45:19 but I still think req.application_url + version + req.environ['PATH_INFO'] is the correct url 13:45:28 so... I do wonder if the real fix is related to the routes 13:45:52 because now that we've got all the routes in the list, we could say "oh, this thing you are trying to get looks like a thing we know about, but in a subtree" 13:46:06 oh... 13:46:11 because right now that 300 multiple choice selector just reflects you the garbage you send in 13:46:25 which might also be non existant 13:46:43 it would be really nice if it only reflected the 300 if the guessed routes were a thing 13:46:48 otherwise, 404 13:47:41 yea, that sounds good, but we still need to fix that url when the routes were a thing :) 13:49:40 Kevin_Zheng said other services just return a 404 13:49:56 i think i reported a bug against glance's API for this same issue, trying to get versions using / 13:49:59 I tried Cinder Neutron 13:50:08 Kevin_Zheng: they are using pecan, right? 13:50:23 that probably saves them a bit here. All the nova code to do this is really custom 13:50:29 I don't think they do the 300 docs 13:50:41 as it wasn't a construct you could get into pecan 13:50:49 https://bugs.launchpad.net/glance/+bug/1632742 13:50:49 Launchpad bug 1632742 in Glance "/v2 route doesn't exist" [Undecided,Won't fix] 13:51:16 not exactly the same 13:51:45 yeh 13:53:19 https://github.com/openstack/nova/blob/master/doc/api_samples/servers/server-get-resp.json#L43 13:53:28 ^ I guess that is why we return 300 13:53:33 for the bookmark url 13:54:20 yeh 13:54:30 which has lots of issues with it 13:54:45 but, regardless, if we could test the route values before we return them in our route list 13:54:53 then 404 if they don't exist 13:54:57 that would probably be best 13:55:27 ok, I'm ok that without microversion 13:56:49 sdague: test route list means? with some checking in our routing mapping 13:57:00 route value 13:57:27 3 mins left 13:57:55 I think that should be another patch 13:58:25 one fix the url, another one checks the routes 13:59:10 k 13:59:21 1 min more 13:59:44 ok, let us move back to nova change or to the patch :) 13:59:58 thanks all 14:00:00 #endmeeting