12:00:20 <alex_xu> #startmeeting nova api
12:00:21 <openstack> Meeting started Fri Jun 19 12:00:20 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:24 <openstack> The meeting name has been set to 'nova_api'
12:00:34 <alex_xu> Hello, who is here today?
12:00:42 <claudiub> o/
12:00:46 <bauwser> \o
12:01:21 <alex_xu> hello!
12:01:34 <alex_xu> only me is api team...
12:01:43 * bauwser will be basically lurking :-)
12:02:07 <claudiub> we trust your judgement. :)
12:02:18 <johnthetubaguy> o/
12:02:23 <johnthetubaguy> well I am just lurking really
12:02:38 <bauwser> alex_xu: ready for a monologue ?
12:03:00 <alex_xu> bauwser: ....do you want to listen?
12:03:18 <alex_xu> or cancel this week?
12:03:19 <bauwser> alex_xu: I do, I could even voice, but don't bet on it :)
12:03:25 <johnthetubaguy> so quick thing
12:03:26 <johnthetubaguy> https://review.openstack.org/#/c/173243/17/specs/liberty/approved/api-relax-validation.rst,cm
12:03:38 <johnthetubaguy> seems like there is agreement on that now, which is great
12:03:40 <alex_xu> +1 quick talk something
12:03:57 <alex_xu> yea, I already +1, I think it pretty close
12:03:59 <johnthetubaguy> I am curious how many other specs are pedning
12:04:03 <johnthetubaguy> pending^
12:04:05 <sdague> o/
12:04:16 <alex_xu> I will happy to help on the implementation
12:04:21 <johnthetubaguy> pending for priority stuff I mean, rather than just APIImpact stuff
12:04:31 <sdague> alex_xu: can you take the lead on that implementation?
12:04:39 <johnthetubaguy> alex_xu: awesome thank you, not sure how much code typing time will get left for me
12:04:41 <alex_xu> sdague: sure
12:04:53 <alex_xu> johnthetubaguy: yea, I see :)
12:04:54 <sdague> alex_xu: great, thank you
12:05:00 <alex_xu> sdague: np
12:05:05 <johnthetubaguy> sdague: alex_xu: +1 don't let my name being on there block you doing all the work, if thats the best way forward!
12:05:09 <bauwser> some details have been removed from the spec, which I'm fine - but I'd love to review that
12:05:24 <sdague> alex_xu: I'll actively review those patches, please ping me as soon as you have anything up
12:05:31 <sdague> I'd like to get that in sooner rather than later
12:05:33 <alex_xu> sdague: got it
12:05:34 <bauwser> sdague: the spec deserves a +2 :)
12:05:43 <johnthetubaguy> +1 in terms of reviewing that spec
12:05:51 <johnthetubaguy> (and trying to get it deployed...!)
12:06:03 <sdague> bauwser: I don't have +2 on specs :)
12:06:16 <bauwser> oh my bad then, was thinking you were nova-drivers
12:06:38 <sdague> as soon as I get done writing up some new devstack plugin docs, I'll be reviewing specs this morning
12:07:01 <alex_xu> so api team member can +1 for it, then put it on https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
12:07:21 <bauwser> alex_xu: well, I think it's reasonable to put it already
12:08:00 <alex_xu> bauwser: sounds good for me
12:08:06 <bauwser> gilliard and you already +1'd it
12:08:06 <johnthetubaguy> (so I regret not pushing on the nova-core all get +2 thing, its been too slow without it, will probably change that soon-ish after the freeze for the backlog stuff, but lets not get distracted by that...)
12:08:27 <johnthetubaguy> alex_xu: so we can put it on that list before too
12:08:31 <bauwser> oomichi as well, btw.
12:08:34 <bauwser> johnthetubaguy: did that
12:08:37 <bauwser> just now
12:09:01 <johnthetubaguy> alex_xu: yeah, lets get a list of all the specs this teams would like to be merged, regardless of their current state
12:09:02 <alex_xu> bauwser: yea, oomichi give -1 for previous version, better to have him +1
12:09:13 <johnthetubaguy> that was I can get them some higher priority
12:09:17 <johnthetubaguy> that way^
12:09:24 <alex_xu> johnthetubaguy: ok
12:09:59 <alex_xu> #link https://review.openstack.org/188410
12:10:02 <johnthetubaguy> oomichi spotted a big omision, around omitting headers for v2 rather than v2.1 so I was really glad of that -1
12:10:29 <alex_xu> johnthetubaguy: yea
12:10:47 <alex_xu> more question for relax validation? then we move on
12:10:57 <johnthetubaguy> I am good for relax stuff
12:11:00 <sdague> I think we can move on
12:11:05 <johnthetubaguy> thanks for all the great feedback on that
12:11:06 <bauwser> +1
12:11:11 <alex_xu> #link https://review.openstack.org/188410
12:11:20 <alex_xu> the microversion client spec
12:11:46 <alex_xu> I have no more words...except review, thanks to sdague already give a lot feedback
12:12:22 <alex_xu> oops, one question from me
12:12:24 <johnthetubaguy> I need to give this some quality time, I like how its based on the ironic spec
12:13:00 <sdague> well, honestly, I find the ironic spec boiler plate mostly distracting
12:13:07 <alex_xu> whether we need depend api-guidelien https://review.openstack.org/187112 it add something like return max/min when request invalid version?
12:13:07 <sdague> because we mostly have all that
12:14:09 <alex_xu> sdague: our spec is a little different with ironic one, I compare few use-case, some words are changed....so we need notice that
12:14:13 <sdague> but I think my major issues were all addressed with L266 - L276
12:14:17 <johnthetubaguy> sdague: true, its got too big right now, the problem description could be trimmed, for example
12:14:52 <bauwser> +1 was about to mention that
12:15:05 <sdague> alex_xu: so, the problem is, no one is ever going to really notice that. I feel like that should be done as an appendix section, that also describes what the differences from ironic are at this point
12:15:09 <bauwser> does it need to be reviewed now, that said ?
12:15:16 <sdague> because building a mental diff here is weird
12:15:16 <bauwser> I mean, during the meeting ?
12:15:25 <johnthetubaguy> sdague: +1
12:15:29 <sdague> and it wasn't the major concern of the spec
12:15:59 <alex_xu> sdague: yea, it hard diff by my eye
12:16:24 <sdague> bauwser: well, now is a time for questions
12:16:25 <johnthetubaguy> I am torn, I like it being stand alone in nova, but the differences are important, I think the later is probably more important
12:16:47 <bauwser> sdague: fair, was an open question, sorry if you sounded it harsh
12:17:47 <sdague> ok, honestly, now that we sorted out the cli default behavior, I think this is in fine shape to move forward. Details can be tweaked in the code reviews if something looks weird, but the crux of API requires explicit microversion, and CLI uses latest is good
12:18:30 <johnthetubaguy> +1 for that distinction
12:18:37 <alex_xu> sdague: +1
12:18:53 <johnthetubaguy> I guess the API user can explicitly request "latest" right?
12:19:28 <sdague> johnthetubaguy: yeh, it's allowed, I'm still iffy on whether that's a good idea or not
12:19:32 <alex_xu> johnthetubaguy: yes
12:19:44 <sdague> but it's pretty minor really
12:20:17 <johnthetubaguy> so that all seems like a good starting point to me
12:21:30 <alex_xu> emm...ask my question again, whether we need depend api-guidelien https://review.openstack.org/187112 it add something like return max/min when request invalid version?
12:21:47 <alex_xu> I'm thing the client implement may depend on this.
12:22:11 <alex_xu> if the client implement on this, we need some server side coding also
12:22:36 <sdague> alex_xu: honestly, I think we should just push forward for now, the api-wg general guidelines are emerging, and until we try some things we won't have the data to know if that's working or not
12:22:53 <sdague> the point of microversions was we could fix any mistakes later with new microversions
12:23:03 <sdague> so not spend forever being unsure
12:23:10 <claudiub> well, there are a couple concerns with exposing the api versions... some servers prefer to hide the server version
12:23:20 <claudiub> maybe have it as a config option?
12:23:36 <sdague> claudiub: nope
12:23:50 <johnthetubaguy> we are explicitly not allowing that sort of thing
12:23:53 <sdague> this is part of the API contract
12:23:59 <sdague> if you don't expose it, you aren't Nova
12:24:01 <johnthetubaguy> sdague: +1
12:24:05 <andreykurilin> while we are here: Should we switch to use OpenStack-API-Version header instead of X-OpenStack-Nova-API-Version ? http://lists.openstack.org/pipermail/openstack-dev/2015-June/066986.html
12:24:25 <johnthetubaguy> claudiub: I know there are people who worry from a security point of view, but we need it for other reasons
12:24:33 <sdague> andreykurilin: honestly, I think that discussion is still very much in flux, I think no action is needed at this point yet
12:24:59 <claudiub> k, cool.
12:25:03 <sdague> to be clear, we're not exposing the git hash of your server, we're exposing the API versions
12:25:07 <alex_xu> sdague: so now the cli implement only depend on what we have?
12:25:16 <andreykurilin> sdague: got it
12:25:17 <sdague> alex_xu: yeh, I think for now, it's fine
12:25:30 <johnthetubaguy> so we have APIs that need a client, so we have to make it work with what we have
12:25:55 <alex_xu> ok, got it
12:25:58 <sdague> andreykurilin: I feel like something like  http://lists.openstack.org/pipermail/openstack-dev/2015-June/066986.html should go through api-wg ratification first, then we fix it in M
12:26:53 <alex_xu> sdague: emm...the microverions itself not under the protect of microversions
12:27:05 <alex_xu> so we need keep any change to microversion is back-compatible
12:27:18 <alex_xu> that is one thing we should care about I think
12:27:34 <sdague> right, so changing a header like that means we're going to have to have a deprecation and overlap phase
12:27:46 <sdague> which is another reason I don't want to rush it
12:28:17 <sdague> because it's an invasive enough change, for really unclear gains. Like CamelCase changes.
12:28:19 <alex_xu> sdague: ok, deprecation is a way
12:28:26 <johnthetubaguy> we would need a transition and discoverability discussion, etc, and thats cool, but its not for now
12:29:07 <alex_xu> ok, I see now
12:29:23 <alex_xu> any more question for microversions?
12:29:41 <alex_xu> ok, let move on
12:29:44 <alex_xu> #link http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/nova-api-remove-v3.html
12:29:57 <alex_xu> thanks edleafe and his team, they already begin to work on
12:30:13 <alex_xu> I think this is good progress
12:30:39 <alex_xu> I guess no more question for this?
12:31:03 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z
12:31:20 <sdague> alex_xu: on the rm v3 bits, is there a patch stream?
12:31:52 <alex_xu> sdague: not yet, edleafe's team working on the plan, edleafe lead some opentack new man
12:31:59 <sdague> ok, cool
12:32:26 <sdague> alex_xu: I look forward to that a lot
12:32:34 <alex_xu> policy stuff is also good. we merged some patches in this two weeks.
12:32:52 <sdague> I'll go through the policy patches as soon as the meeting is over
12:32:59 <alex_xu> sdague: thanks
12:33:20 <alex_xu> #link https://review.openstack.org/191188
12:33:43 <alex_xu> sdague start local bump guideline, it is pretty cool
12:34:02 <sdague> yeh, I need to make another revision of that, I now understand what jaypipes was getting at, which I missed in the first review
12:34:04 <alex_xu> and there are come out a lot of patch want to validate it~
12:34:49 <alex_xu> sdague: cool, without I'm begin to afarid review api patch :)
12:35:00 <sdague> right, I was trying to reference decisions we've made previously
12:35:56 <alex_xu> sdague: the two step fix for 500, sounds interesting idea, except it is a little strange for fix 500 to wrong code in backport
12:36:35 <johnthetubaguy> do we have a similar doc for the policy defaults in code, renaming to match the URL rather than the code, and that kind of thing?
12:36:49 <alex_xu> sdague: I'm think if there are some fix needn't new microversion, then this fix must be back-portable
12:36:52 <johnthetubaguy> oh backports, did we wonder about leaving a few version numbers empty for backports?
12:37:03 <sdague> johnthetubaguy: that's not really going to work
12:37:18 <bauwser> so, why not x.y.z like objects ?
12:37:31 <johnthetubaguy> sdague: so true, we end up changing new version we released already
12:37:39 <sdague> johnthetubaguy: right, exactly
12:37:45 <alex_xu> we need new plan for policy~
12:37:48 <johnthetubaguy> sdague: I remember going that before now
12:38:40 <sdague> alex_xu: yeh, so, honestly, the policy question is a really good one, and is kind of wrapped up with where keystone wants to take policy, which hasn't all been sorted yet
12:38:56 <alex_xu> johnthetubaguy: if there is change bump rpc version, then we can't back-port it also? I think this is similar to microversion
12:39:42 <sdague> so, honestly, I just think a class of bugs that expose to the API are just "to get the fix, upgrade"
12:39:47 <alex_xu> sdague: johnthetubaguy does this one still is we want https://review.openstack.org/179685?
12:40:01 <bauwser> alex_xu: that's forbidden https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy
12:40:43 <alex_xu> bauwser: thanks
12:41:00 <bauwser> that said, some tooling is done for the objects, like I said
12:41:13 <sdague> alex_xu: on the policy front, I feel like we don't want any smaller changes to policy until we have the big picture on the dynamic policy end game
12:41:13 <bauwser> you can provide a .z version
12:41:50 <alex_xu> sdague: ok, so stop continue push that
12:42:15 <sdague> bauwser: the .z thing doesn't really work right here, because now someone writes their code to 2.4.5
12:42:17 <alex_xu> bauwser: I remember we have .z version propose before, but finally we remove that
12:42:25 <sdague> and their cloud updates to master
12:42:31 <sdague> and 2.4.5 goes away
12:42:33 <johnthetubaguy> so my take is we should work out what we would like in an ideal world, and get that written down, then start thinking about how we get there (implementation)
12:42:50 <bauwser> sdague: I need more time for thinking about that, but I got your point
12:43:07 <johnthetubaguy> my last comment was about policy, specifically
12:43:15 <bauwser> anyway, it was not possible *before* the microversions, so that's not that harsh
12:43:17 <sdague> johnthetubaguy: yeh, on policy, I agree.
12:43:25 <sdague> bauwser: right, it's not really a change
12:43:34 <sdague> it's just a bit more enforced in code now
12:43:43 <alex_xu> johnthetubaguy: got it
12:43:48 <bauwser> I guess that's something to be discussed at the API WG level
12:43:57 <bauwser> (talking about the stable backports)
12:45:04 <johnthetubaguy> bauwser: its a non starter for micro version bumps, but it should be discussed there
12:45:21 <sdague> honestly, making it easier to roll forward and just pick up changes should be the goal. If we get that to be seamless, it's a much better answer.
12:45:34 <bauwser> +1
12:45:43 <johnthetubaguy> sdague: you mean get more folks deploying off master?
12:45:48 <sdague> johnthetubaguy: yes
12:46:22 <johnthetubaguy> sdague: I so wish a distros would start pushing that way, and see how it works in that form
12:46:23 * alex_xu lose context, need re-read that part after meeting
12:46:40 <sdague> johnthetubaguy: fortunately the new ansible openstack effort is all about that
12:46:54 <sdague> so that will help move the needle I hope
12:47:01 <johnthetubaguy> sdague: interesting, hadn't spotted that one
12:47:20 <sdague> yeh, it's deploy from git, not from packages like the puppet effort
12:47:26 <johnthetubaguy> sdague: I should get our ansible folks that are doing just that already to try and join in with that
12:48:42 <johnthetubaguy> so we don't do from git, but anyways, interesting stuff
12:48:44 <sdague> ok, any other topics?
12:48:56 <johnthetubaguy> +1 back to API, anything else burning
12:49:02 <alex_xu> #link https://review.openstack.org/187112
12:49:07 <alex_xu> quick update from me
12:49:31 <alex_xu> talk with ironic guys, they don't expermiental also
12:49:47 <alex_xu> back to neutron guys, they are going to give it also~
12:50:04 <alex_xu> so~ yea, avoid another long argument
12:50:09 <sdague> cool
12:50:35 <sdague> related, johnthetubaguy do we have whatever official spec / devref in that says extensions go away?
12:50:43 <sdague> is that on your plate/
12:50:44 <sdague> ?
12:51:00 <johnthetubaguy> sdague: we don't, it is on my radar though (in the summit follow up list, I think)
12:51:06 <alex_xu> sdague: https://review.openstack.org/162912
12:51:14 <alex_xu> johnthetubaguy: ^
12:51:20 <johnthetubaguy> ah, cools
12:51:27 <alex_xu> and got jay's +2
12:51:41 <sdague> ok, great, will look
12:51:43 <sdague> thanks alex_xu
12:51:47 <alex_xu> np
12:51:51 <alex_xu> and one message from me
12:52:22 <alex_xu> I will take leave few days next week. because my baby will born.
12:52:37 <claudiub> congrats. :)
12:52:39 <gilliard> congrats!
12:52:39 <sdague> alex_xu: congrats!
12:52:40 <alex_xu> and my work may have a little slow down, sorry for that
12:52:46 <alex_xu> thanks all :)
12:52:56 <sdague> heh, yep, I know that :) It's a great adventure.
12:53:15 * alex_xu actually already slow down after summit, because spend some time between hospital and home and office
12:53:23 <johnthetubaguy> alex_xu: awesome, good luck!
12:53:30 <alex_xu> johnthetubaguy: thanks
12:53:59 <alex_xu> and no more from me, any more question?
12:54:17 <sdague> not from me, thanks everyone
12:54:17 * johnthetubaguy wonders if openstack should have run a new parent support group!
12:54:28 <johnthetubaguy> looks good from me
12:54:30 <alex_xu> jacorob: hah
12:54:35 <sdague> there have been a lot of #stackbabbies
12:54:51 * alex_xu have no idea what happened after have baby
12:55:05 <gilliard> You're about to find out!
12:55:14 <alex_xu> let us end the meeting :)
12:55:16 <alex_xu> gilliard: yea
12:55:20 <alex_xu> #endmeeting