Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-16
15:00:50 bauzas mriedem: please, yes
15:00:51 bauzas +2
15:01:11 bauzas we already signaled since pike, so let's send another batsignal now
15:05:20 openstackgerrit Stephen Finucane proposed openstack/nova master: Simplify instance name generation https://review.openstack.org/516573
15:15:46 openstackgerrit Eric Fried proposed openstack/nova master: Debug logs for allocation_candidates filters https://review.openstack.org/568712
15:16:36 jroll efried: what do you train for? running or?
15:17:02 efried jroll: I own & run a Brazilian jiu jitsu school
15:17:09 jroll ah, neat :)
15:18:09 efried 7 of those 8 are me leading class (and sparring with my students). The last one is me going to my mothership to receive instruction.
15:29:24 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove deprecated monkey_patch config options https://review.openstack.org/568880
15:40:58 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove deprecated monkey_patch config options https://review.openstack.org/568880
15:47:19 openstackgerrit Merged openstack/nova master: PowerVM Driver: Snapshot https://review.openstack.org/543023
15:49:51 mriedem efried: maybe you have input on this? https://review.openstack.org/#/c/549053/
15:50:27 efried mriedem: I was going to let esberglu answer. If that doesn't happen fairly soon, I'll jump in.
15:50:37 openstackgerrit Zack Cornelius proposed openstack/nova master: Implement file backed memory for instances in libvirt https://review.openstack.org/567876
15:51:19 efried mriedem: Big picture, we do use some of those capability bits to set the respective ones on the driver itself - they're different depending on which disk driver you're using - and others internally to figure out whether we can do certain things.
15:51:52 openstackgerrit Zack Cornelius proposed openstack/nova-specs master: Libvirt file backed memory https://review.openstack.org/563704
15:53:10 efried mriedem: But I haven't dug in to see whether that logic truly exists yet in the in-tree incarnation.
15:53:54 mriedem i just figured if you have an abc parent class with methods/properties that by default raise NotImplementedError, those should be marked as abstract methods/properties
15:54:26 mriedem i.e. i think the point is that the subclass won't instantiate unless it implements those methods
15:56:21 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add request_spec.RequestGroup versioned object https://review.openstack.org/568840
15:56:22 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add requested_resources field to RequestSpec https://review.openstack.org/567267
15:56:23 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268
15:56:48 mriedem lbragstad: policy question for you on https://review.openstack.org/#/c/568706/4/nova/api/openstack/placement/handlers/usage.py@93 - this api is defined as https://developer.openstack.org/api-ref/placement/#list-usages
15:56:55 mriedem and takes a required project_id query string parameter
15:57:13 mriedem right now our default rule uses check string role:admin
15:57:42 mriedem but thinking about admin_or_owner, would it make more sense if the target to the policy check is the project_id from the query param?
15:58:03 mriedem note placement doesn't have an admin_or_owner rule defined because most resources in placement don't have projects/users associated with them
15:58:29 lbragstad mriedem: so - it's safe to assume placement is mostly made up of system level resources?
15:58:30 mriedem or, i haven't gotten to the ones yet that do, like https://developer.openstack.org/api-ref/placement/#list-allocations
15:58:43 mriedem well, usages and allocations are per-consumer
15:58:56 mriedem and a consumer for now has a project/user (instance records, migrations, etc)
15:59:12 lbragstad that makes sense
15:59:15 mriedem i think a volume in cinder at some point would be a resource provider consumer
15:59:47 lbragstad but usages and allocations are per project in some cases and per user in others, right?
16:00:08 lbragstad (e.g. a user can have 5 ssh keys)
16:00:11 mriedem well, we always create them using the instance.project_id and instance.user_id i think
16:00:31 lbragstad ah
16:00:31 mriedem except i'm not sure if we pass user_id in all cases, sec
16:00:58 efried mriedem: oh, the abstract business, okay. Yeah, I understand, and yeah, abc is kind of a retrofit in python, not really any different behavior-wise from raising NotImplementedError. But we can probably clean that up if it's a thing for you.
16:01:04 lbragstad ok - i always thought that project_id was safe to assume in all cases (since pretty much everything requires a project scoped token today)
16:02:09 mriedem yes we always pass project_id,
16:02:10 gibi melwitt: I cannot make it to the tomorrow's nova team meeting so I cannot chair it.
16:02:26 mriedem and during scheduling we always pass user_id too, i just knew we had something different about how nova does that https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L842
16:02:31 melwitt gibi: k, np. thanks for the heads up
16:03:02 mriedem lbragstad: yeah so allocations will have project_id and user_id, and /usages response is built based on the allocations data i believe
16:03:30 lbragstad mriedem: so - based on the fact that project_id is always required when calling list-usages, i think it's safe to say that is a project-specific API
16:03:34 lbragstad (not sure if that was your question)
16:03:49 lbragstad but i would set scope_types on that to be project specific
16:04:46 lbragstad so - that's interesting thoguh
16:05:00 lbragstad if a system administrator wants to set the usage of a project, should they be able to?
16:05:15 lbragstad a project administrator should be able to set the usage of _their_ project
16:05:36 lbragstad so, in the second case, you'd need to make sure context.project_id and query_param.project_id match
16:06:00 lbragstad otherwise, if you just base things on the role assignment, you might open yourself up to allowing them to set usage for projects they have no authorization on
16:06:11 openstackgerrit Vladyslav Drok proposed openstack/nova master: Placement: allow to set reserved value equal to total for inventory https://review.openstack.org/564838
16:06:20 lbragstad the check for system administrators is a bit more loose
16:06:45 efried mriedem: Do you need to remove the comment at the top of nova/debugger.py?
16:07:13 lbragstad if context.system_scope and context.role == policy.check_str then update the usage with the project id in the query parameter
16:07:23 mriedem lbragstad: the usages stuff is all read-only, like a view table kind of, but yeah admins could change usage by modifying allocations for a given project/user
16:08:22 lbragstad mriedem: imo (which could be wrong), the ability to set that kind of stuff should be system administrator territy
16:08:27 lbragstad territory*
16:08:28 mriedem efried: this? # NOTE(markmc): this is imported before monkey patching in nova.cmd
16:08:28 mriedem # so we avoid extra imports here
16:08:40 mriedem efried: that's talking about eventlet monkey patching
16:08:40 efried mriedem: Yes. Wasn't sure if that referred to the same monkey patching you're axing.
16:08:44 efried okay, cool.
16:08:44 mriedem not "hack features into nova"
16:08:50 openstackgerrit Vladyslav Drok proposed openstack/nova master: Placement: allow to set reserved value equal to total for inventory https://review.openstack.org/564838
16:08:58 mriedem nova/cmd/__init__.py monkey patches eventlet
16:09:12 mriedem er whatever, you get it
16:09:29 efried +A
16:09:50 mriedem rhNKA
16:09:51 mriedem HA
16:09:53 mriedem *thanks
16:10:21 mriedem lbragstad: ok, you've gone over my head, but i haven't gotten to POST and PUT for allocations yet
16:10:30 mriedem also, where are scope types defined? keystone?
16:10:43 lbragstad they are defined at the service
16:10:57 lbragstad technically in the policy rules
16:10:58 mriedem using a config option?
16:10:59 mriedem oh
16:11:06 mriedem https://docs.openstack.org/oslo.policy/latest/user/usage.html?highlight=scope_types#setting-scope doesn't tell me anything about that
16:11:11 lbragstad but they should correspond to the different token scopes you can get from keystone
16:11:38 lbragstad " During enforcement, the information in scope_types is compared to the scope of the token used in the request."
16:11:40 mriedem and the token scopes from keystone, are those a finite hard-coded list or per deployment?
16:11:58 lbragstad nope - a project scoped token and a system scoped token should exist in every deployment
16:12:08 mriedem right, let me ask this way: if i set scope_types on a rule in code, how do i know what a valid scope type is? foo bar baz?!
16:12:18 mriedem is that doc'ed somewhere?
16:13:00 mriedem https://docs.openstack.org/keystoneauth/latest/api/keystoneauth1.access.html?highlight=scope#keystoneauth1.access.access.AccessInfo.scoped
16:13:23 lbragstad http://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html
16:15:58 mriedem so looks like scope_types can include project, system, domain, trust, right?
16:16:25 lbragstad technically - trust's are useless without projects and must include a project, so trust-scoped tokens are essentially project scoped
16:16:32 lbragstad (the usability is weird...)
16:16:41 lbragstad ideally, just 'project' and 'system' for now
16:16:46 lbragstad *maybe* 'domain' in the future
16:17:23 mriedem so would it be fair to put something into either https://docs.openstack.org/oslo.policy/latest/user/usage.html?highlight=scope_types#setting-scope or the "enforce_scope" config option help saying, "these are the valid scope types and what they mean"?
16:17:31 mriedem or at least link to some other doc that defines the valid scope types
16:17:47 lbragstad ++
16:17:56 lbragstad yeah - that was probably an oversight on my part
16:18:00 lbragstad and probably a doc bug
16:18:21 mriedem i can report it, but where? oslo.policy?

Earlier   Later