Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-22
16:09:16 jaypipes mriedem: claims would occur after the NUMATopologyFilter selected a host. We could have the NUMAtopology that was selected (and currently thrown away by the filter) written to the compute_nodes table.
16:10:26 bauzas dansmith: you're not there in the hangout
16:11:15 jaypipes melwitt: honestly, I don't really care about use cases where an IPMI boot failure results in an ERROR state for an instance
16:12:30 sajeesh ping sdague
16:14:37 sdague sajeesh: what's up?
16:14:58 sajeesh Hi sdague ..you have written in the mail Get someone from the CERN team to write down what their ideal
16:14:58 sajeesh ruleset looks like, so it can be turned into a worked example
16:15:12 sdague sajeesh: yes
16:15:20 sajeesh by ruleset do you mean all use cases ?
16:15:51 sdague not use cases, how they think they would want hierarchical quotas to work
16:16:06 sajeesh ok
16:16:06 melwitt jaypipes: :\ I don't know the particulars on what is different about scheduling onto baremetal directly, but when you have enough nodes, enough of them could be flaky and if we fail and go to error, we're not absorbing any of that for the end user
16:17:03 sdague sajeesh: because the use cases here don't build the hierarchical model all that well, most people set a bunch of use cases together that actually are conflicting
16:17:33 sdague so, I want the model algorithm to be proposed by groups that are interested, then we'll work it through
16:18:00 sajeesh sdague:+1
16:21:44 ayoung Since we are rewriting how you guys do policy enforcement, maybe y'all should take a look: https://review.openstack.org/#/c/384148/
16:22:50 ayoung alaski, it has changed a bit since you last looked at it...in October
16:25:23 cdent jaypipes are you guys still on the hangout?
16:25:30 jaypipes cdent: yes
16:25:37 sdague ayoung: so, my concern with is_admin on project is that now if you give a user authority to add other users to a project, they also get to see the physical topology of your cloud, and perform live migrations. Because while is_admin is no longer fully global, it isn't service scoped, right?
16:26:41 alaski ayoung: I'm no longer actively involved in openstack and likely won't get a chance to look too closely at that change.
16:26:54 ayoung alaski, understood
16:27:06 ayoung sdague, let me parse what you are asking.
16:28:19 ayoung sdague, "my concern with" == "the reason I don't like this approach." " if you give a user authority to add other users to a project" should read " if you give a user authority to add other users to the admin project"
16:28:45 ayoung sdague, is that what you mean?
16:28:52 sdague ayoung: well, I'm trying to understand based on what's there
16:29:06 ayoung sdague, ok...so let me try to explain what we are doing here.
16:29:17 sdague so, what does the flow look like from openstack cli calls
16:29:27 ayoung We added a config option in Keystone that indicates one project is an admin project.
16:29:28 sdague for what an operator would be doing, and why
16:30:09 ayoung If that value is set, if a token is scoped to the admin project, the oslo-context will contain the value is_admin_project=True
16:30:47 ayoung the assumption is that, for operations that should be scoped to a proejct, we still need to honor the admin role, but that should be distinct from global operations that need the admin role
16:31:20 ayoung for global operations, such as adding a hypervisor, you limit access to tokens with is_admin_project=True
16:31:28 ayoung it is not scoped per service
16:31:46 ayoung you could do per-service via RBAC, but you would still want to make use of this mechanism
16:32:11 ayoung if you wanted a computeadmin role separate from admin, you could do that, but it would require custom policy
16:32:43 ayoung but you would still want to enforce that the user has computeadmin on the admin_project, and not accept tokens scoped to other projects
16:32:49 ayoung sdague, does that make sense?
16:33:11 sdague ok, I guess I don't understand how it moves things forward. I think I need an example of openstack cli commands about "now this is in place, this is what a keystone admin would do to give bob the following permissions, and this is what he could do after"
16:33:29 sdague I need an outside in view of this to make it make sense to me
16:33:45 ayoung sdague, fair enough
16:34:07 ayoung sdague, once this change is merged, assuming no changes on the Keystone side, nothing would actively change in Nova
16:34:22 sdague ayoung: then I don't understand why we'd make the change
16:34:27 ayoung the reason for that is, as alaski and I discussed in his comments, we built a hack into oslo-context
16:34:40 ayoung sdague, it only takes effect once the config option is actively set in Keystone
16:35:09 ayoung at that point, only users with roles on the project that Keystone has configured as the admin_project would be able to execute these APIs
16:35:32 ayoung We need the change in Nova, Glance, Cinder, Neutron, and Keystone before the fix enforces policy across the board
16:35:33 sdague ayoung: sure, I guess I don't understand why Nova should ever know that big
16:35:38 sdague that bit
16:35:43 sdague like, that's the thing I don't get
16:35:55 sdague there are multiple ways now for a keystone setup to say "you are admin"
16:36:01 sdague so, that's fine
16:36:12 ayoung sdague Nova is the policy enforcement point, not Keystone
16:36:15 sdague why doesn't keystonemiddleware / oslo.context process that
16:36:27 sdague and just set the is_admin flag based on that logic
16:36:31 ayoung so....
16:36:48 ayoung Did you go to my RBAC in middleware talk?
16:36:50 sdague it doesn't seem useful to have to teach every service what the current keystone configuration is to do that
16:36:53 sdague nope
16:37:45 ayoung sdague, ok, so the conccet there is that RBAC could be enforced on just the URL, as it does not need to know the scope of the object out of the database. Unlike, say, neutron netwokrs, or glance images, which are project scoped. The role check is only on the URL
16:37:53 ayoung is_admin_project is a scope check.
16:38:15 ayoung and, for all the listed resources, we need to fetch an object our of the database first
16:38:39 ayoung OK...you say...but these APIs are not scoped, so we don't need an object from the database, right?
16:38:45 ayoung and...I agree with you
16:38:59 ayoung but we do not have enough information to determine what policy rule we need to enforce
16:39:09 ayoung only the policy.json file knows that, as of now
16:39:56 sdague ayoung: honestly, I think I need worked examples showing the set of cli flows for it to make sense. The policy bits get really abstract really quickly. And while I realize you have most of it your head, I can't really do that without pictures and flows
16:39:56 ayoung In the "RBAC in middleware" proposal, we specify an inventory of routes, with a role assigned to each. The routes look a lot like the Compute API doc
16:40:35 dansmith jaypipes: feel free to cc me directly on that mail if you want to further implicate me in the act of bring it back up
16:40:40 ayoung sdague, the short answer to your question is, without additional policy enforcement, we need to know, at policy time, whether a specific token is supposed to be global scoped or not
16:41:31 ayoung forget my RBAC proposal, cus that is not approved yet. JUst to get a fix for bug 968696, we need a way for Nova to say "yes, this token is good for global operations" or "no it is not"
16:41:31 openstack bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung)
16:41:58 ayoung sdague, determining which operations are global vs scoped is a decision for the Nova engineering team to make
16:42:08 ayoung as is figuring out how to enforce the scoping
16:42:22 ayoung what Keystione is providing is the answer to "is this token valid for global operations"
16:42:44 ayoung this patch is using that answer to start differentiating between scoped and global operationws
16:42:57 ayoung could it be done in middleware? Not today
16:43:03 ayoung Not without a lot more tooling.
16:43:35 sdague ayoung: so, I'll repeat, this isn't going to make any sense to me without those other diagrams and flows. So I'll stay opted out of the conversation if those don't exist.
16:43:54 ayoung sdague, huh?
16:44:08 ayoung I...I don't think I can make it any more simple than that.
16:44:22 ayoung In order to perform global admin operations, you need a token scoped to the admin project.
16:46:18 openstackgerrit Sylvain Bauza proposed openstack/nova master: Scheduler returning alternatives per destination https://review.openstack.org/465175
16:46:18 openstackgerrit Sylvain Bauza proposed openstack/nova master: Delete existing allocations when retrying https://review.openstack.org/460433
16:46:19 openstackgerrit Sylvain Bauza proposed openstack/nova master: Don't delete allocation if instance being scheduled https://review.openstack.org/460177
16:46:19 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: Allocate instance by the conductor https://review.openstack.org/460455
16:46:20 openstackgerrit Sylvain Bauza proposed openstack/nova master: Fix ChanceScheduler returning a wrong node https://review.openstack.org/466725
16:54:23 ayoung sdague, what exactly would you require in order to move this forward? Considering that a comparable change needs to go into every openstack project, I'm guessing that whatever we provided for the Nova team would help move it forward across the board. The current implementations are really broken, due to Keystone not having provided a way to distinguish between global and scoped tokens. But that mistake goes back to pre-Ke
16:54:23 ayoung ystone Nova's token system as well.
16:54:42 ayoung Just because it has been broken since Cactus does not mean it is not broken.
17:04:09 bauzas jaypipes: mriedem: dansmith: cdent: melwitt: edleafe: FWIW, given the outcome of our hangout, I'm going to stop working on my series, in particular given I'll need to disappear starting tomorrow
17:04:23 bauzas edleafe: feel free to takeover any change you want
17:04:57 bauzas edleafe: I just removed my -2s that I gave you previously
17:05:09 bauzas tl;dr: all is clear for iterating fast
17:05:32 bauzas I'll spend my day tomorrow for bug triaging and reviews
17:09:21 ayoung sdague, here is my RBAC talk. https://www.openstack.org/videos/boston-2017/per-api-role-based-access-control please watch it when you have the time. In the meanwhile, I will try to put together the explanation of why we are approach the fix to 968696 the way we are.
17:15:24 bauzas mriedem: melwitt: do you want me to publish a new rev for the ReqSpec delete where I would call the deletion in https://review.openstack.org/#/c/391060/9/nova/compute/api.py@2046 for example ?
17:15:33 bauzas I can do that quickly so you both could review
17:16:24 cdent bauzas: ack on the all clear for iterating
17:16:57 mriedem bauzas: i don't think that's the place to do it

Earlier   Later