Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-04
20:29:46 prometheanfire s/pike/rocky
20:29:53 prometheanfire I keep on calling rocky pike
20:32:55 cdent criminey
20:34:02 mriedem prometheanfire: and list_cells shows cell0 and cell1 right?
20:34:28 prometheanfire https://bugs.launchpad.net/nova/+bug/1790721
20:34:28 openstack Launchpad bug 1790721 in OpenStack Compute (nova) "nova-status upgrade check shows warnings when it shouldn't" [Undecided,New]
20:34:40 prometheanfire yep, shows both cells
20:35:28 mriedem i think it's the same bug
20:35:39 mriedem we're hitting the api db using this placement context manager, but it's not configured for the api db
20:35:44 mriedem so it's hitting cell0 looking for resource providers
20:36:50 cdent blargh. I thought nova-status use the api for placement checks?
20:36:51 prometheanfire ok, so partial fix so far then (I think)
20:37:10 mriedem cdent: there is a TODO from me in that same coe
20:37:12 mriedem *code
20:37:17 cdent ah
20:37:24 prometheanfire mriedem: ya, read that :P
20:37:27 mriedem we do hit the API to check that we can *talk* to placement
20:37:27 prometheanfire in _count_compute_resource_providers
20:37:50 mriedem yeah this one, "Check: Placement API"
20:37:56 mriedem that makes sure we can at least get to placement
20:42:19 openstackgerrit melanie witt proposed openstack/nova stable/queens: Add functional test for affinity with multiple cells https://review.openstack.org/599765
20:42:20 openstackgerrit melanie witt proposed openstack/nova stable/queens: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/599766
20:43:29 mriedem i should probably add nova-status upgrade check to devstack first, but i think that has to be run *after* the subnodes, if any, are up, which means we need to call back into devstack from d-g
20:43:35 mriedem like we do with discover_hosts
20:44:23 prometheanfire iirc it's run right before online migrations
20:44:33 prometheanfire at least the upgrade doc makes me think that
20:44:42 mriedem you can run it on base install too
20:44:50 mriedem to verify the deployment
20:45:01 prometheanfire ah
20:45:24 openstackgerrit melanie witt proposed openstack/nova stable/pike: Fix the request context in ServiceFixture https://review.openstack.org/599839
20:45:25 openstackgerrit melanie witt proposed openstack/nova stable/pike: Add functional test for affinity with multiple cells https://review.openstack.org/599840
20:45:26 openstackgerrit melanie witt proposed openstack/nova stable/pike: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/599841
20:46:43 openstackgerrit melanie witt proposed openstack/nova stable/pike: Fix the request context in ServiceFixture https://review.openstack.org/599839
20:46:44 openstackgerrit melanie witt proposed openstack/nova stable/pike: Add functional test for affinity with multiple cells https://review.openstack.org/599840
20:46:45 openstackgerrit melanie witt proposed openstack/nova stable/pike: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/599841
20:55:15 Sundar melwitt: Please ping me when you have a moment.
20:56:16 melwitt Sundar: hi
20:56:28 mriedem prometheanfire: well we'll see if this notices it https://review.openstack.org/599847
20:56:54 Sundar melwitt: You had asked for a Nova spec for accelerator-related things. The only open AFAICS is how Cyborg will interact with placement: through virt drivers or by calling placement directly.
20:56:57 Sundar Most other aspects are already addressed in the Cyborg/Nova scheduling spec (https://review.openstack.org/#/c/554717/) or in the ongoing os-acc spec (https://review.openstack.org/#/c/577438/).
20:57:14 Sundar So, can the new spec just point to the older specs for those aspects?
20:57:46 prometheanfire mriedem: just had to be sure, but at least that exit code works (got a 1)
20:58:53 Sundar May be we need a bit more detail on how exactly the virt drivers will invoke os-acc. I can add that to os-acc spec.
21:00:01 melwitt Sundar: you can and should add links to the other specs as references in the nova spec, but the nova spec should describe the proposed changes to nova as part of the interaction. the references can be for background reading and then the new spec will detail the nova changes that will be needed and those are what we will review (after reading the referenced other specs that you should add to the References section of the spec)
21:00:44 melwitt we just want to be able to review the proposal for nova changes as a nova spec
21:03:17 Sundar melwitt: OK. I'll take a stab. We can iterate from there as needed. Thank you.
21:03:28 melwitt cool, thanks
21:03:57 melwitt Sundar: btw, what day/time are you having the nova/placement interaction session at the cyborg room?
21:05:04 melwitt Sundar: and would sometime between 11:10am and 12:30pm on thursday work for you for Cyborg/Nova session at the nova room?
21:17:22 Sundar melwitt: It doesn't look like the Cyborg times are decided yet! https://etherpad.openstack.org/p/cyborg-ptg-stein
21:17:34 Sundar I'll ask Cyborg PTL and get this resolved
21:17:56 Sundar I am fine with your proposed time on Thursday
21:18:12 melwitt ok, just let me know so I can make a note on our etherpad so folks know when to show up at the cyborg room
21:18:26 Sundar Yes, sure. Thanks!
21:40:15 mriedem lbragstad: we probably need your keystone eyeballs on this https://review.openstack.org/#/c/599598/3/specs/stein/approved/transfer-instance-ownership.rst@140
21:40:33 mriedem tl;dr should nova be responsible for checking that a given user is in a given project
21:40:59 lbragstad mriedem looking
21:41:34 mriedem i guess GET /v3/users/{user_id}/projects would be pretty easy though
22:11:05 lbragstad mriedem yeah - we have another API like that, too
22:11:10 lbragstad https://developer.openstack.org/api-ref/identity/v3/index.html#list-role-assignments-for-user-on-project
22:18:46 lbragstad so long as there is a role returned, then that might be enough for nova http://paste.openstack.org/raw/729458/
22:21:51 mriedem lbragstad: ok and if nova is configured with admin / service user creds to keystone, can nova get the user information even if the current token in the request context is not for that user?
22:22:11 mriedem i guess it probably depends on what auth nova's keystone creds are configured with
22:22:22 mriedem but we use that today to verify a provided tenant id exists
22:22:27 mriedem for certain apis that take a tenant id
22:23:19 lbragstad yeah the token used to call that API is going to have to belong to the nova service user
22:24:17 lbragstad right now that policy is protected by rule:admin_required
22:25:47 lbragstad but - if that's too strict a default for nova, we do have work staged for stein to rework the authorization of that API https://bugs.launchpad.net/keystone/+bug/1750669
22:25:47 openstack Launchpad bug 1750669 in OpenStack Identity (keystone) "The v3 grant API should account for different scopes" [High,Triaged]
22:27:58 lbragstad nova should have access to the token used to make the request via the context object
22:28:51 lbragstad if you're expecting only system administrators to call this API, then you might be able to reuse that token to call the role API in keysotne
22:29:01 melwitt that reminds me of a wishlist bug we have open where people would like us to validate the user_id when updating quota limits, same as we validate the project_id currently
22:30:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix TypeError in nova-manage cell_v2 list_cells https://review.openstack.org/599861
22:32:15 lbragstad we have an api for that but it too would require administrator access
22:32:32 lbragstad or it would require the nova service user to be an administrator
22:33:20 lbragstad but, hopefully that's going to be changing soon with https://bugs.launchpad.net/keystone/+bug/1748027
22:33:20 openstack Launchpad bug 1748027 in OpenStack Identity (keystone) "The v3 users API should account for different scopes" [High,Triaged] - Assigned to sonu (sonu-bhumca11)
22:33:20 melwitt I see. but the validation of project_id is a non-admin thing?
22:33:49 lbragstad i guess it depends on how you're validating the project id
22:34:00 melwitt I have to check. I don't remember how we're doing it
22:34:02 lbragstad are you calling the GET /v3/projects/{project_id}
22:34:52 melwitt lemme see
22:35:18 melwitt yup, looks like it
22:35:28 lbragstad nice - in that case we do rule:admin_required or project_id:%(target.project.id)s
22:35:49 lbragstad making it accessible to admins and users with a role assignment on the project in the path
22:37:04 melwitt https://github.com/openstack/nova/blob/master/nova/api/openstack/identity.py#L41
22:38:13 lbragstad if that ksa session is built with the nova service user, then it looks like you're already handling the case where nova doens't have the necessary permissions https://github.com/openstack/nova/blob/master/nova/api/openstack/identity.py#L61-L68
22:38:26 lbragstad so that's good
22:39:15 lbragstad unless you're hoping to switch that case to false eventually
22:39:30 melwitt trying to see if it's built with the nova service user (sorry, this is new to me)
22:40:26 lbragstad https://github.com/openstack/nova/blob/master/nova/utils.py#L1189-L1191 ?
22:41:03 melwitt yeah, and we're passing ksa_auth=context.get_auth_plugin()
22:41:13 lbragstad looks like it supports being passed a ksa session and building one from config
22:41:38 mriedem yes https://docs.openstack.org/nova/latest/configuration/config.html#keystone
22:41:41 mriedem it's whatever you configure nova with
22:42:04 mriedem if you don't and we can't verify, we would default to our old behavior which is, meh - hope you know what you're doing admin person!
22:42:26 melwitt ah, ok
22:43:58 lbragstad huh - ok
22:44:33 melwitt # we don't have enough permission to verify this, so default
22:44:33 melwitt # to "it's ok".

Earlier   Later