13:00:43 <alex_xu> #startmeeting nova api
13:00:44 <openstack> Meeting started Wed Aug 10 13:00:43 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:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:48 <openstack> The meeting name has been set to 'nova_api'
13:01:01 <alex_xu> who is here for api today?
13:01:06 <cdent> hola
13:01:10 <edleafe> \o
13:01:13 <jichen> o/
13:01:31 <alex_xu> good morning everyone!
13:01:47 <gmann_> o/
13:01:58 <alex_xu> sdague will join later
13:01:59 <gmann_> good morning
13:02:40 <alex_xu> ok, let us start the meeting
13:02:50 <alex_xu> #topic API Priorities
13:03:21 <alex_xu> for proxy api deprecation, we merged the patch about imageref last week
13:03:57 <alex_xu> and the only thing left is about the cli part I think
13:04:07 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/python-novaclient+branch:master+topic:net-compat
13:04:53 <alex_xu> looks like no activety on those patches, i probably can check with dansmith if he needs any help later
13:05:25 <gmann_> alex_xu: both seems have +2
13:05:39 <alex_xu> gmann_: both have -1 also
13:05:45 <gmann_> oh
13:06:31 <alex_xu> for user_id based policy enforcement, we already have good sample patch from gmann_
13:06:51 <alex_xu> the only problem is the spec still not merged yet :(
13:07:05 <gmann_> alex_xu: i am pushing other patches too
13:07:17 <gmann_> alex_xu: yea once spec is merged then we can merge code easily
13:07:22 <alex_xu> gmann_: cool, thanks
13:07:31 <alex_xu> #link https://review.openstack.org/324068
13:07:53 <gmann_> alex_xu: and while doing that  i found start stop server already have policy enforcement for user_id
13:08:12 <gmann_> looks like we missed that we are providing for those
13:08:26 <alex_xu> sdague: ^ if you have time, we probably need a quick update the spec, then we can ask johnthetubaguy and matt help for merge the spec
13:08:49 <alex_xu> gmann_: yea, I guess there are few action already have user_id
13:09:06 <gmann_> alex_xu: sdague so here another question is should we stop this for start server as we are doing only for destructive actions ?
13:09:13 <johnthetubaguy> I know changing the devstack default has taken over his life, but I think that is merged now
13:09:20 <johnthetubaguy> yeah, I wasn't sure about that
13:09:40 <johnthetubaguy> start isn't *as* destructive, but its odd not matching the pair
13:09:43 <alex_xu> gmann_: we talk about that last week, we won't stop that
13:10:29 <gmann_> johnthetubaguy: alex_xu humm, then we do for all pair action like lock-unlock etc
13:11:03 <gmann_> my feeling was only for those listed currently in spec
13:11:25 <alex_xu> we want to deprecate that feature, so won't expand that support to more action i guess
13:11:40 <johnthetubaguy> right, thats the aim, a minimal solution
13:11:41 <alex_xu> gmann_: yea, me tto
13:11:48 <alex_xu> s/tto/too
13:12:11 <johnthetubaguy> the operators claimed they were happy with the list, it would be nice to get them to vote on this I guess? we should maybe follow up the old thread with a link?
13:12:43 <gmann_> johnthetubaguy: yea nice idea. and based on that we can do.
13:13:11 <johnthetubaguy> is someone happy to take that action?
13:13:31 <alex_xu> johnthetubaguy: we already do that
13:13:41 <johnthetubaguy> ah, I wondered if we had
13:13:50 <johnthetubaguy> I don't keep on top of that list
13:13:53 <gmann_> alex_xu: did we posted list?
13:14:05 <alex_xu> johnthetubaguy: sdague follow a link when he sent the spec out
13:14:21 <johnthetubaguy> yeah, that sounds like the good stuff he would do
13:14:28 <johnthetubaguy> anyways, how to move forward?
13:14:35 <johnthetubaguy> I think there a few typos and template issues that need fixing
13:14:42 <johnthetubaguy> thats what made me drop my vote
13:14:59 <johnthetubaguy> if someone could tidy that up, I could re-apply my +2
13:15:07 <gmann_> johnthetubaguy: and confirm_resize and revert_resize one also in question now
13:15:17 <johnthetubaguy> not really, its the same as all the other ones
13:15:23 <johnthetubaguy> start and unlock
13:15:28 <johnthetubaguy> etc
13:15:45 <johnthetubaguy> revert causes a small VM outage I guess
13:15:45 <gmann_> johnthetubaguy: but thats little bit different as resize is not a complete opertion alone without them
13:16:05 <johnthetubaguy> hmm, true
13:16:32 <johnthetubaguy> but the thing is, stopping folks do bad things
13:16:46 <johnthetubaguy> if you can't call resize, it doesn't matter so much if you call revert or confirm, I guess
13:17:31 <gmann_> and if after resize other can do revert_resize or confirm_resize which owner does not want :)
13:17:32 <alex_xu> johnthetubaguy: +1
13:17:32 <johnthetubaguy> its about restricting access, not increasing access, so the folks who can resize are allowed to do the other operations
13:17:45 <johnthetubaguy> gmann_: its the same argument as start
13:17:48 <johnthetubaguy> kinda
13:17:52 <gmann_> but yea there are lot of possibiity so not so strong on this
13:17:52 <sdague> o/
13:17:56 <gmann_> johnthetubaguy: yea :)
13:18:07 <johnthetubaguy> I wouldn't block anything that added both, but I wouldn't block on them not being their either
13:18:22 <johnthetubaguy> most people never call resize ever, so its a mute point really
13:18:34 <gmann_> humm
13:18:37 <gmann_> ok
13:18:47 <sdague> trying to catch up.
13:18:47 <johnthetubaguy> its just a light handed protection here, rather than strict isolation
13:18:55 <sdague> is there a patch up for the list of actions in the spec?
13:19:06 <gmann_> johnthetubaguy: yea, agree
13:19:16 <johnthetubaguy> gmann_: you had a patch up for one action I thought?
13:19:28 <sdague> I'd rather review just that first, get that in, then contemplate any chances only after that's in
13:19:29 <gmann_> sdague: johnthetubaguy i started and up for many
13:19:37 <gmann_> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/user_id_based_policy_enforcement
13:19:41 <sdague> gmann_: ok
13:19:54 <gmann_> sdague: lock one is first one
13:19:58 <gmann_> #link https://review.openstack.org/#/c/351100/
13:20:02 <alex_xu> gmann_: cool
13:20:18 <sdague> gmann_: ok, cool, I'll review that stack once we're done with the meeting
13:20:22 <gmann_> sdague: it depends on spec patch
13:20:28 <gmann_> sdague: Thanks
13:20:46 <sdague> hmph
13:20:50 <sdague> we're still reviewing that spec?
13:21:13 <alex_xu> yea, some comments on the spec :)
13:21:21 <sdague> grr... mriedmen is rehashing all the same things we did here weeks ago
13:21:35 <gmann_> :)
13:21:44 * mriedem joins late
13:22:28 <sdague> mriedem: ok, well I'm frustrated with your comments on - https://review.openstack.org/#/c/324068/3/specs/newton/approved/user_id_based_policy_enforcement.rst
13:22:51 <sdague> because they are exactly the issues we've been over multiple times about not making this a complete solution only blocking destructive ops
13:23:09 <mriedem> ok?
13:23:44 <sdague> unlock, unpause, unshelve were intentionally left off the list
13:23:53 <johnthetubaguy> sdague: I removed my vote due to the formatting blips he spotted, the content I am still OK with (although the revert/confirm made me think, but I don't think its worth adding)
13:24:00 <sdague> This spec proposes that we support a very limited set of operations on
13:24:00 <sdague> servers to check the user_id of the server in policy. These are
13:24:00 <sdague> operations that are considered destructive to servers.
13:24:13 <mriedem> ok i guess i missed that part
13:24:19 <mriedem> or didn't make the connection
13:24:54 <johnthetubaguy> ... and we are doing an intentionally bad job, so people know its a dead thing
13:24:55 <sdague> so, I'm fine fixing the template leak
13:25:00 <sdague> johnthetubaguy: right
13:25:24 <sdague> but we really need to move this forward, and the only ops folks that commented, were fine with this list of actions
13:25:34 <alex_xu> I remember I comment on evacuate is admin action, not sure why it added back to the list
13:25:35 <gmann_> sdague: should we state in spec that to not honor user_id for start server which is done currently
13:25:51 <sdague> alex_xu: by default, the whole point is people are changing policy
13:26:03 <mriedem> is there something in here which is clear about why it's only destructive operations and why we are just doing those?
13:26:05 <sdague> if they are changing policy, we shouldn't make assumptions about what they changed it to
13:26:09 <alex_xu> sdague: ok, got it
13:26:37 <mriedem> i get there are words about we missed this and people are using it but it's a crappy solution,
13:26:43 <sdague> mriedem: that's basically the whole problem description
13:26:54 <sdague> we never believed this should be a feature
13:26:57 <sdague> apparently it was
13:27:09 <sdague> and people are backdooring hierachical projects via this feature
13:27:39 <sdague> so we will provide the bare minimum safeguards to not randomly destroy every other persons vm in your project
13:27:40 <mriedem> so maybe fill out the actual use case section
13:27:58 <sdague> ok, it seemed like it was pretty clear from problem description
13:28:00 <mriedem> joe bob and jim bob are in the same project, joe bob stops his server but doesn't want jim bob to stop it, but jim bob can start job bob's server
13:28:32 <mriedem> sorry but it wasn't clear when i read it
13:29:11 <sdague> we also kind of don't want to document the use case too much, because the issue is people found those docs, and all started doing this
13:29:19 <sdague> we're actually trying to discourage that
13:29:35 <mriedem> :/
13:29:40 <gmann_> we will be doing this with deprecated feature right
13:29:44 <mriedem> obfuscated features
13:30:01 <mriedem> yeah, that was another thing i pointed out - it said this would be deprecated but didn't say how that would be signaled
13:30:23 <sdague> well, part of the signalling is removing all the docs about it
13:30:30 <gmann_> mriedem: yea
13:30:35 <mriedem> are there docs about it?
13:30:48 <sdague> L190 - 192
13:31:05 <sdague> yes, there are examples in some of the official docs that alex I think managed to delete
13:31:12 <johnthetubaguy> now we store the default policy in code, we should be able to warn if user_id is in a policy I guess?
13:31:20 <sdague> johnthetubaguy: we probably could
13:31:29 <alex_xu> yea, I fixed some
13:31:29 <sdague> but, freeze is in 10 business days
13:31:32 <alex_xu> #link https://review.openstack.org/325645
13:31:44 <alex_xu> #link https://review.openstack.org/325648
13:31:47 <gmann_> sdague: how about we explicitly say in api-ref plese do not use this
13:31:57 <sdague> gmann_: there is nothing in api-ref about policy
13:32:07 <johnthetubaguy> gmann_: its not really api-ref, its a operator thing
13:32:15 <gmann_> hummm
13:32:18 <sdague> here is the situation
13:32:26 <sdague> large sites are using this feature
13:32:29 <sdague> we've removed it
13:32:40 <sdague> we have a spec and code to bring back enough for them to survive
13:32:59 <sdague> so do we move forward, or just fully kick them in the privates :)
13:33:48 <mriedem> there is already code up?
13:34:11 <johnthetubaguy> https://review.openstack.org/#/q/topic:bp/user_id_based_policy_enforcement
13:34:13 <gmann_> mriedem https://review.openstack.org/#/q/topic:bp/user_id_based_policy_enforcement
13:34:20 <gmann_> johnthetubaguy: thanks
13:34:24 <mriedem> i'm fine with the spec moving forward, but it needed some work
13:34:29 <mriedem> sorry i didn't blanket +W it
13:34:47 <johnthetubaguy> mriedem: are you OK with the current action list now?
13:35:24 <gmann_> sdague: johnthetubaguy mriedem we will remove user_id thing from start server right? just confirming again
13:35:29 <sdague> mriedem: ok, what is the changes I can make in the next hour to put this into a merge state
13:35:42 <gmann_> hoping this would cause backward incompatibilte thigns as v2.1 support that
13:35:45 <sdague> I think that's what I'm asking, because you have a lot of comments in there
13:36:01 <sdague> and a bunch of those are things we have specifically said we wouldn't do
13:36:56 <mriedem> i haven't gone through the actions in fine detail, i.e. not sure how crashDump is destructive yet w/o looking
13:37:12 <mriedem> or like, why isn't snapshot in here if os-stop is?
13:37:43 <sdague> mriedem: ok, so here is the thing, the action list was signed off on by the stake holders that need this
13:38:19 <sdague> so if you are reopenning that discussion, then the feature misses newton, because we need to go recheck that with the stake holders again
13:38:21 <mriedem> and that's not pointed out in the spec because we want it to be a secret?
13:38:47 <sdague> tim bell sent an email on it over a month ago to public lists
13:38:50 <mriedem> if it's a special list and it was discussed elsewhere then fine, i didn't know any of that, so let's just move forward with this list
13:39:01 <sdague> I'll go try to find it
13:39:11 <mriedem> and from what i remember then it was like 3 actions
13:39:24 <sdague> no, it was this action list
13:40:01 <sdague> it's been this action list since it was posted - https://review.openstack.org/#/c/324068/1..3/specs/newton/approved/user_id_based_policy_enforcement.rst
13:40:16 <mriedem> http://lists.openstack.org/pipermail/openstack-operators/2016-May/010560.html
13:40:26 <mriedem> ^ 3 actions
13:40:30 <mriedem> and that's what i remembered
13:41:36 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2016-June/096590.html
13:41:44 <sdague> that's tim bell's sign off on this review
13:41:58 <sdague> yes, it would have been better if they actually commented on the review, but it was on the public list
13:42:39 <mriedem> so they don't care about console?
13:42:46 <mriedem> even after they said that a few times early on?
13:42:56 <sdague> he looked at the list
13:44:51 <sdague> this is the narative that I've been going off of, folks from the operators list saw this spec, it's been the same set of actions since inception, and they didn't complain at this point. And we were just handling paperwork issues with nova specs folks not acking that
13:46:05 <sdague> which means I still believe we should move forward on that list. If it turns out to be the wrong thing, we at least had it public for a long window of time unchanged. If we change it during vacation season 2 weeks from freeze, it's not really clear we can get revalidation on it
13:46:45 <mriedem> so maybe the spec should explicitly say, yeah this isn't a full list probably, but this is what people in the referenced ops list said they were happy with
13:46:53 <mriedem> and we don't want people using this anyway so tough
13:47:05 <sdague> I'm fine making that update after this meeting
13:47:49 <sdague> do we agree we move forward after that clarification?
13:48:08 <mriedem> sure, clean up the template stuff too, point out the use case
13:48:12 <mriedem> those were my gripes
13:48:12 <sdague> will do
13:48:25 <alex_xu> so cool :)
13:49:44 <alex_xu> mriedem: sdague johnthetubaguy could you feedback on the network deprecation cli patches also, if it needs update, i can help on update if Dan busy on other thing
13:49:48 <alex_xu> here is the link https://review.openstack.org/#/q/status:open+project:openstack/python-novaclient+branch:master+topic:net-compat
13:50:59 <mriedem> i told dan i would help work on https://review.openstack.org/#/c/347514/ but i'm not sure if i'll actually have time now given some other stuff i'm working on
13:51:02 * alex_xu reminds 10 mins left
13:51:22 <mriedem> but he said he was ok with others helping out there
13:51:28 <mriedem> since it got a lot bigger than he expected i think
13:52:21 <alex_xu> mriedem: no problem, I can work on so I needn't check with Dan, just get the authorization from you is enough
13:52:38 <mriedem> you might want to give him a heads up
13:52:52 <alex_xu> mriedem: ok, got it, catch him after the meeting
13:53:08 <alex_xu> the last thing is policy discovery cli
13:53:10 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/discoverable-policy-cli
13:53:28 <alex_xu> looks pretty good for me, but just no activity on those patches
13:54:41 <alex_xu> if you guys can give some feedback, I may catch the claudio to see if he can update or I give some help to make progress
13:54:58 <sdague> alex_xu: it's probably worth just updating those patches
13:55:06 <sdague> if you have feedback, as we're near the wire here
13:55:26 <sdague> it's the better part of a day to get a patch through the gate now even if it's good, and I expect that to grow to 2 days
13:56:04 <alex_xu> sdague: ok, got it
13:56:30 <alex_xu> mriedem: 2.37 looks like faild on a functional test, then it LGTM
13:57:02 <mriedem> alex_xu: unrelated failure, i'll recheck
13:57:25 <alex_xu> mriedem: due to that test running on `lastest` version
13:57:54 <alex_xu> after 2.37 we have 2.38, then this is all for newton
13:58:08 <alex_xu> anything I missing?
13:58:19 <alex_xu> otherwise we will close the meeting, 2 mins left
13:59:41 <alex_xu> emm... 1 mins left
14:00:11 <alex_xu> ok, thanks all!
14:00:14 <alex_xu> #endmeeting