| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-04 | |||
| 20:05:19 | cdent | mriedem: is it normal for there to be NovaExceptions that we would want to only print? | |
| 20:05:27 | mriedem | i'd say no | |
| 20:05:28 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Configure placement DB context manager for online_data_migrations https://review.openstack.org/599744 | |
| 20:05:31 | mriedem | i've removed it | |
| 20:05:36 | cdent | huzza | |
| 20:05:37 | mriedem | ^ is the old squasharoo | |
| 20:05:37 | cdent | h | |
| 20:06:52 | mriedem | oops guess i missed that in the squash | |
| 20:08:55 | melwitt | mriedem: I mean I could add a fake_network.set_stub_network_methods(self) all to my test instead of backporting the changes that removed all of those calls | |
| 20:08:59 | melwitt | *call | |
| 20:12:44 | mriedem | melwitt: you mean like *add* to your backport test what was removed from here right? https://review.openstack.org/#/c/599764/1/nova/tests/functional/db/test_archive.py | |
| 20:12:48 | mriedem | melwitt: if so, then yes just do that | |
| 20:12:56 | mriedem | the neutron fixture backport is very weird otherwise | |
| 20:13:25 | melwitt | mriedem: yes, add fake_network.set_stub_network_methods(self) to my backport test | |
| 20:13:29 | melwitt | k | |
| 20:13:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Configure placement DB context manager for online_data_migrations https://review.openstack.org/599744 | |
| 20:14:18 | mriedem | prometheanfire: ^ should make your dreams finally come true | |
| 20:15:01 | prometheanfire | mriedem: mostly, 'nova-status upgrade check' still shows a warning | |
| 20:15:11 | mriedem | paste me | |
| 20:15:12 | prometheanfire | but online migrations work (with nothing migrated) | |
| 20:15:42 | prometheanfire | mriedem: http://paste.openstack.org/show/729448/ | |
| 20:17:39 | prometheanfire | mriedem: I thought sean-k-mooney mentioned that being a false positive or something though | |
| 20:19:49 | mriedem | hmm, how many nodes are shown with nova hypervisor-list? | |
| 20:22:41 | prometheanfire | 2 | |
| 20:24:32 | mriedem | and how many in openstack resource provider list? | |
| 20:26:03 | prometheanfire | 2 | |
| 20:28:25 | mriedem | hmm, looks like we have a bug then | |
| 20:28:35 | mriedem | you want to write that up? | |
| 20:29:00 | prometheanfire | sure | |
| 20:29:14 | prometheanfire | I think this one is not pike only, I think I saw this in queens too | |
| 20:29:20 | prometheanfire | maybe more, not sure | |
| 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 | openstack | Launchpad bug 1790721 in OpenStack Compute (nova) "nova-status upgrade check shows warnings when it shouldn't" [Undecided,New] | |
| 20:34:28 | prometheanfire | https://bugs.launchpad.net/nova/+bug/1790721 | |
| 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 | prometheanfire | in _count_compute_resource_providers | |
| 20:37:27 | mriedem | we do hit the API to check that we can *talk* to placement | |
| 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 | openstack | Launchpad bug 1750669 in OpenStack Identity (keystone) "The v3 grant API should account for different scopes" [High,Triaged] | |
| 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 | |