13:00:01 <alex_xu> #startmeeting nova api
13:00:03 <openstack> Meeting started Wed May 25 13:00:01 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:06 <openstack> The meeting name has been set to 'nova_api'
13:00:10 <alex_xu> who is here today?
13:00:15 <cdent> hello
13:00:28 <sdague> o/
13:00:37 <edleafe> \o
13:00:45 <sdague> though there is a plumber, so I might have to disappear at any point to deal with that
13:00:56 <alex_xu> sdague: no problem
13:01:18 <Kevin_Zheng> o/
13:01:47 <alex_xu> ok, i think we can start the meeting
13:01:56 <alex_xu> #topic API Priorities
13:02:19 <alex_xu> For the api-ref, looks like we already merge versions and metadata
13:02:21 <jichen> o/
13:02:23 <oomichi_> hi
13:02:40 <sdague> yeh, I need to finish servers, I will try to do that soon
13:02:55 <sdague> there is still a pretty good flow of reviews coming in, I would encourage people to stay on top of them
13:03:09 <sdague> http://burndown.dague.org/ - we're down to about 50% of tags left
13:03:22 <alex_xu> good news!
13:03:49 <Kevin_Zheng> alex_xu: did you guys decide on how to work with microversioned sample files?
13:04:14 <alex_xu> Kevin_Zheng: i guess no, sdague do you have idea abou that?
13:04:28 <sdague> Kevin_Zheng: not yet
13:04:52 <Kevin_Zheng> OK
13:05:15 <Kevin_Zheng> can we have both?
13:05:33 <Kevin_Zheng> but if there are multiple the samples will be too much?
13:06:20 <johnthetubaguy> I think all the current ones match v2.1, I guess we could hide some newer samples, if there have been changes to the API, we test every edge, so we could have a sample for each edge?
13:06:23 <alex_xu> Kevin_Zheng: does work with only the newest api sample file? as we marked some field only available in new version
13:06:43 <sdague> I need to start poking at a few other microversion UX things in the code
13:06:57 <sdague> I will try to start in on that this week
13:07:08 <johnthetubaguy> sdague: feels like we need to experiment with keypairs or something, to see what works
13:07:15 <sdague> johnthetubaguy: yeh, agreed
13:07:24 <Kevin_Zheng> yes
13:07:29 <sdague> that's going to be largely os-api-ref work
13:07:32 <alex_xu> sdague: cool
13:07:40 <sdague> as it will include javascript that changes visibility
13:07:45 <johnthetubaguy> yeah, +1
13:07:59 <jichen> cool~
13:08:39 <alex_xu> ok, so i think that is all for api-ref for now?
13:09:02 <sdague> yep
13:09:08 <alex_xu> let's move on
13:09:14 <alex_xu> for policy discovery
13:09:19 <alex_xu> #link https://review.openstack.org/289405
13:09:40 <alex_xu> I saw claudio_ updated spec for show policy discovery in nova-manage
13:10:21 <alex_xu> not sure people reviewed it. looks like it needs nova-manage to validate the user just like python-novaclient.
13:10:41 <johnthetubaguy> I wonder if we just pass in a keystone token for now?
13:10:44 <sdague> I have not reviewed that yet, I will add it to my list
13:10:54 <alex_xu> currently nova-manage just use a fake admin context
13:11:12 <johnthetubaguy> although I guess we can use that keystone lib we use elsewhere now
13:11:12 <sdague> johnthetubaguy: ... will a token get us anywhere?
13:11:31 <alex_xu> johnthetubaguy: still need to get the role of user form keystone?
13:11:44 <johnthetubaguy> yeah, I was thinking from the token fetch the roles, etc
13:11:48 <alex_xu> s/form/from/
13:11:59 <johnthetubaguy> we could just pass the info you get back from keystone, I guess, like the role and tenant, etc
13:12:21 <sdague> johnthetubaguy: lots of token types don't include all that embedded info, you need the round trip
13:12:33 <sdague> honestly, maybe this should be a dedicated tool
13:12:39 <sdague> nova-policy-check
13:12:44 <johnthetubaguy> it does feel different to nova-manage
13:12:48 <johnthetubaguy> a new cmd seems cheap
13:13:00 <sdague> just to keep us from doing ugly things in nova-manage
13:13:05 <johnthetubaguy> sdague: good idea
13:13:10 <alex_xu> if we put in python-novaclient, sounds more easy
13:13:30 <johnthetubaguy> thats too end user facing, we need access to deep bits of nova
13:13:36 <sdague> alex_xu: it can't really be in nova client, it needs access to nova code
13:13:47 <alex_xu> ah, yea, forget that point
13:13:50 <sdague> this tool only works on the machine where you nova api install is
13:14:05 <sdague> but, yeh, let's just do it as a dedicated tool
13:14:08 <johnthetubaguy> yeah, that seems a reasonable assumption
13:14:23 <johnthetubaguy> we could make it use the same params/env variables as python-novaclient though
13:14:28 <sdague> claudio_: sound reasonable to you?
13:14:32 <johnthetubaguy> i.e. do a full auth
13:14:43 <sdague> johnthetubaguy: sure, but that's mostly about keystoneauth1
13:14:52 <johnthetubaguy> sdague: +1
13:15:00 <alex_xu> is it ok just pass role manually by operator?
13:15:37 <alex_xu> or it can't show all the worksflow for us
13:15:40 <sdague> alex_xu: maybe as a follow on, lets get something more automatic first
13:15:52 <alex_xu> sdague: ok
13:15:56 <sdague> ok, who wants to provide the feedback to the spec?
13:16:24 <johnthetubaguy> so its open in a tab, I can do that
13:16:31 <alex_xu> johnthetubaguy: thanks
13:17:06 <alex_xu> #action johnthetubaguy feedback the decision on separated tool for policy discovery back to the spec
13:17:24 <alex_xu> anything more for policy? otherwise let's move on
13:17:32 <sdague> on the flip side, a bunch of the oslo.policy changes landed
13:17:43 <sdague> the policy generator is still outstanding I think
13:17:53 <alex_xu> sdague: yea
13:18:00 <alex_xu> #link https://review.openstack.org/309153
13:18:28 <sdague> right, so we need to close on that
13:18:44 <johnthetubaguy> yeah, we had some discussions on ops requests, but I think we got to the bottom of that now
13:18:47 <alex_xu> ok, encourage people help on the review
13:19:03 <sdague> we should also probably figure out who else on the oslo side should be engaged on review
13:19:08 <sdague> dhellman has been doing a bunch
13:19:28 <sdague> but seems like we want additional eyes as well so this doesn't get stalled after he's happy with it
13:20:09 <johnthetubaguy> good point
13:20:27 <johnthetubaguy> I wonder if dims is feeling keen about policy
13:20:27 <sdague> maybe I'll ask dhellman about that
13:21:31 <alex_xu> ok, so sdague just is action for you?
13:21:48 <sdague> yeh
13:22:09 <sdague> #action sdague to follow up with dhellman to find the right additional reviewers for oslo.policy changes
13:22:23 <alex_xu> sdague: thanks :)
13:22:38 <alex_xu> ok, i think we can move on
13:22:52 <alex_xu> let talks about remove legacy v2
13:22:55 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/remove-legacy-v2-api-code
13:23:09 <alex_xu> johnthetubaguy: have concern on removing the old policy checks
13:23:37 <johnthetubaguy> ah, so the policy checks in compute.api.py
13:23:40 <alex_xu> johnthetubaguy: so we expect fill the target param for the policy check?
13:23:46 <johnthetubaguy> they include the target
13:23:49 <johnthetubaguy> which is useful
13:24:12 <alex_xu> johnthetubaguy: but those aren't work with v2.1 API, due to the skip_policy_checks flag
13:24:14 <johnthetubaguy> (and sdague was telling me about the operator thread on wanting to have policy based on user_id)
13:24:21 <johnthetubaguy> oh, oops
13:24:25 <johnthetubaguy> right, we skip those
13:24:36 <johnthetubaguy> ah, well, just take that out then
13:24:41 <sdague> johnthetubaguy: right, so I think maybe we talk about this issue now though
13:24:42 <alex_xu> s/aren't works/doesn't work/...
13:24:49 <sdague> because it impacts the v2 legacy remove, a little
13:25:10 <johnthetubaguy> yeah, lets touch on the wider issue
13:25:20 <sdague> http://lists.openstack.org/pipermail/openstack-operators/2016-May/010526.html
13:25:26 <sdague> for people that haven't read it yet
13:25:28 <johnthetubaguy> ah, thanks, thats it
13:26:12 <johnthetubaguy> so its a horrible thing that arguably breaks our API semantics, but it worked before, and now it fails
13:26:16 <alex_xu> ah, really have people using "user_id:%(user_id)s"
13:26:20 <sdague> right
13:26:22 <johnthetubaguy> yeah
13:26:30 <sdague> now, in some cases, I don't think they need it
13:26:47 <sdague> people were basically just building catchall projects so they didn't have to create projects
13:26:57 <sdague> because users will get autocreated from AD
13:27:07 <johnthetubaguy> now it turns out the DB code hard codes the tenant_id check, so most of the policy rules that check the tenant_id right now are misleading
13:27:16 <sdague> but CERN has a more middle ground use case
13:27:24 <sdague> though they still haven't responded with all the details
13:27:47 <sdague> johnthetubaguy: right, we filter by context on project_id
13:27:54 <sdague> so there is an overlap there
13:28:13 <alex_xu> we can match the v2 api behaviour with quick fix by adding target param, then later fix on db layer hard-code.
13:28:25 <sdague> I actually think that user_id: only works in a subset of calls anyway
13:28:31 <sdague> because of things like this
13:28:50 <sdague> alex_xu: the real question is what set of things do we do this across
13:29:01 <sdague> or do we do it at all
13:29:08 <sdague> I'm very on the fence
13:29:20 <alex_xu> ok, got it
13:29:26 <johnthetubaguy> I am tempted to actually filter the objects we pass as a target
13:29:36 <johnthetubaguy> so we just pass user_id and project_id
13:29:37 <sdague> and feel like we still don't really have enough details on the policy changes and use cases here
13:30:02 <dims> johnthetubaguy : sdague : there's only one in the queue - https://review.openstack.org/#/q/project:openstack/oslo.policy+is:open
13:30:03 <sdague> johnthetubaguy: and change the meaning of GET /servers ?
13:30:28 <sdague> dims: that's the only one outstanding, it requires a spec as well
13:30:46 <sdague> dims: the oslo.policy changes are pretty compact
13:30:54 <johnthetubaguy> so by default there is no change in the API, it just allows people to break the API
13:31:05 <sdague> johnthetubaguy: that seems... problematic
13:31:11 <johnthetubaguy> my thinking is we then deprecate user_id, and work out how to support those usecases another way
13:31:23 <sdague> that's actually why mtreinish pushed back really hard on people testing this
13:31:27 <johnthetubaguy> your quota idea, could be part of that, but it feels like there are other things
13:31:53 <sdague> right, so the thing is, I feel like we need a lot more engagement on the operator side to figure out those details
13:32:08 <sdague> I've asked for them a few times in the ML, and really haven't seen detailed answers
13:32:09 <johnthetubaguy> we do, we will need to go to ops meetups with ideas and get feedback, etc
13:32:20 * dims notes mikal has oslo core privs :)
13:32:25 <johnthetubaguy> they seems talkative when pin them down in a room
13:32:27 <sdague> johnthetubaguy: well, we need this info sooner than that
13:32:31 <dims> sdague : johnthetubaguy : will review the spec and that review today
13:32:32 * johnthetubaguy makes a note of dims note
13:32:39 <sdague> dims: thank you
13:33:29 <johnthetubaguy> so we have lots of policy things in flux, if we get the default policy thing, we can start output warning when people have deprecated "rule params", like user_id
13:33:47 <sdague> sure
13:33:54 <johnthetubaguy> at that point, I think we have they system by which we can sensible message to people we can remove the feature
13:34:00 <johnthetubaguy> it feels like we are stuck with it till then :(
13:34:02 <sdague> but we will ship a release where their rules will not work at all
13:34:23 <sdague> delete of v2 legacy removes all these features
13:34:34 <johnthetubaguy> in my head I was thinking this release, we add in the target everywhere, to smooth the transition
13:34:48 <sdague> johnthetubaguy: that means it needs to be tested everywhere
13:34:57 <sdague> the reason this broke is no tests
13:35:03 <sdague> that's actually a pretty big effort
13:35:11 <johnthetubaguy> yeah, that true it is
13:35:30 <sdague> so, it's definitely a spec
13:35:34 <sdague> and it needs people
13:35:36 <johnthetubaguy> it is something I can get some of the OSIC folks to help with, I suspect, but we clearly shouldn't do that lightly
13:35:46 <johnthetubaguy> yeah, it needs a spec
13:36:02 <johnthetubaguy> can anyone see another way to dig out of this problem?
13:36:20 <johnthetubaguy> other than just not fixing it
13:36:39 <johnthetubaguy> anyways, putting a spec up gives us all time to think about it more
13:37:05 <sdague> well, the other thing is to go through the details that people did and figure out much narrower targets
13:37:30 <sdague> like, if this is only for server state change actions, that's one thing
13:37:41 <sdague> it's like 6 actions that are probably important, and that's all we do
13:37:53 <sdague> but right now it's just "we need this generically supported in policy"
13:37:55 <sdague> which is huge
13:38:09 <johnthetubaguy> yeah, starting with server actions, adding user_id and project_id as the target, seems like a scope
13:38:23 <sdague> and I only want to fix specific ones that people can't live without
13:38:35 <edleafe> If it can be done for just those few cases, that would be preferable
13:38:43 <sdague> and try to figure out a different way around for all of them
13:38:52 <johnthetubaguy> hmm, OK... I just worry about the folks that haven't spoken up
13:38:55 <sdague> because, server locking seems like it solves a ton of that
13:38:59 <edleafe> That will give time for them/us to figure out an alternative
13:39:12 <sdague> johnthetubaguy: sure... but honestly, we can't just keep guessing in the wind :)
13:39:17 <johnthetubaguy> sdague: thats a good point, server locking does
13:39:28 <sdague> you have to speak up if you want a voice
13:39:33 <sdague> we are not mind readers
13:39:54 <johnthetubaguy> true, I was more coming from the, oops, lets follow the deprecation cycle properly
13:40:16 <sdague> johnthetubaguy: well, this was never deprecated because "no one knew it was a feature"
13:40:22 <johnthetubaguy> but its not that clear cut, we did deprecate the code that supports all this
13:40:26 <sdague> like, we litterally didn't put this code into the v3 stack at all
13:40:33 <johnthetubaguy> sdague: ack
13:40:38 <sdague> it's effectively not existed in new code in 3 years
13:40:53 <sdague> and all these calls of "please go try this"
13:41:10 <sdague> kind of ignored until the week before deleting all the legacy v2 code
13:41:46 <edleafe> It's the downside of running Juno/Kilo
13:41:50 <johnthetubaguy> well its about now folks are using the thing where we made v2.1 the default, but agreed its not idea
13:41:57 <edleafe> when we're working on Newton
13:43:00 <johnthetubaguy> anyways, I am +1 getting a list of places where it matters, and just fixing that
13:43:10 <sdague> johnthetubaguy: ok, how do we get that?
13:43:14 <johnthetubaguy> with a note saying, we need to get you off this thing
13:43:30 <sdague> because my asks on the ML aren't
13:44:15 <sdague> they don't seem to http://lists.openstack.org/pipermail/openstack-operators/2016-May/010531.html
13:44:20 <johnthetubaguy> maybe we just add a reno note about the new policy not supporting any target info, and we update the default policy to make that clear?
13:44:52 <johnthetubaguy> if someone comes forward with specific cases (I think we have that old patch on the bug), we consider adding it?
13:45:05 <johnthetubaguy> we can tell them that on the ML, and hope for the best?
13:45:38 <oomichi_> johnthetubaguy: +1 for clarifying that on a reno, and we will be able to get real feedback/requirements
13:45:52 <johnthetubaguy> actually, we need to update all our docs, as it turns out we documented this as an option
13:47:24 <alex_xu> that sounds a plan
13:47:59 <sdague> johnthetubaguy: ok, do you have the action to go update those docs?
13:48:20 <johnthetubaguy> I think I do, yes
13:48:33 <johnthetubaguy> I will try find someone to own this, and help them through it
13:49:27 * alex_xu not sure how to write this action...
13:49:49 <sdague> ok, johnthetubaguy can you write the action
13:49:59 <johnthetubaguy> I will try sort out the policy user_id mess
13:50:03 <johnthetubaguy> or something like that?
13:50:06 <sdague> and we should make sure to revisit all old actions next meeting
13:50:13 <johnthetubaguy> sdague: +1
13:50:19 <alex_xu> sdague: yea
13:50:26 <sdague> #action johnthetubaguy to update policy docs to remove user_id references to server actions
13:50:34 <johnthetubaguy> also
13:50:48 <alex_xu> #action alex_xu will revisit all old actions next meeting
13:50:50 <alex_xu> :)
13:50:50 <johnthetubaguy> #action johnthetubaguy to reply on bug and ML about the ops issues with user_id
13:51:18 <alex_xu> johnthetubaguy: thanks
13:51:23 <alex_xu> i think we can move on
13:51:45 <alex_xu> anything we want to talk about deprecation?
13:52:02 <johnthetubaguy> of the user_id?
13:52:53 <alex_xu> johnthetubaguy: sorry, you mean?
13:53:10 <johnthetubaguy> oh, I was meaning, what bits of deprecation did you want to talk about?
13:53:37 <alex_xu> the deprecation proxy api was merged
13:53:51 <alex_xu> another thing is about extension
13:53:55 <johnthetubaguy> ah, proxy APIs, gotacha
13:54:15 <alex_xu> i guess no update for deprecate proxy api for now.
13:54:20 <alex_xu> and not hurry
13:54:58 <alex_xu> sorry, i didn't get time to work out a spec for extension also. people can free to take this task also
13:55:37 <alex_xu> if we didn't have anything for those, let jump to open? there are two opens didn't get chance last week.
13:56:27 <alex_xu> ok...3 mins left
13:57:03 <cdent> before we scoot off, just want to say this ought to be ready for review: https://review.openstack.org/300077
13:57:08 <cdent> that's support for both microversion headers
13:57:10 <Kevin_Zheng> can we talk a little about the hard-stop feature?
13:57:15 <cdent> the main sticking points will be the docs
13:57:17 <alex_xu> cdent: yea
13:57:23 <alex_xu> Kevin_Zheng: go ahead
13:57:25 <cdent> as it is hard to know what's best
13:57:49 <alex_xu> i guess just for advertis your item...
13:57:58 <Kevin_Zheng> https://review.openstack.org/#/c/293790/
13:58:06 <johnthetubaguy> cdent: seems like the docs are failing to build right now?
13:58:10 <sdague> cdent: I'll add https://review.openstack.org/300077 to my review queue
13:58:16 <sdague> and suggestion docs
13:58:19 <Kevin_Zheng> really hope this can merged,
13:58:26 <cdent> johnthetubaguy: feh
13:58:29 <cdent> I'll fix that
13:58:42 <Kevin_Zheng> really close to non-priority spec freeze
13:58:44 <cdent> thanks sdague
13:58:57 <johnthetubaguy> no worries, appreciate the extra doc entires on that one, its looking close
13:59:15 <sdague> Kevin_Zheng: https://review.openstack.org/#/c/293790/8/specs/newton/approved/allow-user-defined-shutdown-for-stop.rst has some remarkable overlap to - https://review.openstack.org/#/c/234219/ shutdown_termination part
13:59:34 <alex_xu> sorry....let's back to openstack-nova
13:59:39 <alex_xu> #endmeeting