12:00:05 <alex_xu> #startmeeting nova api
12:00:06 <openstack> Meeting started Tue Dec  1 12:00:05 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: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's here today?
12:00:29 <Kevin_Zheng> hi
12:00:31 <andrearosa> hi
12:00:34 <paul-carlton1> hi
12:00:38 <gmann_> hi
12:00:49 <alex_xu> hello everyone!
12:01:07 <PaulMurray> o/
12:01:14 <alex_xu> let's wait on more minutes for more people join in
12:01:17 <jichen> o/
12:01:56 <sdague> o/
12:02:20 <alex_xu> ok, let's start the meeting
12:02:28 <alex_xu> #topic actions from last meeting
12:02:33 <alex_xu> sdague ask docs team about approval rights by api subteam on our wadl
12:02:47 <alex_xu> sdague: do you have update for this ^ this is action before US holiday
12:03:04 <sdague> I did talk with annegentle about that, and she was going to ponder, I don't think we had real resolution on it
12:03:16 <sdague> I'll follow up again this week
12:03:25 <alex_xu> sdague: ok, thanks a lot
12:03:43 <alex_xu> ok, only on action, let's move on
12:03:48 <alex_xu> #topic content patches up for review
12:03:56 <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:04:08 <alex_xu> last week, we have topic for admin concepts
12:04:23 <alex_xu> thanks jichen and edleafe help on that :)
12:04:35 <alex_xu> #link https://review.openstack.org/#/c/249943
12:04:50 <alex_xu> this is for host. This is pretty good from me, although there is some discussion about deprecated host maintenance. As service and host have some overlap, that confuse user. But we can improve the doc next step.
12:04:59 <alex_xu> #link https://review.openstack.org/248454
12:05:12 <alex_xu> the service one was wrote by me, but I think it just need more feedback
12:05:26 <alex_xu> #link https://review.openstack.org/250737
12:05:38 <alex_xu> the last one is aggregate, hypervisor and migration.
12:05:55 <alex_xu> Pretty good we have devref about aggregate, but I'm a little concern that is for developer, not api user.
12:06:41 <sdague> yeh, I can write something on the agregates front
12:06:50 <alex_xu> sdague: thanks :)
12:07:05 <sdague> nice job so far, I'll do some reviews here later today
12:07:48 <alex_xu> The one we said want to be an example for api-ref already merged
12:07:56 <gmann_> alex_xu: sdague its worth to use devref one as ref also
12:07:56 <alex_xu> #link https://review.openstack.org/#/c/248534/
12:08:37 <alex_xu> gmann_: yea, agree, keep the ref is good also
12:08:57 <sdague> gmann_: sure, but this is a concept guide. Footnotes are fine to learn more, but this has to have the high level concepts in here
12:08:59 <alex_xu> for the api-ref one, I'm afraid people didn't get chance take a look at. But please feel free submit patch to correct it
12:09:30 * johnthetubaguy is happy to see so many patches up for those API docs now
12:09:32 <gmann_> sdague: yea, i was thinking high level concept + ref for more details which we already have
12:10:46 <alex_xu> if no more question for those patches, let's move on
12:11:03 <gmann_> yea
12:11:05 <johnthetubaguy> as a heads up, I did attempt to get our new guide linked from the complete reference: http://developer.openstack.org/api-ref-compute-v2.1.html
12:11:23 <johnthetubaguy> https://review.openstack.org/#/c/249725/
12:11:35 <johnthetubaguy> I suspect we can do better, but its a start
12:11:52 <alex_xu> johnthetubaguy: thanks :)
12:12:26 <alex_xu> I'm just a little worry about most of wadl patch didn't get chance for our guys' review
12:13:02 <sdague> honestly, we can fix it later if it's an issue
12:13:08 <alex_xu> or we can just continue with patch to improve it if we find problem
12:13:21 <alex_xu> sdague: yea, that also works
12:13:37 <alex_xu> anyway, let's move on
12:13:47 <alex_xu> #topic most needed next content patches
12:13:55 <alex_xu> We have good servers action, good user and admin concepts.
12:14:53 <alex_xu> I checked the doc, for servers, we can something more for scheduler-hints, bdm, servers query, consoles.
12:15:11 <alex_xu> we also can put more stuff about extension and microversions, version.
12:15:25 <alex_xu> what is people prefered topic for next?
12:15:46 <alex_xu> s/we can something more/we can add something more/
12:16:09 <paul-carlton1> can we talk about https://review.openstack.org/228828
12:16:13 <sdague> I'm going to have to go stare at this later. I haven't had my coffee yet today, so still a little slow on it
12:16:17 <alex_xu> and next week is our virtual doc sprint
12:16:26 <gmann_> alex_xu: yea
12:16:27 <alex_xu> paul-carlton1: sorry, I put that in next topic
12:16:35 <paul-carlton1> ok
12:16:54 <gmann_> alex_xu: for microversion we will add here right?  http://developer.openstack.org/api-guide/compute/microversions.html
12:17:15 <gmann_> or any other preferred structure?
12:17:50 <johnthetubaguy> gmann_: I intended that to talk about how microversions work, not to document them all
12:18:22 <gmann_> johnthetubaguy: yea, as all description we have in https://github.com/openstack/nova/blob/master/nova/api/openstack/rest_api_version_history.rst
12:18:25 <alex_xu> gmann_: that is for developer, need to check it first. the concept for normal api user
12:18:28 <gmann_> johnthetubaguy: mainly the usage part
12:18:39 <johnthetubaguy> right, just the usage bit really
12:18:51 <johnthetubaguy> and contrasting that with extensions for older versions of the aPI
12:18:52 <gmann_> alex_xu: with ref of that may be
12:19:09 <johnthetubaguy> I think covering the use cases sdague had in his blog are a good idea
12:19:17 <gmann_> johnthetubaguy: yea
12:19:21 <alex_xu> johnthetubaguy: +1
12:19:21 <johnthetubaguy> like these are the ways we expect people to use our API, etc
12:21:08 <alex_xu> ok, for this week, people can just focus on review, and free to pick other task.
12:21:41 <alex_xu> sdague: maybe we should check the existed doc to list some points need to improvement, then we can leave those for next virtual doc sprint
12:21:54 <sdague> alex_xu: yeh, that sounds reasonable
12:22:31 <alex_xu> ok, I will help on go through the doc again, to find something worth improvement
12:22:58 <alex_xu> so if you find something, you can submit a patch add some todo note
12:23:25 <alex_xu> ok, if no more question, let's move on
12:23:49 <alex_xu> #topic API futures - specs
12:23:55 <alex_xu> #link https://review.openstack.org/228828
12:24:00 <alex_xu> paul-carlton1: your turn
12:24:29 <paul-carlton1> sdague, proposed an approach which I have updated the spec to accommodate
12:25:08 <sdague> right, so I think we're all agreed that we need the functionality proposed in the spec. There seems to be disagreements on how we surface that to the user.
12:25:15 <paul-carlton1> but others did not want this and another spec  has already been approved using instance action approach instead
12:25:15 * edleafe wanders in half-awake
12:25:28 <paul-carlton1> #link https://review.openstack.org/#/c/229040
12:25:39 <alex_xu> the only point I have is migration resource is for all the migration. the delete also can means we cancel resize, evacaute?
12:25:50 <paul-carlton1> I'm happy with either approach but we should be consistent?
12:26:13 <johnthetubaguy> sdague: +1 that
12:26:51 <paul-carlton1> so delete on a migration stops it, in some cases the driver cannot do this so we get a not supported outcome in instance actions for the deletion of migrtion
12:27:30 <johnthetubaguy> is this a new migration resource, or the existing one?
12:27:45 <sdague> johnthetubaguy: it's the sub resource of servers
12:27:48 <paul-carlton1> it is an existing resource
12:27:49 <sdague> the approachI suggested
12:28:25 <johnthetubaguy> we don't currently have a sub resource of services that lists migrations though, just wanted to be clear on that
12:28:26 <paul-carlton1> GET /servers/{id}/migration returns the id of a migration object
12:28:40 <sdague> johnthetubaguy: right, it's a new resource
12:29:00 <johnthetubaguy> yep, thats cool, just wanted to make sure we were talking about the same thing
12:30:30 <johnthetubaguy> so my gut tells me, follow the old pattern, and eventually we replace all actions with a more async task focused API, with common patterns
12:31:11 <johnthetubaguy> but having said all that, maybe this is a good first attempt at the "new" pattern, so we should probably just try it, and see if it works
12:31:30 <sdague> do I'm actually confused on what - https://review.openstack.org/#/c/229040/14/specs/mitaka/approved/pause-vm-during-live-migration.rst,cm really is
12:31:36 <sdague> which is the other one that got approved
12:31:46 <johnthetubaguy> just to be clear, migrations will list: migrate calls, live-migrate calls, and resizes?
12:32:05 <alex_xu> yea, GET /servers/{id}/migration just for in-progress live-migration sounds like strange
12:32:14 <gmann__> yea list migrations list all type of migration for all the instances.
12:32:19 <PaulMurray> sdague, that one became the action live-migrate-force-end
12:32:20 <johnthetubaguy> sdague: its the force live-migrate to complete by pausing the VM, rather than cancelling the live-migrate
12:32:29 <johnthetubaguy> yeah, thats what it was called
12:32:31 <PaulMurray> sdague, it pauses a VM so it completes the migration quickly
12:32:43 <PaulMurray> sdague, but resumes it on completion
12:32:53 <sdague> live-migrate-force-end is massively confusing set of words
12:32:59 <sdague> how did that ever get approved
12:33:00 <johnthetubaguy> we totally need to have them both consistent, whatever we pick
12:33:11 <johnthetubaguy> sdague: it seemed less confusing that all the suggestions before it
12:33:23 <sdague> really?
12:33:25 <PaulMurray> sdague, the change of name was to indicate it should not be viewed as a pause
12:33:33 <paul-carlton1> so following the approach recommended by sdague  that would be a POST on /server/{id}/migration/{id}
12:33:48 <PaulMurray> sdague, it is an algorithm to speed up the migration that impacts the user
12:34:03 <PaulMurray> sdague, another that does not cause a pause could be introduced
12:34:22 <sdague> yeh, ok, I feel like that name is evacuate all over again
12:34:22 <PaulMurray> sdague, another algorithm that is
12:34:26 <paul-carlton1> The name is misleading, we are thinking of it as an action on a migration to expedite it
12:34:31 <sdague> we're going to be explaining what that is, forever
12:34:54 <PaulMurray> sdague, feel free to come up with a better one :)
12:35:05 <PaulMurray> sdague, its not set in stone just yet
12:35:14 <sdague> ok, well it got approved
12:35:34 <PaulMurray> sdague, do we need that one and the cancel to be consistent
12:35:44 <PaulMurray> in use of migrations or actions
12:36:05 <sdague> I feel like they should be consistent
12:36:12 <PaulMurray> me too
12:36:16 <johnthetubaguy> sdague: totally agreed they should be consistent
12:36:29 <PaulMurray> so we are looking at deciding how both should look
12:36:37 <PaulMurray> in the api
12:36:41 <johnthetubaguy> sdague: I would -2 any code review where they are not consistent, regardless of the spec
12:37:04 <sdague> johnthetubaguy: ok, well, maybe the problem is this is all ending up very soda straw
12:37:35 <sdague> there should have been a single spec with all the live migration API changes so they look whole
12:37:58 <PaulMurray> sdague, we can still consider doing an update to the first spec - lets do the right thing here
12:38:02 <sdague> yeh
12:38:20 <PaulMurray> sdague, I would rather get the migrations vs actions sorted and then make them consistent
12:38:22 <sdague> ok, so the resource model for cancel seems to me to be really natural REST
12:38:30 <sdague> because it's litterally DELETE that thing
12:39:02 <sdague> and whenever that is so natural, we should use it, or just give up and redo our interface as soap
12:40:06 <sdague> POST /server/{id}/migration/{id} - action {"complete-now"}
12:40:34 <alex_xu> why that is POST?
12:40:47 <sdague> "Do whatever is needed to most quickly complete the migration, this may mean turning off the live VM earlier than it would otherwise"
12:40:51 <paul-carlton1> some seem to want migrations and it to return a list?
12:41:39 <sdague> alex_xu: yeh, maybe it's a put with some attributes, I don't know. It does fee like we should hang it off migration subresource
12:41:57 <sdague> paul-carlton1: well, conceptually, all our resources have been collections
12:42:01 <paul-carlton1> in this case, yes but in the future we may add other POST operations on the /server.. migration to tweak it in other ways
12:42:08 <sdague> this is the first time one would not be
12:42:56 <paul-carlton1> I'll update the cancel spec accordingly and deal with Michalik comment too then we should be good to go!
12:43:06 <sdague> johnthetubaguy: are you ok with this?
12:43:31 <pkoniszewski> but why do we need to provide migration ID in API call? there can only be one on-going migration for particular VM
12:43:45 <alex_xu> do we want to implement cancel cold migration/evacuate in the future?
12:43:57 <paul-carlton1> we may do
12:44:00 <sdague> alex_xu: possibly
12:44:24 <sdague> pkoniszewski: because it's consistent, and that has an id
12:44:29 <johnthetubaguy> sdague: yes, using this as a first attempt of making our actions more REST like and task-ey, it makes sense I think
12:44:31 <alex_xu> sdague: ok, if we want to that, we can keep the sub-resource of servers
12:44:47 <gmann__> alex_xu: sdague can we have something like redo action for any migration of server, like live as of noe and evacuate, cold-migration later
12:44:49 <sdague> and because if that id is returned some other time, and you follow it back, you want to make sure you are interacting witht he same migration as before
12:45:44 <gmann__> may be REDO for any action on server ?
12:46:06 <sdague> ok, so who has the pen to write up how all of these become consistent ?
12:46:08 <alex_xu> emm....that another huge work
12:46:11 <sdague> paul-carlton1: is going to update his spec
12:46:19 <sdague> however there is the already approved spec
12:46:27 <gmann__> and keep implementing for actions as per need.
12:46:39 <pkoniszewski> i can update my spec (force-end) basing on paul-carlton1 update
12:46:44 <PaulMurray> pkoniszewski, wrote the first spec
12:47:03 <PaulMurray> cool pkoniszewski - thanks
12:47:04 <johnthetubaguy> sdague: +1 for the action being on the {id}, anything else would be fighting way too many conventions
12:47:22 <sdague> pkoniszewski: ok
12:47:31 <pkoniszewski> yes, race condition sounds like a good reason to operate on id
12:47:36 <paul-carlton1> thanks
12:48:17 <PaulMurray> maybe we should stick an agreement in the minutes?
12:48:32 <alex_xu> yea, the time is tight
12:48:32 <pkoniszewski> would be good to have this written down somewhere
12:48:48 <sdague> pkoniszewski: also, given that it's a separate actions namespace, how about "force-complete"
12:48:57 <sdague> end sounds too much like cancel
12:49:07 <sdague> that is going to confuse people a lot
12:49:14 <pkoniszewski> sdague: as far as I remember johnthetubaguy had some concerns with "force-complete"
12:49:23 <sdague> johnthetubaguy: what are those concerns?
12:49:23 <pkoniszewski> don't remember exactly what the point was
12:49:40 <sdague> we're going to regret the word "end" for years here
12:49:49 <pkoniszewski> personally I prefer "force-complete"
12:50:09 <alex_xu> +1 from me, sounds good
12:50:11 <johnthetubaguy> sdague: it wasn't from me the concern, it should be in the gerrit review, I think it was something about the errors
12:50:46 <johnthetubaguy> sdague: I prefer complete
12:51:02 <alex_xu> ok, do we have all the deal at here, we need move on, as we have next topic
12:51:04 <PaulMurray> I think it was that it might not complete, so coming to some kind of end ?
12:51:14 <PaulMurray> either complete or give up
12:51:21 <sdague> end means stop
12:51:26 <edleafe> I think 'complete' by itself implies that it won't finish otherwise
12:51:33 <PaulMurray> not in a 100m race
12:51:39 <paul-carlton1> what abut something like modify, so we can use it to do various actions relating to the migration but we can discuss this in migration sub team meeting later?
12:51:44 <edleafe> 'force-complete' seems clear
12:52:17 <johnthetubaguy> I am happy with force-complete, I would need to read through the gerrit comments to work out the previous issue
12:52:30 <sdague> PaulMurray: I think that the dialect differences is how we ended up with evacuate, and we've spent more time explaining misconceptions on that, then took to write the feature
12:52:31 <PaulMurray> johnthetubaguy, +!
12:52:47 <PaulMurray> +1 even
12:52:50 <sdague> :)
12:52:59 <sdague> I'm so going to +! from now on :)
12:53:02 <gmann__> or force_finish otherwise force_complete looks good
12:53:11 <pkoniszewski> the decision has been made there to use "force-end" instead of "force-complete" - https://review.openstack.org/#/c/229040/13/specs/mitaka/approved/pause-vm-during-live-migration.rst
12:53:18 <sdague> finish also means stop
12:53:23 <edleafe> +! == 'force-approve'
12:53:43 <sdague> these words need to not mean stop, otherwise people with think this is cancel
12:53:48 <johnthetubaguy> I think it was andrearosa who didn't like complete
12:53:52 <edleafe> sd +!
12:53:56 <edleafe> arrgh
12:53:56 <johnthetubaguy> trying to remember why now
12:53:59 <edleafe> sdague: +!
12:54:12 * edleafe needs coffee!
12:54:13 <PaulMurray> I think alex_xu said lets move on
12:54:22 <alex_xu> yea, 5 mins left
12:54:29 <paul-carlton1> if you use modify the body can contain a pause to pause the instance
12:54:30 <johnthetubaguy> so I think it was "we can't guarantee that the live migration finish"
12:54:31 <pkoniszewski> yes, we should move on, let's discuss it later on LM subteam meeting
12:54:32 <sdague> yeh, honestly, this was probably the most important thing to get nailed down
12:54:35 <johnthetubaguy> but I think we should ignore that
12:54:41 <sdague> johnthetubaguy: yeh, we should ignore that
12:54:47 <sdague> we don't guaruntee anything in the api
12:54:54 <alex_xu> another thing is about oslo-policy. which we mention in the irc last week, and suggestion add to meeting agenda
12:55:00 <johnthetubaguy> sdague: right, error happen, worry about the intent
12:55:04 <sdague> johnthetubaguy: right
12:55:23 <alex_xu> sdague: do you know what's going on for the discussion about oslo-policy in nove?
12:55:39 <sdague> alex_xu: nothing at this point
12:56:11 <alex_xu> so we keep use the old policy.py?
12:56:30 <sdague> is there something more specific that you are asking about?
12:56:47 <johnthetubaguy> this is more about, should we move to oslo.polcy, and what is stopping us
12:56:52 <alex_xu> #link https://review.openstack.org/#/c/198065/
12:56:54 <sdague> there were some grand discussions at summit, but nothing concrete has emerged as far as I know
12:56:57 <alex_xu> ^ and I saw this patch
12:57:36 <sdague> yeh, so, that's probably fine. I was hoping we'd get policy in code before doing that
12:57:45 <sdague> but that doesn't seem high on anyone's radar
12:57:55 <johnthetubaguy> well, we dropped it for docs right?
12:58:01 <alex_xu> yea, I remember those discussion
12:58:25 <sdague> we dropped it for not being able to get enough people to understand why it was important
12:58:40 <sdague> there was dramatic pushback from some quarters
12:58:51 <johnthetubaguy> sdague: true, thats more accurate
12:59:04 <sdague> so, that's fine, it's dropped, might as well synchronize here
12:59:32 <johnthetubaguy> true
12:59:44 * johnthetubaguy cries a little inside
12:59:48 <dims> sdague : "I'm happy to write specs here" :) http://markmail.org/message/objf6ht572b5fnza
13:00:12 <alex_xu> ok, it's time to close
13:00:17 <alex_xu> let's move to openstack-nova
13:00:18 <sdague> dims: yeh, then the whole thread was - "we hate this"
13:00:23 <dims> ack sdague
13:00:29 <sdague> so it didn't seem a good use of time
13:00:30 <alex_xu> thanks all, sorry have to end the meeting
13:00:37 <sdague> yep, thanks alex_xu
13:00:39 <gmann__> Thanks all
13:00:41 <alex_xu> #endmeeting