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