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