13:00:22 <alex_xu> #startmeeting nova api
13:00:24 <openstack> Meeting started Wed May  4 13:00:22 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:28 <openstack> The meeting name has been set to 'nova_api'
13:00:32 <alex_xu> who is here today?
13:01:24 <oomichi_> hi
13:01:39 <jichen> o/
13:01:41 <johnthetubaguy> o/
13:02:21 <cdent> o/
13:02:26 <alex_xu> i guess people still in jetlag
13:03:02 <alex_xu> #topic API Priorities
13:03:13 <sfinucan> o/
13:04:17 <alex_xu> let say remove legacy v2 API first?
13:04:41 <oomichi_> +1 :-)
13:04:54 <jichen> +1
13:05:12 <alex_xu> oomichi_: and i already sent out some patches
13:05:15 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/remove-legacy-v2-api-code
13:05:57 <oomichi_> not only nova, but also devstack
13:06:08 <oomichi_> https://review.openstack.org/#/q/status:open+project:openstack/topic:bp/remove-legacy-v2-api-code
13:06:12 <alex_xu> is there any order people concerned? I'm think of removing the api-paste.ini entry first, that stop user using the legacy v2 api first. Then we remove legacy v2 code piece by piece
13:06:44 <alex_xu> oomichi_: ah, cool, also the merged one, the legacy v2 gate job, thanks for that :)
13:07:16 <oomichi_> alex_xu: yeah, we can remove api-paste.ini now
13:07:20 <sdague> alex_xu: I left a comment on your patch removing the paste bits
13:07:25 <johnthetubaguy> honestly, as long as we get it done quickly, the order isn't too important
13:07:36 <johnthetubaguy> yeah, +1 sdague's comment on that patch
13:07:37 <sdague> I'd like to have a unit test to understand what the user sees if they forgot to update paste.ini
13:08:11 <sdague> I also updated the api dashboard to look for this blueprint - https://review.openstack.org/#/c/312475/
13:08:17 <alex_xu> sdague: yea, good point on that patch, I think I should add log in pipeline_facotry method instead of removing the pipeline_factory directly.
13:08:47 <sdague> alex_xu: yeh, maybe, as long as we understand what the behavior is, and it's something that the admin will understand and be able to fix
13:09:02 <sdague> the ec2 remove from enabled_apis was a little rougher than we would have liked
13:09:48 <alex_xu> sdague: ok, got it, i will update the patch.
13:10:18 <alex_xu> I think we should remove paste entry before breaking the legacy v2 api code
13:10:58 <alex_xu> after that we can free to remove legacy v2 api code, just ensure the tests passed.
13:11:07 <sdague> yep
13:11:19 <johnthetubaguy> I think we have to, it sounds sensible
13:11:40 <alex_xu> after legacy v2 code removed, there can be some cleanup in the wsgi stack.
13:11:47 <sdague> getting the paste entry removed, and the failure if it's still there sensible seems like the primary step. After that we can just delete a bunch of stuff.
13:12:20 <alex_xu> one more question, what kind of test we expected on v2.1 compat mode?
13:13:19 <oomichi_> alex_xu: meaning additionalProperties:True mode?
13:13:28 <johnthetubaguy> are we not OK with all the existing testing?
13:13:45 <sdague> I think the existing testing is probably fine
13:14:09 <alex_xu> the api sample test still run with v2.1 compat mode, the nova/tests/functional/test_servers run under compat mode, and other functional test is not.
13:14:12 <alex_xu> oomichi_: yup
13:14:37 <sdague> we've got functional testing for the APIs in tree with the samples, the only differences between it and the v2.1 code should be in that layer
13:14:54 <sdague> I'm sure there are ways to enhance it further, but it's been fine up until this point
13:14:55 <johnthetubaguy> are we also removing the extensions config for v2.1, maybe I am getting ahead of the list now?
13:15:12 <sdague> johnthetubaguy: I think we decided that's a spec
13:15:21 <sdague> for communication as much as anything else
13:15:26 <johnthetubaguy> sdague: gotcha
13:15:55 <johnthetubaguy> I remember that conversation now... vaguely
13:16:03 <alex_xu> ok, that is another question, but i got clearly now
13:16:11 <sdague> https://etherpad.openstack.org/p/newton-nova-api L96
13:16:37 <johnthetubaguy> in my head that change affects the samples testing, hence the quick check
13:16:55 * mriedem joins late
13:17:28 <alex_xu> yes, probably need gmann's sample test merging work first
13:18:18 <alex_xu> who is going to write that spec?
13:18:51 <johnthetubaguy> if I don't write it, I can help +2 it
13:19:04 <alex_xu> if no-one, let me help it.
13:19:11 <sdague> I might get to it, but it will be a couple of weeks, because we really do need to stay focussed on api-ref and policy
13:19:56 <alex_xu> ok, looks like api-ref and policy is more priority than that
13:21:11 <alex_xu> so let me try first.
13:21:12 <johnthetubaguy> sounds like the correct call
13:21:32 <alex_xu> so looks like cool at here. let's move on
13:21:50 <alex_xu> api policy discovery
13:22:05 <alex_xu> #link https://review.openstack.org/#/c/290155/
13:22:17 <alex_xu> we said only need this one in newton?
13:22:53 <mriedem> looks like alaski and dhellmann need to sort that one out
13:23:00 <mriedem> otherwise i was more or less ok with it
13:23:10 <sdague> yeh, we should just keep on top of it, I think I need to take one more pass on it
13:23:23 <johnthetubaguy> likewise, I like the way its going, just nits
13:23:36 <mriedem> i'm not sure if dhellmann is asking that we bake a bunch of new stuff into an oslo lib
13:23:42 <alex_xu> still implement in nova first, not oslo?
13:23:44 <mriedem> because it would be easier for nova to do this thing first and split it out later
13:24:09 <alex_xu> ok, got it
13:24:22 <sdague> ok, probably a todo to sort out where that one stands
13:24:28 <sdague> to make sure we get to approval soon
13:24:41 <mriedem> it needs a rev anyway
13:25:04 <mriedem> but it would be good to have an agreement between alaski and dhellmann
13:25:08 <sdague> https://review.openstack.org/#/c/289405/6/specs/newton/approved/discoverable-policy-api.rst is a bit more problematic. I think we decided on a very different approach during the session, but I'm not sure that claudio_ was there
13:25:34 <johnthetubaguy> ah, yes, the nova-manage command idea
13:25:46 <sdague> right
13:25:57 * mriedem doesn't remember exactly
13:26:00 <sdague> I can provide that group feedback into the spec today
13:26:02 <mriedem> hopefully the notes are in https://etherpad.openstack.org/p/newton-nova-api
13:26:22 <sdague> https://etherpad.openstack.org/p/newton-nova-api L28-L41
13:26:44 <mriedem> yeah
13:26:45 <sdague> L35 is the most relevant
13:26:47 <mriedem> new policy language
13:26:50 <alex_xu> at line 35
13:26:51 <sdague> Decision: no, not in Newton. Build the infra and be able to see it in nova-manage.
13:26:52 <mriedem> build it into nova-manage
13:26:56 <mriedem> yup
13:26:56 <sdague> Decision: don't munge this with capabilities, this is a permission check. +1
13:27:15 <mriedem> i would have gotten there eventually :) i need to write the recap for the api session today
13:27:34 <sdague> :)
13:27:52 <sdague> #action sdague to provide session feedback to https://review.openstack.org/#/c/289405 spec
13:28:13 <cdent> sdague, awesome, because I'm struggling to parse the etherpad
13:28:19 <johnthetubaguy> quick question...
13:28:22 <alex_xu> sdague: cool, thanks
13:28:41 <johnthetubaguy> actually is dumb question, ignore me, was thinking about whats needed to unblock live-reize
13:28:51 <johnthetubaguy> this is a dependency, but its not the end of the road, thats all
13:28:58 <sdague> johnthetubaguy: right, we said, previously, it was discoverable capabilities
13:29:12 <sdague> which this is all ground work for
13:29:22 <johnthetubaguy> yeah, +1
13:29:31 <johnthetubaguy> you could expose that via permissions, but thats messy
13:29:40 <sdague> we specifically said we wouldn't do that
13:30:04 <sdague> Decision: don't munge this with capabilities, this is a permission check. +1
13:30:09 <sdague> L36
13:30:19 <johnthetubaguy> right, I was meaning deployers might change permissions due to known capabilities, but yeah, its not an assumption we want in the API
13:30:23 <alex_xu> i still confuse on the policy discovery and capabilities discovery. I found we always talk about them together, but I thought they are diffrent things.
13:30:31 <sdague> alex_xu: they are
13:30:48 <johnthetubaguy> does it work vs can i do it
13:31:10 <sdague> but capabilities are hard to do without the policy being fully known in advance (which it is not)
13:31:22 <alex_xu> ok, cool, looks like i'm same page with people
13:31:30 <johnthetubaguy> +1, this is a needed stop on that journey
13:31:40 <sdague> because the two intersect in some cases, where the cloud can in theory do X, but the admin wants to prevent it
13:31:58 <johnthetubaguy> I think claudio_ was hoping this spec would un block his live-resize, hence my query
13:32:02 <johnthetubaguy> just a heads up there
13:32:05 <sdague> so it makes no sense to expose can:live-resize to the user, they try, then get a 403
13:32:07 <alex_xu> ah, i got it now, sdague thanks
13:32:15 <johnthetubaguy> sdague: agreed
13:32:34 <sdague> or, it can make sense, but it's mostly very frustrating
13:33:02 <johnthetubaguy> ack, both for the deployer and the user
13:33:07 <sdague> so if we fix permissions being fully explicit, then we can address the rest of it on top of that
13:33:46 <cdent> I assume throughout this people being conscious of the fact that any one human operating a user-agent may have multiple identities with the service
13:33:57 <cdent> so they need to be able to know "if you change who you are you might be able to do this"
13:34:02 <alex_xu> after we have policy discovery, that is kind of thing instead of extension?
13:34:18 <johnthetubaguy> cdent: we were generally talking per token, I think
13:34:41 <sdague> cdent: right, per token, which is really per tenant in the policy conversation
13:35:31 <cdent> cool, just checkin'
13:35:32 <sdague> alex_xu: more or less, but that's all next cycle
13:36:22 <alex_xu> sdague: ok, want to know how people think about that, as we said no extension. but there is something make people can do something
13:36:29 <alex_xu> s/something/same thing/
13:36:45 <alex_xu> so we can move on?
13:36:51 <sdague> alex_xu: yeh
13:37:02 <alex_xu> Let's talk about api ref
13:37:08 <alex_xu> sdague: what is next plan
13:37:21 <sdague> well, first off, a bunch of open patches out there - https://review.openstack.org/#/q/file:api-ref+project:openstack/nova+status:open
13:37:43 <sdague> jichen is doing a bunch of great work here, very thankful of that
13:37:49 <sdague> we need more folks diving in though
13:37:54 <alex_xu> jichen: thanks!
13:38:08 <jichen> alex_xu: sdague :  :)
13:38:26 <sdague> next Mon & Wed we'll do some doc sprints to try to push through as much as possible
13:38:48 <mriedem> #link api-ref review sprint dev thread http://lists.openstack.org/pipermail/openstack-dev/2016-May/093844.html
13:38:55 <sdague> I've got some todos once we get the content close about microversions, and changing the way we represent urls
13:39:30 <sdague> How about I follow up to mriedem's post with the details there so people can see the longer term steps here
13:39:55 <alex_xu> +1
13:39:57 <mriedem> maybe separate thread if it's not about reviews?
13:40:10 <mriedem> i'd only follow up with review tips to my thread
13:40:16 <sdague> mriedem: sure, sounds good
13:40:19 <mriedem> this is what to expect, this is what to chec, etc
13:40:21 <mriedem> *check
13:40:36 <sdague> I'll follow up on your thread with that, I'll wait until post sprint to evaluate and say next steps
13:41:06 <sdague> I'll probably write something today to assess how many outstanding items we've got in our checklist
13:41:35 <sdague> I updated the nova-api dashboard to put API ref at the top
13:41:53 <sdague> to try to score everything there first, as it should be easy
13:43:08 <sdague> any other questions there?
13:43:22 <alex_xu> nothing fro me
13:43:27 <alex_xu> s/fro/from/
13:43:32 <mriedem> link to the dashboard?
13:43:35 <mriedem> or is that in a wiki somewhere?
13:43:38 <mriedem> or etherpad
13:45:18 <sdague> mriedem: it's just in the repo, I can add it to the wiki
13:45:29 <mriedem> mikal thanks you already
13:45:43 <sdague> or figure out a way to get these dashboards on stable urls
13:46:20 <mriedem> there is 14 minutes left with a few more items, so let's move on
13:46:32 <alex_xu> ok
13:46:33 <alex_xu> Deprecated API Proxy
13:46:50 <alex_xu> #link https://review.openstack.org/#/c/312209/
13:46:59 <mriedem> i plan to review that soon
13:47:06 <mriedem> we have notes in the session etherpad
13:47:41 <sdague> yeh, I think that mostly matches the session
13:47:58 <alex_xu> ok, only thing need is review
13:48:28 <alex_xu> if no more question, then move on?
13:48:32 <sdague> yep
13:48:39 <alex_xu> #topic Open
13:48:53 <alex_xu> cdent: you have items for open I think
13:49:09 <cdent> yeah, I am after eyes and feedback on https://review.openstack.org/#/c/305800/ and https://review.openstack.org/#/c/300077/
13:49:22 <mriedem> did you guys already go over the legacy v2 api removal?
13:49:28 <cdent> the main concern is how best to document the change and ensure that it is kosher
13:49:31 <cdent> mriedem: that was first
13:49:37 <mriedem> d'oh!
13:49:37 <alex_xu> mriedem: yea, in the beginning of the meeting
13:49:38 <mriedem> ok
13:50:13 <sdague> I have on my todo list a few more specs to write up: deprecating some unused, unusable REST APIs; remove of bookmark links; update for the flavor by server spec;
13:50:22 <cdent> I know that the microversion change isn't a priority, but it is a) basically done b) pretty lightweight, so may as well push it along if people have some spare cycles
13:50:59 <cdent> my implementation is probably a bit incomplete, due to my inexperience with nova api changes, so feedback will make things happen
13:51:10 <sdague> cdent: yeh, I'll put the spec up for review. I think it's mostly going to be about a usage section in api-ref on microversions
13:51:21 <sdague> starred that spec to look later
13:51:25 <cdent> thanks
13:52:02 <alex_xu> ah, good point, probably a lot of microversion doc need update
13:52:14 <sdague> https://review.openstack.org/#/c/311529/ is the metadata casing proposed fix
13:52:45 <sdague> which was talked about late on friday, and mriedem did a good job pointing out the bits I messed up in draft 1
13:52:51 <sdague> draft 2 should be a lot more explicit
13:53:19 <sdague> http://docs-draft.openstack.org/29/311529/3/check/gate-nova-specs-docs/7f935cf//doc/build/html/specs/newton/approved/lowercase-metadata-keys.html
13:53:57 * mriedem frames that on the wall
13:54:13 <alex_xu> cool, another fix for mess stuff
13:55:37 <cdent> oh, before I forget, mriedem had said something about wanting it to be easier to explore what gabbi is, so I made this: https://gist.github.com/cdent/d70015ac6fffbbd3cd80a771e197bf36
13:55:37 <alex_xu> if no more question, I probably go to end the meeting early?
13:55:51 <cdent> it's a shell script that automatically starts up and automatic demo
13:55:56 <cdent> s/and/an/
13:56:04 <cdent> in case anyone is interested or curious
13:56:25 <alex_xu> cdent: cool
13:56:26 <sdague> cool
13:56:40 <sdague> cdent: oh, last thing, I looked at the resource pools API spec this morning
13:56:51 <sdague> and I wonder if now is the time to split the CLI as well
13:56:56 <cdent> it only covers the very basics, mostly of the syntax, not of how to integrate with testing harness and fixtures
13:57:00 <sdague> so we don't have to do that late in the game
13:57:02 <cdent> sdague: yeah I read that
13:57:08 <cdent> I think you're probably right
13:57:09 <sdague> and take a bunch of novaclient gorp with it
13:57:34 <cdent> I haven't even begun to think that about the cli yet...
13:57:40 <cdent> s/that//
13:57:52 <mriedem> split the cli as in for the new placement api?
13:58:00 <sdague> mriedem: yeh
13:58:13 <mriedem> and put it where? new thing or osc?
13:58:22 <sdague> probably a new thing entirely
13:58:26 * alex_xu will cut the meeting on time, but now people can just free to talk
13:58:48 <sdague> I guess it could be an osc plugin, which would be fine
13:59:16 <sdague> but not in nova cli for sure, because that will be one more bit of split challenge
13:59:22 <alex_xu> #endmeeting