Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-04
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".
22:44:35 melwitt haha
22:44:35 lbragstad so - the same creds used by ksm?
22:44:57 lbragstad "move along citizen.. nothing to see here"
22:45:04 melwitt haha
22:52:39 melwitt should be whatever is in the [keystone] section of the nova.conf, though I don't see that configured in the gate nova.conf
22:53:37 melwitt I see only [keystone_authtoken] for example, in here http://logs.openstack.org/99/584999/5/check/tempest-full/29581fd/controller/logs/etc/nova/nova_conf.txt.gz
22:54:18 lbragstad yeah - that's what we look for in ksm for sure
22:54:29 melwitt oh, ok
22:54:32 lbragstad i'm wondering if that gets re-used for nova requests
22:55:03 lbragstad look like it - it should be available to nova via the config object
22:57:14 melwitt maybe this is how it gets re-used? https://github.com/openstack/nova/blob/master/nova/context.py#L59-L64
22:58:14 melwitt we do that as part of the context.get_auth_plugin() call, if there's no self.user_auth_plugin set https://github.com/openstack/nova/blob/master/nova/context.py#L160
23:48:13 lbragstad aha - interesting
#openstack-nova - 2018-09-05
00:13:14 openstackgerrit Elancheran S proposed openstack/nova stable/pike: Add exact match aggregate image properties matcher/filter https://review.openstack.org/599870
00:21:46 openstackgerrit Elancheran S proposed openstack/nova master: Add exact match aggregate image properties matcher/filter https://review.openstack.org/593167
00:59:10 openstackgerrit fupingxie proposed openstack/nova master: Delete allocations for instances that have been moved to another node https://review.openstack.org/582899
01:00:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix nova-status "_check_resource_providers" check https://review.openstack.org/599875
01:04:48 openstackgerrit fupingxie proposed openstack/nova master: Add an example to add more pci devices in nova.conf https://review.openstack.org/592243
01:09:28 openstackgerrit Sam Morrison proposed openstack/nova master: Fix DB archiver AttributeError due to wrong table name attribute used https://review.openstack.org/599878
01:23:57 openstackgerrit Sam Morrison proposed openstack/nova stable/rocky: Fix DB archiver AttributeError due to wrong table name attribute used https://review.openstack.org/599881
01:24:55 openstackgerrit Sam Morrison proposed openstack/nova stable/queens: Fix DB archiver AttributeError due to wrong table name attribute used https://review.openstack.org/599882
01:26:17 openstackgerrit Sam Morrison proposed openstack/nova stable/pike: Fix DB archiver AttributeError due to wrong table name attribute used https://review.openstack.org/599883
01:27:41 openstackgerrit Sam Morrison proposed openstack/nova stable/ocata: Fix DB archiver AttributeError due to wrong table name attribute used https://review.openstack.org/599885
01:28:34 prometheanfire mriedem: :D, not sure I can test it now without a rollback, but that else thing sounds right
01:30:33 openstackgerrit Matt Riedemann proposed openstack/nova master: Configure placement DB context manager for nova-manage/status https://review.openstack.org/599744
01:30:35 mriedem prometheanfire: here is the 2nd part of that ^
01:30:50 mriedem that should fix both the nova-status and nova-manage parts that hit the placement tables
01:31:06 mriedem i have my devstack patch updated and should fail, and then i'll apply that patch to show it passing
01:32:29 prometheanfire cool
01:35:35 mriedem and with that i need to get the hell off this computer
01:41:24 prometheanfire cya :D
01:46:17 mriedem_afk prometheanfire: yup devstack failed as expected http://logs.openstack.org/47/599847/2/check/tempest-full/d3ee11e/controller/logs/devstacklog.txt.gz#_2018-09-05_01_24_22_187
01:50:03 prometheanfire woo
02:14:11 openstackgerrit Merged openstack/nova master: Other host allocs may appear in gafpt during evac https://review.openstack.org/597301
02:17:02 openstackgerrit Sam Morrison proposed openstack/nova master: Allow ability for non admin users to use all filters on server list. https://review.openstack.org/526558
02:43:03 openstackgerrit fupingxie proposed openstack/nova master: Delete allocations for instances that have been moved to another node https://review.openstack.org/582899
03:09:52 openstackgerrit huanhongda proposed openstack/nova-specs master: Return "deleted" and "estimated_reclaim" time of instance for admin https://review.openstack.org/581638

Earlier   Later