Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-22
16:06:05 bauzas anyway, I'm litterally 24 hours away of taking a long break
16:06:42 jaypipes dansmith: perhaps this is the session I had to leave early (I was standing in the back and right before I left I said "recschedules should not occur and the reason for them will be gone when claining in the scheduler"?
16:06:45 bauzas I'm trying hard to make sure we're all on the same page before I leave
16:06:58 dansmith jaypipes: bauzas: mriedem: I'm good for a hangout any time starting now, whenever you want, until 11:30 PDT
16:07:08 bauzas I can
16:07:09 jaypipes I can do a hangout whenever.
16:07:13 mriedem i can also do now
16:07:17 jaypipes ++
16:07:23 dansmith jaypipes: yeah, you left, but I thought you were still around for the consensus on reschedules.. however you _were_ there for the scheduling claims session where we talked about the extra hosts thing
16:07:30 melwitt eliminating reschedules would make things really suck for Ironic users in the absence of a porcelain API that does retries
16:07:47 jaypipes melwitt: you mean "standalone Ironic".
16:07:53 melwitt no, Ironic + Nova
16:08:15 mriedem plus i think numa came up
16:08:20 dansmith I'll get a link, just a sec
16:08:22 mriedem in the claims in the scheduler session
16:08:40 jaypipes mriedem: NUMA is handled in the existing NUMAtopologyFilter.
16:08:57 dansmith https://hangouts.google.com/call/e6jtzndusjf6rezqvwdatascvuu
16:09:12 bauzas joining
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 ruleset looks like, so it can be turned into a worked example
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: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 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:16:06 sajeesh ok
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 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: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: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 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: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: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.

Earlier   Later