12:00:08 #startmeeting nova api 12:00:08 Meeting started Tue Dec 8 12:00:08 2015 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:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:00:11 The meeting name has been set to 'nova_api' 12:00:17 who is here today? 12:00:31 hi 12:00:44 o/ 12:00:47 morning 12:02:09 morning/evening everyone 12:02:09 we probably have short meeting today, as today is api doc sprint! 12:02:09 #topic actions from last meeting 12:02:09 we didn't have any action from prevous meeting 12:02:28 cools 12:02:28 o/ 12:02:29 only thing is, sdague do you have any update for api ref approve permission? 12:02:35 hi 12:02:43 alex_xu: I don't yet 12:03:02 sdague: ok, it's fine, without that, it still works for us 12:03:12 #topic doc sprint 12:03:18 I told anne that I'd like the nova cores that do API work to be in an approve group for that, so me, johnthetubaguy, alex_xu, oomichi 12:03:29 she seemed ok with it, but it hasn't yet materialized 12:04:11 we have some patch up for concept doc 12:04:12 #link #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/complete-todo-in-api-concept-doc,n,z 12:04:12 oops 12:04:17 sdague: johnthetubaguy would you like take a look few of patches from me, it adds more todos, I think it is useful for people looking for tasks 12:05:17 alex_xu: looking at them now actually 12:05:20 alex_xu: sure, can do, I meant to start going through these yesterday, but fell down a rabbit hole with unwinding our glance configuration 12:06:17 and gmann_ create a topic for api-ref, it will be great people use same topic 12:06:18 #link https://review.openstack.org/#/q/status:open+project:openstack/api-site+branch:master+topic:fix-compute-api-ref,n,z 12:06:19 am i still online, looks like super quiet... 12:06:43 yep, still online 12:06:45 I see you 12:07:17 jichen: oomichi gmann_ sdague any response? 12:07:25 related to this api-ref, I sent a mail about http203 12:07:31 to openstack-dev 12:07:36 oomichi: link? 12:07:40 ok, 12:07:40 yea 203 needs to be discussed 12:08:12 #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/081690.html 12:08:17 that is 12:08:51 api-site contains a lot of 203 as valid code 12:09:06 sdague: oomichi yea but for some API not all 12:09:15 oops, I have huge delay for message 12:09:19 we may need to define that at upper level if that is valid one 12:09:32 honestly, it seems weird 12:10:05 sdague: someone tried to add 203 as valid code to tempest before 12:10:14 oomichi: do you have that patch? 12:10:18 there are some discussion over patches - https://review.openstack.org/#/c/254483/ https://review.openstack.org/#/c/242901/ 12:10:27 I cannot find it now, too old 12:10:29 were they doing it because it was in the doc? or do they have a real reason 12:10:29 well we have to start with documenting what we have, I suspect we will find lots of odd things during this process 12:10:36 sdague: ^^ 12:10:42 sdague: because of the doc 12:10:53 because of the doc... arg 12:11:04 #link https://review.openstack.org/#/c/242901/ 12:11:26 * cdent can't imagine a situation where _application_ code should be generating 203 12:11:52 johnthetubaguy: is this a repose thing? 12:11:59 that is not what any API returns its manipulated from proxy thing actually 12:12:00 so lets back up a bit, is it possible to get 203 in the code? 12:12:07 johnthetubaguy: no, it is not 12:12:16 sdague: its possible, not sure how it got in the docs though 12:12:18 203 can't be generated by the code today 12:12:27 yea 12:12:30 right, lets just drop that form the API description then 12:12:32 so I feel like it should be removed from the docs 12:12:35 yeah 12:12:35 johnthetubaguy: agreed 12:12:36 * cdent nods 12:13:16 the concept of having two success codes for an API call just freaks me out 12:13:36 +1 I tried to submit one but someone told me it's added by Annta, let me try to search the history 12:13:37 yep 12:14:10 sdague: I see 12:14:21 +1 remove it 12:14:31 I suspect it has to do with the rax setup, but it's fine that we separate what OpenStack expects to be true, and any particular vendor setup 12:14:44 yea +1 to remove 12:15:06 can we discuss this on -dev for getting a consensus from wide area including doc team? 12:15:40 oomichi: sure, or on the review 12:15:47 I explained why I think it should go in my +1 12:15:51 sdague: thanks :) 12:16:08 yeah, totally should not include any vendor specifics in our API docs 12:16:47 one more question for me, when i look at version section in concept doc 12:17:09 we have '/v1.1' endpoint, but we won't return '1.1' api in the version API 12:17:15 #link https://review.openstack.org/#/c/254687/2/api-guide/source/versions.rst 12:17:39 I just send a patch, the current response from the version API just include 2.0 and 2.1 12:17:59 alex_xu: because /v1.1 is just alias 12:18:30 its not been in there long enough that I am not worried about it, I guess. Although that sure makes it harder to remove/detect 12:18:40 oomichi: ok, alias make sense 12:19:00 ok, if no worry, just move on 12:19:02 in a related area, I just put a -1 on here: https://review.openstack.org/#/c/254473/ 12:19:03 https://review.openstack.org/#/c/246297/1/api-ref/src/wadls/compute-api/src/v2.1/wadl/images-v2.1.wadl 12:19:20 johnthetubaguy: I thought we were going to drop the /v1.1 in the default paste? 12:19:20 alex_xu: is the one I mentioned for the 203 return code 12:19:46 sdague: I didn't think we could, as its always been there 12:20:05 so, I know of no one, and no tests using it 12:20:30 I would really like to do whatever is required to deprecate and phase it out 12:20:34 at least in our defaults 12:20:35 johnthetubaguy: that is because mentioning later "v2.0" 12:20:50 because vendors can add it back 12:21:03 sdague: sure, but it feels like so little cost to keep it, seems bad to break backwards compatibility 12:21:19 jichen: emm, I didn't get the comment, the 203 for some purpose? 12:21:31 johnthetubaguy: how many rax users hit it? 12:21:35 oomichi: OK, probably need to phrase it differently 12:21:36 brb 12:21:42 johnthetubaguy: the endpoint seemed to imply "v2.0" as the endpoint, but I removed the "v2.0" on the patch. then I added it. 12:21:46 sdague: I don't know actually, thats a good question 12:22:30 alex_xu: - Anne Gentle updated all these to separate out the 203 return code for the purposes of migration to RST, I don't know what's RST, I thought it might be history related 12:23:40 oomichi: added an alternative way of phrasing that in the patch, to see if that helps 12:24:19 johnthetubaguy: sorry, difficult to get your comment for me. 12:24:42 johnthetubaguy: nice to clarify what is v2.0 separately in the doc, right? 12:25:18 jichen: from the title of your patch, it is going to remove 203 response. So I guess that comment isn't related we should keep 203 as valid return code. 12:25:23 the thing is, v1.1 hasn't been returned in our version discover for years 12:25:36 oomichi: added a new comment in the review for a new way to word that 12:25:52 when we say remove, what we're saying is removing 1 paste pipeline line so that new installs don't get this 12:25:58 johnthetubaguy: ok, thanks! 12:26:18 https://github.com/openstack/nova/blob/7c02bde804434dfd769fdaf7fb6d1ccbcb946d66/etc/nova/api-paste.ini#L78 12:26:23 alex_xu: oops, I misunderstanding it .. 12:26:41 sdague: we are also saying we break users that wrote scripts against the version that only had the /v1.1 endpoint present 12:26:57 sdague: but thats long enough ago, I would not block that 12:27:00 johnthetubaguy: no, we actually aren't 12:27:16 because existing clouds typically don't blindly blast over their paste.ini 12:27:44 emm..sounds good pint 12:27:45 johnthetubaguy: also, if we believe v1.1 is a thing, it should be in our version list 12:27:49 s/pint/point 12:27:49 GET / 12:27:56 sdague: true 12:28:03 which it is not, and has not been for 3 years? 12:28:09 yes, that is a little strange 12:28:18 so, that makes me believe it is not a thing 12:28:25 yeah, I don't want to add it in there 12:28:33 sdague++ 12:28:34 so probably easiest to just drop v1.1 12:28:57 then we should remove it, and reno the fact that we're doing this, and what a site should do if they want to keep it locally 12:29:03 we could call that three year deprecation window or something, if it makes us feel happier about that 12:29:07 yup 12:29:11 should we have mail to operator-ML before we remove 12:29:15 you can sign me up for that, I'll make the patch today 12:29:33 nice to drop v1.1, and that is a nice step before droping v2.0 12:29:46 oomichi: dropping v2.0 is not on the table any time soon 12:29:52 or possibly ever 12:29:55 we should inform the operators, not sure we should give them the option 12:30:10 oomichi: yeah, I can't see me ever not -2ing /v2.0 removal 12:30:11 sdague: yeah, I know in short-term 12:30:13 yeh, lets land the patch and FYI it to the ops 12:30:31 yeah 12:30:56 #action sdague make a patch for remove 1.1 and info the ops 12:31:11 thanks alex_xu, was about to record that myself :) 12:31:20 sdague: :) 12:31:33 ok, so let's move on? 12:31:38 yep 12:31:39 any more question about sprint? 12:31:56 ok, move on 12:32:05 alex_xu: is it worth updating the nova-spec dashboard in gerrit dash creator with the topics you want reviewed? 12:32:23 or making another dashboard for this? 12:32:27 its in the review etherpad at least 12:32:43 #link https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking 12:33:06 sdague: I think it's fine, we just have one topic for concept doc and one topic for api-ref 12:33:43 yeh, I just find the dashboards easier because they typically have NOT label:Code-Review>=-2,self 12:33:51 which means you know all the ones you don't have an active vote on 12:33:57 so you can use it as a todo list 12:34:14 anyway, just a thought, lets move on 12:34:57 ok 12:35:07 #topic API futures - specs 12:35:13 #link http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/live-migration-progress-report.html 12:35:21 johnthetubaguy: ^ your turn 12:36:24 emm...did I get network slow again? 12:36:32 no, I see you :) 12:36:37 ok :) 12:36:48 alex_xu: yea you are fine :) 12:36:52 * edleafe yawns 12:36:57 yeah, I can see alex_xu 12:37:02 sdague: ^ do you know the detail about that? 12:37:45 * alex_xu pokes edleafe avoid him get sleep 12:38:31 if they are no response, let us jump to the open, maybe they will be back after few minutes 12:38:44 I think the issue is that we did all this conversation about using the servers/{id}/migrations/{id} for pause 12:38:53 and that is the resource that should be used for status 12:39:03 instead of a global lookup resource 12:39:18 * edleafe thanks alex_xu 12:39:44 sdague: so the servers/{id}/migrations/{id} is totally different resource with /migrations? 12:39:50 yes 12:39:57 which does not yet exist 12:40:08 what is for /migrations in the future? 12:40:08 but johnthetubaguy didn't want to further expand /migrations 12:40:39 good question, and I'm not sure, but the future here should be per server 12:40:45 because a migration is about a server 12:41:20 yeah, I think we drop /migrations in a later microversion 12:41:27 once the per-server stuff works better 12:41:47 or just make it a cross server list for admins, so you query by host 12:41:57 johnthetubaguy: if we drop /migrations, we are missing a function for query old migration? 12:42:00 but anyways, feels like we should really add that stuff in the new place for now 12:42:15 alex_xu: yeah, maybe thats what we keep it for then, the admin use caess 12:42:24 johnthetubaguy: sdague alex_xu yea how we will get history data for migration 12:42:56 because that helpfull if any migration has not completed or failed 12:43:02 anyways, just feels like this data would fit better on the per server active migrations, than it does after the migrations have finishished 12:43:14 the progress info 12:43:48 also, it doesn't seem to be clear on live-migrate vs migrate, and what happens when info is not available, but I may have just missed that. 12:44:11 imaging use case: when migrating servers, they want to make some host free. is it nice to get the migrating servers with secific *source host* ? 12:44:21 I think /migrations is a thing that goes away should we get a tasks interface 12:44:30 because migrations are always going to be outstanding tasks 12:44:39 and that would be the way you seach for them 12:44:56 I'm a little prefer to keep same view for two resources, different view will make user confused. for keep same view, we also can remove the /migration directly in the future 12:45:00 servers/{id}/migrations/{id} is the specific migration 12:45:02 I am imaging we can do that on /migrations 12:45:22 alex_xu: no, we don't want /migrations format extended 12:45:45 that can be the list to get links to servers/{id}/migrations/{id} 12:46:41 sdague: that is for people won't continue depend on the old /migrations? 12:46:47 I think we need to just consider that /migrations is the existing search interface 12:46:52 and that's what it is, search 12:47:04 with more info at the new resource 12:47:24 so the only thing that should extend about it is each migration should include a link to the new migration resource 12:48:11 nice to extend new resource with using /migrations for searching 12:48:23 sdague: or just migration id list 12:48:43 sdague: what is the purpose of the link? 12:48:48 gmann__: I think the existing info is fine 12:48:57 alex_xu: so that you can get all those details 12:49:00 or cancel it 12:49:36 the whole theory of the API is you have collection resources like /servers /migrations /images that you can search on 12:49:37 sdague: ok 12:49:43 that provide links to things you operate on 12:49:50 or get more details with 12:50:10 so that all the resources are discoverable via link following 12:50:36 ok, so that will be N release work? 12:50:57 yea sounds standard way. 12:51:47 alex_xu: no, this has to be for M 12:52:04 because there are 2 specs approved to change migrations, and the assumption is they'd operate on this new resources 12:52:09 sdague: ok, cool, happy to see this move on, if we have plan 12:52:26 i.e. I'm -2 on all patches on this live migration status if they update the existing resource 12:52:47 so we need update the spec 12:52:50 alex_xu: so can you circle with the intel folks and get them to make a spec update? 12:53:00 yeh, that was the point of the agenda item 12:53:01 sdague: yup, I will do that 12:53:08 realizing this fell through the cracks 12:53:38 sdague: I mean for adding link in /migration is N release work? 12:54:00 alex_xu: yeh, it needs to be as part of the same version that adds the extended status 12:54:12 otherwise how to people discover the new resources? 12:54:28 sdague: ok, I see now 12:54:49 then let talk about remove /migration in the future 12:55:03 that requires tasks I think 12:55:08 and I don't think it's urgent 12:55:14 I think lets just focus on getting the specs representing the current agreed direction 12:55:19 yeah, we can punt the rest of it 12:55:20 johnthetubaguy: agreed 12:55:51 ok, I didn't get the relationship about migration and task yet, I thought they are same purpose 12:55:51 I have an exception request in to look at making os-instance-actions more consistently used, in the hope of making some progress on "tasks" 12:56:19 cool, if we have progress on tasks 12:56:27 #topic open 12:56:32 alex_xu: long term, I think a migration might also be tracked by a task, but lets worry about that later I guess 12:56:40 sorry, jump to open direclty, avoid people need help 12:56:41 ok, open topic question - api samples testing 12:56:58 johnthetubaguy: yeah, that is nice direction in long term 12:57:17 johnthetubaguy: ok, expect that 12:57:23 I was a little confused by some of the testscenarios logic in https://review.openstack.org/#/c/254401/1/nova/tests/functional/api_sample_tests/api_sample_base.py,cm because it seems like there are some odd conditionals in there to setup the tests 12:57:45 especially as we want to add a 4th path which doesn't have project_ids in the path 12:58:06 post meeting, can we go through that in #openstack-nova? 12:58:18 sure 12:58:26 and gmann__ are expert onthat 12:58:27 yeah, I think we had a TODO to turn all extensions on, not sure if we got that done yet 12:58:37 and one additional question, the patch auggy is working on for making project_id optional 12:58:46 yup, I saw patch from gmann__ 12:58:47 sdague: sure i thought to remove project id from existing one 12:58:58 we can talk about that in next meeting also 12:59:11 johnthetubaguy: in progress done for image and flavor only 12:59:11 in order to samples test that, my suggestion is we put a new set of samples in doc/api_samples/{foo}/v2.13 12:59:22 because we'll signal this with a microversion 12:59:30 and wanted to make sure that made sense to folks 12:59:36 or if there is a better way to do it 12:59:52 1 mins left, let move to openstack-nova directly 12:59:56 ok, sounds good 12:59:58 ok 13:00:07 thanks all! enjoy the doc sprint! 13:00:12 #endmeeting