13:00:16 <alex_xu> #startmeeting nova api
13:00:17 <openstack> Meeting started Wed Mar 30 13:00:16 2016 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:21 <openstack> The meeting name has been set to 'nova_api'
13:00:30 <alex_xu> who is here today?
13:00:38 <cdent> o/
13:00:45 <sdague> o/
13:00:51 <tojuvone> Hi
13:01:50 <alex_xu> ok, today is quiet
13:02:00 <alex_xu> let's start the meeting
13:02:21 <alex_xu> #topic Nova Microversion testing in Tempest
13:02:31 <oomichi> hi
13:02:37 <alex_xu> gmann isn't here, but looks like good progress
13:02:55 <edleafe> o/
13:03:22 <alex_xu> i think we can skip this now, let's go next
13:03:36 <alex_xu> #topic API ref doc
13:03:36 * edleafe is split between meeting and phone
13:03:50 <alex_xu> sdague: I added topic at here, do you want to track the work from now?
13:03:58 <sdague> sure, that sounds like a good plan
13:03:59 <alex_xu> I see you begin to restack the patches
13:04:07 <sdague> here is where we stand
13:04:18 <sdague> the giant WIP stream is now a 2 patch series in nova
13:04:33 <sdague> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:wip_api_docs2
13:04:52 <sdague> the first patch is the infrastructure, which includes the sphinx extension
13:05:04 <sdague> the second patch is content for servers & versions
13:05:26 <sdague> the api-ref build publish jobs are now a thing
13:05:34 <sdague> so with https://review.openstack.org/#/c/298763/
13:05:46 <sdague> you can see the built api-ref - http://docs-draft.openstack.org/63/298763/4/check/gate-nova-api-ref/6983838//api-ref/build/html/
13:06:04 <alex_xu> so cool we already have job at here
13:06:11 <sdague> yes, that was done yesterday
13:06:25 <sdague> it doesn't publish anywhere on merge yet
13:06:34 <sdague> but we can see what the output will be
13:06:55 <alex_xu> sdague: cool, what is next plan?
13:07:14 <sdague> those 2 changes should probably get reviewed for real, and we should land something
13:07:39 <sdague> next up, auggy, annegentle, and karen are working on the wadl2rst converter
13:07:53 <sdague> so hopefully in a week or two we could bulk import most of the data
13:07:59 <alex_xu> maybe we should change the topic name, it make people it still in WIP
13:08:01 <sdague> then do fixups
13:08:24 <oomichi> sdague: after your patch, we will remove the content of nova api from api-site repo, right?
13:08:35 <alex_xu> sdague: cool, import the *.rst parameters.yaml, right?
13:08:50 <sdague> oomichi: after we get the entire thing working and publishing
13:09:01 <sdague> oomichi: I expect the cut over to be after Austin for sure
13:09:08 <oomichi> sdague: ok, I got the point
13:09:42 <sdague> I expect once we get the bulk import of data we're going to need to do a week long doc sprint to fix things that didn't convert properly
13:10:09 <alex_xu> ++
13:10:24 <johnthetubaguy> cool, thats looking awesome, so we have the framework and example up, so we can then add in the details afterwards
13:10:39 <sdague> johnthetubaguy: right, that was the attempt
13:10:47 <sdague> it demonstrates this as multiple rst files
13:10:56 <sdague> which is how I expect we'll manage it
13:11:00 <oomichi> yeah, nice steps for moving forward
13:11:39 <sdague> so, next steps, please review those so we can have the framework and initial data in tree
13:11:40 * edleafe applauds sdague
13:12:18 * alex_xu begin to review from tomorrow
13:12:18 <johnthetubaguy> is the plan to later extract the plugin to the docutils I guess?
13:12:35 <sdague> johnthetubaguy: yes, once we get all the formatting quirks sorted out
13:12:45 <johnthetubaguy> sdague: cool
13:13:03 <sdague> right now it's going to be easier to fix things if it stays in tree
13:13:25 <sdague> because once we extract it, we'll have to cut releases of the extension for it to be used by projects
13:13:42 <johnthetubaguy> yeah, sounds like totally the right call
13:13:54 <johnthetubaguy> I am thinking along similar lines for the feature classification matrix plugin
13:13:58 <sdague> my expectation is that we'll extract it during second milestone
13:15:08 <sdague> ok, I think that's about it on that front. We're making good progress.
13:15:28 <alex_xu> sdague: thanks for making this forward
13:15:51 <alex_xu> if no more question, we will move to next topic
13:16:11 <alex_xu> #topic open
13:16:28 <alex_xu> let's talk about newton works
13:16:44 <alex_xu> #link https://etherpad.openstack.org/p/newton-nova-api-ideas
13:17:24 <johnthetubaguy> it sounds like we have our work cut out with microversion docs and testing, once we have the above stuff in place?
13:17:28 <cdent> I have a gabbi-related spec for api testing that I'll add to the etherpad
13:18:28 <sdague> I think that after API docs, the top user features would be discoverable policy and structured errors
13:18:47 <sdague> which is the things I'd want to prioritize
13:19:01 <alex_xu> I also see something the summit ideas etherpad also
13:19:01 <alex_xu> #link https://etherpad.openstack.org/p/newton-nova-summit-ideas
13:19:01 <alex_xu> so...let go the api ideas etherpad first i think
13:19:01 <alex_xu> how about let us list out the thing we think about for newton?
13:19:06 <alex_xu> am i still online?
13:19:14 <sdague> alex_xu: yeh, it was just delayed for a minute
13:19:28 <alex_xu> ok...network delay
13:20:02 <alex_xu> sdague: yes, looks like discoverable policy on the top
13:20:04 <johnthetubaguy> sdague: +1 your points there around policy and errors being the big things
13:20:21 <sdague> I'll be honest, I'm not super excited about swapping out test infrastructures given the amount of churn that ends up being
13:20:36 <sdague> doing something in parallel might be fine to demonstrate
13:20:45 <johnthetubaguy> error wise, were we thinking about fixing up instance actions, or starting something more task-ey?
13:20:54 <cdent> yeah, my preference would not be to replace the api-samples, but to augment
13:21:12 <cdent> I've just added a link on the spec to somewhere I'm using it for tdd
13:21:34 <sdague> cdent: yeh, I think that's fine as a low priority background thing during the cycle. Though it does make another dsl people need to remember during reviews.
13:21:52 <sdague> johnthetubaguy: error wise, there is a spec from the api-wg about returning json structured errors
13:22:01 <sdague> instead of just http status code + free form text
13:22:12 <johnthetubaguy> ah, I was thinking more about async error stuff
13:22:28 <sdague> so we could actually tell people more specific things like "bare metal computes don't support live migrations"
13:22:36 <sdague> instead of 400
13:22:52 <tojuvone> That would be neat
13:23:13 <alex_xu> yes, like that
13:23:18 <sdague> it would also get us out of these odd binds about trying to put more meaning into http error codes than really exist
13:23:51 <sdague> and, we've actually found that in many of our tests we test for a condition which can be created by multiple kinds of failures, and we're actually passing for the wrong reasons
13:24:32 <sdague> https://github.com/openstack/api-wg/blob/master/guidelines/errors-example.json
13:24:38 <johnthetubaguy> yeah, thats all good stuff too
13:25:06 <sdague> my feeling is the way you'd implement this in Nova is to add error names out our extensions
13:25:06 <johnthetubaguy> I guess I was more worried about users telling if things like a snapshot had finished, and if it was a success or not
13:25:16 <cdent> fix the error message is only half the solution to that problem...
13:25:19 <sdague> johnthetubaguy: sure, that's also a concern
13:25:28 <johnthetubaguy> thats the whole task-ey thing
13:25:44 <johnthetubaguy> although being more precise about the errors seems like a good building block for all that
13:26:00 <sdague> johnthetubaguy: so, to be honest, I don't think we can do tasks until we get 3 core team members devoting the cycle to it
13:26:51 <sdague> cdent: sure, but it's also a big issue that there are times we want to communicate detailed reasons about why things are wrong, and we fail to
13:27:34 <sdague> I think laski has a spec up for discoverable policy
13:27:54 <alex_xu> #link https://review.openstack.org/290155
13:28:42 <johnthetubaguy> so I need to catch up with alaski as thats duplicating what I was trying with the cross project idea: https://review.openstack.org/#/c/298686
13:28:59 <johnthetubaguy> although I think we are starting to converge on concert proposals, so thats all good
13:29:40 <sdague> johnthetubaguy: I feel like most of the time cross project specs aren't all that useful until they are demonstrated in a project
13:29:55 <sdague> they get too abstract quickly
13:31:21 <johnthetubaguy> sdague: yeah, I agree really, I just did the cross project one first as I thought there was a completing direction that was gaining more traction
13:31:32 <sdague> johnthetubaguy: ok, no prob
13:31:51 <johnthetubaguy> anyways, totally don't think we should wait for cross project agreement, lets take one for the team, and try make policy work
13:32:54 <alex_xu> any more item, we care about in newton?
13:33:17 <johnthetubaguy> that sounds like a good pile of stuff to focus on
13:33:36 <sdague> policy currently has a spec
13:33:45 <sdague> api docs has a specless blueprint
13:34:03 <sdague> if structured errors is a thing, it probably needs a spec and an owner
13:34:03 <cdent> "has a spec" sounds vaguely like "has a posse"
13:34:07 <sdague> :)
13:34:18 <sdague> well, it has a spec and an owner in laski
13:34:42 <sdague> I want to make sure that if we are agreeing on priorities, the priorities all have a driver on them
13:34:44 <cdent> laski is a posse all by himself
13:34:52 <sdague> otherwise they will likely not happen
13:34:59 <sdague> cdent: ++
13:35:47 <johnthetubaguy> I am interested in helping with policy, but I don't think I can take on the error stuff
13:35:55 <sdague> should we take this conversation to the mailing list?
13:36:07 <johnthetubaguy> sdague: that sounds like a good idea
13:36:25 <sdague> maybe I can summarize a proposed set of priorities, some things we should do a low priority, and what sort of things we'd need to move forward on
13:36:33 <sdague> and we can have discussion there
13:37:23 <alex_xu> if structured errors is a thing and no one can help, I can help on it
13:37:26 <sdague> #action sdague to put mailing list post out discussing API priorities in mitaka
13:37:54 <alex_xu> sdague: cool, thanks
13:38:36 <alex_xu> anything we want to talk about in another etherpad?
13:39:03 <alex_xu> it's also about policy. one more thing is flavor extra spec
13:39:55 <sdague> (fyi, got to drop shortly for a bit, will catch up on additional conversation in logs)
13:40:29 <alex_xu> ok, if no more question on priority, let's move on
13:40:59 <alex_xu> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090687.html
13:41:13 <alex_xu> I have agenda, for a patch whether need microversion.
13:42:13 <alex_xu> 'delete_on_termination' always false in the swap volume api, and it behaviour as when it born
13:42:54 <johnthetubaguy> so after you call swap volume, it breaks delete_on_termination?
13:43:31 <alex_xu> johnthetubaguy: yes, delete_on_termination won't be keep, if we call it as 'break'
13:43:41 <johnthetubaguy> this sounds like a bug in swap_volume, and doesn't really need a microversion
13:43:59 <johnthetubaguy> so here is my thinking why...
13:44:28 <johnthetubaguy> if we added a new swap volume microversion, we would probably want all API versions to not hard code delete_on_termination anyways
13:44:53 <johnthetubaguy> so we may as well not add the microversion, unless we want to make it easy to discover a system that has this fix
13:45:48 <alex_xu> ok, if we think it is a break, i prefer just no microversion
13:46:59 <oomichi> then, we will need to backport it into stables also without microversion bumps
13:47:05 <oomichi> that seems good for me
13:48:16 <alex_xu> oomichi: backport to mitaka?
13:48:24 <johnthetubaguy> oomichi: yeah, good point, its something we could backport then
13:48:42 <oomichi> alex_xu: yeah, I think so if we consider it as a bug
13:49:02 <johnthetubaguy> so I often mess up these things, but it feels like a bug
13:49:12 <alex_xu> my concern it is old api, only backport to mitaka isn't enough, that is why i think we need a microversion
13:49:30 <oomichi> johnthetubaguy: yeah, we faced similar situation before without microversion bump
13:50:10 <oomichi> alex_xu: but the latest microversions are different between releases. impossible to bump microversion due to different  versioning
13:51:14 <alex_xu> oomichi: yes
13:51:39 <alex_xu> ok, if people think it is right way to go, i will remove the -2
13:51:51 <oomichi> we could have x.y.Z for this kind of thing
13:51:59 <oomichi> on version number
13:52:17 <oomichi> alex_xu: +1
13:53:03 <alex_xu> ok, let's move
13:53:08 <alex_xu> #link https://review.openstack.org/#/c/296995
13:53:17 <tojuvone> That's me
13:53:29 <alex_xu> tojuvone: yea, your turn
13:53:59 <tojuvone> so the have maintenance with time period set when it is
13:54:19 <tojuvone> and more
13:54:44 <alex_xu> tojuvone: the time period is just for a record? nova won't do anything based on the time period?
13:55:02 <tojuvone> as of sdague comment wanted also to have opinions about how much of this should land in Nova
13:55:49 <tojuvone> time period is at least important to owner of server. Telco use case he can prepare.. maybe there could be even oneflag more when host is really down
13:56:55 <tojuvone> Telco aplication is very keen on things effecting to server state and wants to know
13:57:11 <johnthetubaguy> advertising the expected maintenance window makes a lot of sense to me, but I think we should really look slightly wider at what the user needs to know
13:58:00 <johnthetubaguy> I think we have the host state working in a way that can tell users when the maintenance has started and finished, but we might need to re-think a few bits of that
13:58:01 <tojuvone> At least like when is the maintenance window palnned and when will the server be down becasue of it
13:58:24 <johnthetubaguy> tojuvone: can we get folks from the large operators group to review this spec?
13:58:30 <tojuvone> service enable/disable is only for not allow scheduling, right
13:58:58 <johnthetubaguy> tojuvone: yes, I think we need more than that, but its a start
13:59:25 <johnthetubaguy> for example, we want new builds to go to machines that have the maintenance complete, even if that was done before the expected window started, etc, etc
13:59:43 <johnthetubaguy> I think we need to sit back and look at the bigger picture a little, and see what work that generates
14:00:12 <tojuvone> yes, there is planty of more stuff.. also like what to do with servers
14:00:34 <tojuvone> they can stay on host, be removed or moved (migrate)
14:00:43 <alex_xu> oops, sorry guys, we run out of time
14:00:47 <vincentfrancoise> o/
14:00:50 <sballe_> o/
14:01:00 <alex_xu> #endmeeting