| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-16 | |||
| 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? | |
| 16:18:50 | lbragstad | yeah - oslo.policy | |
| 16:19:20 | lbragstad | since projects will probably see if there before they dig into keystone docs if they're using DocumentedRuleDefault or RuleDefault objects | |
| 16:19:56 | mriedem | yeah | |
| 16:19:57 | openstack | Launchpad bug 1771621 in oslo.policy "Documentation for scope_types doesn't mention what the valid scope types are" [Undecided,New] | |
| 16:19:57 | mriedem | https://bugs.launchpad.net/oslo.policy/+bug/1771621 | |
| 16:20:29 | lbragstad | sweet - i can get that fixed today | |
| 16:20:44 | mriedem | so if i set scope_types=['project'] for /usages, that means a system-scope token or a token scoped to the project in the target for the check has access? | |
| 16:21:09 | mriedem | i'm trying to think about admin_or_owner terms here | |
| 16:21:22 | lbragstad | yeah - scope_types handles that mapping | |
| 16:21:41 | mriedem | but that also means the project_id from the query param needs to be in the target to the enforce() call? | |
| 16:21:55 | lbragstad | if you set 'project' as a scope type for a policy, the policy engine will make sure the token used to make that request is project-scoped | |
| 16:21:58 | mriedem | because if i'm using a token from project A and doing GET /usages?project_id=B | |
| 16:22:01 | mriedem | i shouldn't be able to right? | |
| 16:22:09 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290 | |
| 16:22:19 | lbragstad | correct, that would be a violation of the authorization we have with project role assignments | |
| 16:22:35 | mriedem | ok, because the way i have the check for that right now is it just passes in the user request context, | |
| 16:22:54 | mriedem | so it's going to say, "you have a token for project A and you're checking project A, so sure, lgtm" | |
| 16:22:55 | mriedem | right? | |
| 16:23:49 | lbragstad | yes.. that's what you need, but sometimes it's easier to just ask oslo.policy to check that the token is scoped to the proper entity and leave the context.project_id == query_param.project_id check to the nova code | |
| 16:24:04 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class https://review.openstack.org/549053 | |
| 16:24:05 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk https://review.openstack.org/549300 | |
| 16:24:08 | lbragstad | oslo.policy should make sure the token used matches the scope_types and that the check_str passes | |
| 16:24:42 | mriedem | "leave the context.project_id == query_param.project_id check to the nova code" | |
| 16:24:46 | esberglu | mriedem: Added the abstract tags and responded to your other comments ^ | |
| 16:24:48 | mriedem | i don't know that we explicitly do that in our apis | |
| 16:24:57 | lbragstad | right... and that's fine | |
| 16:25:03 | lbragstad | because openstack always kinda operated like that | |
| 16:25:03 | mriedem | we probably do enforce that in things like DB APIs that query based on the context | |
| 16:25:04 | mriedem | model_query | |
| 16:25:16 | mriedem | esberglu: thanks | |
| 16:25:28 | lbragstad | ideally, in the future, you might want to consider a layer that does some validation like that | |
| 16:25:31 | stephenfin | mriedem, dansmith: Posted updates to that numa-aware-vswitch spec. Think I might need some input regarding how I'm storing the information for use in the scheduler and resource tracker | |
| 16:25:53 | lbragstad | making sure the resource controlled by nova falls within the authorization context set by the token | |
| 16:25:58 | mriedem | stephenfin: we might want to jump on a hangout for that | |
| 16:26:10 | mriedem | need to understand your work items to know how we should store data and pass it around | |
| 16:26:27 | stephenfin | mriedem, dansmith: It's probably best to look at what I have done and suggest why I shouldn't have done that https://review.openstack.org/#/c/564449/3 https://review.openstack.org/#/c/564452/3 | |
| 16:26:52 | stephenfin | mriedem: Yeah, that wouldn't be a bad idea. I can't do this evening though :( | |
| 16:27:06 | mriedem | stephenfin: tomorrow morning after the nova meeting? | |
| 16:27:09 | mriedem | well, evening for you | |
| 16:28:01 | stephenfin | mriedem: dansmith and I have our team meeting then. I can do any time before | |
| 16:28:08 | dansmith | I can't do before | |
| 16:28:13 | dansmith | but could do after-after | |
| 16:28:46 | mriedem | i'm free tomorrow, depends on stephen's hard drop everything and leave the office time :) | |
| 16:28:47 | stephenfin | Heh, and I can't do after-after (tag rugby game to play) | |
| 16:28:53 | mriedem | see! | |
| 16:29:11 | dansmith | we'll all also be in YVR | |
| 16:29:20 | stephenfin | aaaand I'm gone to Vancouver Friday AM | |
| 16:29:26 | mriedem | stephenfin, see, you need to start a family, give up on friends, and confine yourself to your desk | |
| 16:29:39 | stephenfin | dansmith: That would work. Don't imagine it'll take long | |
| 16:29:40 | mriedem | start working on your sweet sweet paunch | |
| 16:29:49 | mriedem | yeah we can punt to YVR... | |
| 16:30:38 | stephenfin | Aye, but if efried_rollin can fit in 8 sessions a week, I should probably try fit in a tag game | |
| 16:30:46 | stephenfin | mriedem: Sweet | |
| 16:34:27 | mriedem | efried_rollin: esberglu: +2 on https://review.openstack.org/#/c/549053/ | |
| 16:36:41 | esberglu | mriedem: ack, tx for review | |
| 16:36:57 | cfriesen | stephenfin: tag rugby? that's not as much fun. :) | |
| 16:39:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add granular policy rules for usages https://review.openstack.org/568706 | |
| 17:00:16 | lbragstad | mriedem: let me know if this helps https://review.openstack.org/#/c/568901/ | |
| 17:02:08 | lbragstad | it's rough - but it might also be beneficial to add in a section on how the service is responsible for checking the scope of the resource in the request against the token being used, and how that differs from the scope_types check | |
| 17:09:07 | mriedem | lbragstad: thanks, in a tab, will look in a bit | |
| 17:10:36 | lbragstad[m] | mriedem: cool, thanks for bringing it up | |
| 17:48:30 | melwitt | dansmith: would you please update the topic with the new runways https://etherpad.openstack.org/p/nova-runways-rocky | |
| 17:48:38 | melwitt | *channel topic | |
| 17:48:38 | mriedem | jaypipes: dansmith: i went over the mirror aggregates to placement change https://review.openstack.org/#/c/553597/ - think we just need to determine what to do about safe_connect usage in there and how idempotent we should be | |
| 17:48:40 | dansmith | yeah sorry | |
| 17:48:57 | melwitt | thanks mriedem for swarpping the runways | |
| 17:49:03 | melwitt | swapping | |
| 17:49:10 | mriedem | np | |
| 17:49:38 | dansmith | um which is the powervm one? | |
| 17:49:43 | dansmith | looks like multiple specs | |
| 17:49:49 | dansmith | but just powervm-localdisk now? | |
| 17:50:13 | melwitt | it's multiple blueprints. they used to be in one and were asked to split them into specless bps, IIRC | |
| 17:50:30 | melwitt | one for each parity thing. so it's a little weird | |
| 17:50:43 | jaypipes | thx mriedem | |
| 17:51:49 | mriedem | i'll also push a docs change for the rocky requirement in nova-api to have placement configured for things like local delete and deleting compute services | |
| 17:52:06 | mriedem | those are idempotent today but you'll get warnings in the logs if placement isn't configured for nova-api | |
| 17:53:37 | melwitt | oh and powervm-vscsi is blocked on CI coverage so powervm-localdisk is the only one left | |
| 17:53:39 | melwitt | derp | |
| 17:58:24 | mriedem | esberglu: powervm ci seems to be unwell http://184.172.12.213/00/549300/27/check/nova-in-tree-pvm/03c26c0/logs/console.txt.gz | |
| 17:58:41 | mriedem | m echo 'Didn'\''t find service registered by hostname after 60 seconds' | |
| 17:59:03 | mriedem | i believe that timeout is configurable now if you need to bump it | |
| 17:59:45 | mriedem | http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/nova#n1066 | |
| 18:02:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use RequestSpec.user_id in scheduler.utils.claim_resources https://review.openstack.org/568917 | |
| 18:06:29 | esberglu | mriedem: Not a timeout, legit failure for the service to come up http://184.172.12.213/53/549053/18/check/nova-in-tree-pvm/9c1c445/logs/n-cpu.txt.gz | |
| 18:07:00 | mriedem | oh nice | |
| 18:07:26 | esberglu | mriedem: I thought https://review.openstack.org/#/c/549053/18/nova/virt/powervm/disk/driver.py@64 should make @abstractproperty accessible? | |
| 18:07:34 | esberglu | What am I missing | |
| 18:07:48 | mriedem | @abc.abstractproperty | |
| 18:07:55 | mriedem | https://docs.python.org/2/library/abc.html#abc.abstractproperty | |
| 18:07:56 | mriedem | i think anyway | |
| 18:08:51 | esberglu | mriedem: I guess I misunderstood add_metaclass. New patch incoming | |
| 18:09:08 | mriedem | yeah unit tests and pep8 failed in https://review.openstack.org/#/c/549053/ | |
| 18:14:05 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class https://review.openstack.org/549053 | |