| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-04 | |||
| 15:54:34 | mriedem | it doesn't have any state as far as i can tell | |
| 15:54:49 | mriedem | unlike SchedulerReportClient which does have some state | |
| 15:55:11 | efried | It must not have state, since we were able to cache it before with no ill effects | |
| 15:55:22 | efried | unless the state was added in the interval when we had removed the caching. | |
| 15:55:30 | mriedem | the neutron sg api you mean | |
| 15:55:37 | stephenfin | Makes sense to me. I can rework that patch accordingly | |
| 15:56:24 | stephenfin | though I'll hold off for now since that queue is approaching x-cell resize size and will kill CI if pushed | |
| 15:56:28 | stephenfin | RIP CI | |
| 15:57:25 | mriedem | the bottom 5 or so changes can use another core | |
| 15:57:33 | stephenfin | mriedem: While I have you, is this the correct thing to do? https://review.opendev.org/#/c/697152/2/doc/api_samples/os-quota-class-sets/quota-classes-show-get-resp.json | |
| 15:58:06 | stephenfin | I assume we don't support arbitrary quota classes so we can't modify the output for older microversions | |
| 15:58:37 | stephenfin | ...meaning I have to fake those nova-net'y quotas rather than just dropping them | |
| 15:58:41 | mriedem | i'm pretty sure we only support one quota class, 'default' | |
| 15:59:02 | stephenfin | sorry, arbitrary quotas...types? | |
| 15:59:20 | mriedem | yeah you can't create random quota types | |
| 16:00:03 | salmankhan | HI guys, I am facing an issue if someone can help. I upgraded the nova queens api from xenial to bionic and I am not able to see network info in "nova show" or "openstack server show" commands. However I can see the network details on dashboard or "nova interface-list" or "openstack port show" commands. Doesn't look like a database issue, but may be. If I reboot a instance there is no interface attached as well. What could be | |
| 16:00:04 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/quota_sets.py#L29 | |
| 16:00:51 | stephenfin | so I do have to keep them. okidok | |
| 16:00:59 | mriedem | that said, i'm not sure about what you're doing there with just changing all the network quota values to -1 | |
| 16:01:41 | stephenfin | that's what the noop driver was doing (unlimited) and those things are noops now | |
| 16:01:43 | stephenfin | so... | |
| 16:01:45 | openstackgerrit | Merged openstack/nova master: Add QoS tempest config so bw tests run https://review.opendev.org/697180 | |
| 16:02:02 | mriedem | the noop quota driver is just for testing | |
| 16:02:07 | mriedem | or nfv single tenant i guess | |
| 16:02:39 | mriedem | i agree that we can't just remove them from the responses and stuff without a microversion since it changes the schema | |
| 16:03:08 | mriedem | we don't proxy enforcement of those to neutron at all do we? | |
| 16:03:20 | mriedem | i know there was talk of doing that back in like havana | |
| 16:03:25 | stephenfin | nope, they're dead | |
| 16:03:38 | stephenfin | all DB model driven | |
| 16:05:36 | mriedem | yeah, i mean the -1 is a lie because we're not enforcing those. we did deprecate them from the apis in 2.35 and 2.49 and they were a lie before if using neutron anyway - you could change security group rules quota to 500 in nova and it wouldn't apply to neutron | |
| 16:06:15 | melwitt | re: the noop quota driver, I had thought that was the way for a deployment that doesn't care about quotas to bypass all the calculating (perf impact). so I was thinking not to remove it because of that. am I missing something? | |
| 16:06:45 | mriedem | how many deployments besides nfv single tenant don't care about quota? | |
| 16:08:19 | stephenfin | If -1 is a lie, what do I return instead? Just 0? | |
| 16:08:35 | stephenfin | I have to return _something_ | |
| 16:10:45 | mriedem | it's all a lie is my point i think, so -1 is probably good enough | |
| 16:11:11 | mriedem | i'm just not sure how clearly i'm thinking about this atm, or what alternatives there are | |
| 16:11:31 | mriedem | i defer to dansmith | |
| 16:11:36 | mriedem | o-) | |
| 16:12:05 | dansmith | I don't know about quota things | |
| 16:12:09 | dansmith | I defer to melwitt | |
| 16:15:08 | melwitt | I'll take a look at it | |
| 16:15:52 | salmankhan | fine. | |
| 16:15:52 | salmankhan | Anyone??? HI guys, I am facing an issue if someone can help. I upgraded the nova queens api from xenial to bionic and I am not able to see network info in "nova show" or "openstack server show" commands. However I can see the network details on dashboard or "nova interface-list" or "openstack port show" commands. Doesn't look like a database issue, but may be. If I reboot a instance there is no interface attached as well. Wha | |
| 16:17:35 | mriedem | the instance network info cache is probably missing | |
| 16:17:58 | salmankhan | how can it be fixed | |
| 16:18:02 | mriedem | check the instance_info_caches.network_info column for that instance | |
| 16:18:26 | mriedem | on queens....i'm not sure | |
| 16:18:32 | mriedem | there is a periodic that would heal it starting in i think stein | |
| 16:18:49 | mriedem | see https://review.opendev.org/#/c/679274/ | |
| 16:20:26 | mriedem | you could also take a look at this https://review.opendev.org/#/c/640516/ | |
| 16:20:55 | mriedem | "If someone comes forward saying "yes this fixes a thing I'm hitting" then I'd be willing to restore it." | |
| 16:21:38 | mriedem | that second patch won't help you on queens since it relies on the force_refresh kwarg from the previous patch | |
| 16:21:53 | sean-k-mooney | mriedem: for what its worth we have backported only the periodic heal downstream | |
| 16:22:06 | mriedem | super | |
| 16:22:09 | sean-k-mooney | we did not backport the data migration | |
| 16:22:18 | sean-k-mooney | because that caused other issues | |
| 16:22:19 | mriedem | and canonical is going to as well it looks like | |
| 16:23:02 | sean-k-mooney | we have it all the way back to newton at this point | |
| 16:23:31 | sean-k-mooney | although we only did newton in the last month | |
| 16:23:34 | salmankhan | So you saying apply this 679274, that could fix on queens? | |
| 16:24:18 | sean-k-mooney | only if you have fixed teh underlying network issue | |
| 16:24:51 | sean-k-mooney | this only happens if there was an external failure that casued the cache to be curropted | |
| 16:25:43 | salmankhan | I messed up with neutron ports policy and that probably corrupted the cache, I think. | |
| 16:25:57 | salmankhan | though I have fixed that policy | |
| 16:25:57 | sean-k-mooney | yep that is one of the know ways to cause it | |
| 16:26:27 | sean-k-mooney | if the neutron policy.json is miss configured an empty list will be returned form neutron | |
| 16:26:33 | sean-k-mooney | and then we update the caceh with that | |
| 16:26:50 | sean-k-mooney | if that has been fixed the back can fix that | |
| 16:27:11 | salmankhan | ok, :finger_crossed: going to apply 679274 and see. | |
| 16:32:55 | stephenfin | dansmith: Any idea what could cause this test to fail? https://zuul.opendev.org/t/openstack/build/c598788184854780b2494a45b42a9718/console | |
| 16:33:07 | stephenfin | (from https://review.opendev.org/697156) | |
| 16:33:58 | dansmith | mucking around with the registry | |
| 16:34:01 | dansmith | oh | |
| 16:34:14 | stephenfin | I thought maybe I'd removed an object that was referenced from another object, but it doesn't seem like I have | |
| 16:34:22 | dansmith | stephenfin: did you maybe remove or not register an object? | |
| 16:34:39 | stephenfin | I removed objects, yes | |
| 16:34:47 | stephenfin | But I've removed all references to those objects, fwict | |
| 16:34:48 | dansmith | did you remove one that you didn't remove from the test_objects list of hashes? | |
| 16:35:44 | dansmith | unrelated to your failure, did we talk about removing objects already? | |
| 16:35:48 | stephenfin | grep doesn't bring up any matches for the removed objects in 'nova/tests/unit/objects/' | |
| 16:36:18 | stephenfin | I think so. You've to keep the DB models if it's persistent for a cycle or two, but the objects can go | |
| 16:36:21 | stephenfin | I think... | |
| 16:37:53 | dansmith | so, removing these objects will mean that if anything sends us one over the wire, we will completely fail, | |
| 16:38:08 | dansmith | and obviously things stop being able to run remotable methods if they're not upgraded | |
| 16:38:55 | stephenfin | Then I will triple check, but I think the only thing that could have sent these over the wire was nova-network, and that has been non-functional for at least a cycle now | |
| 16:39:13 | dansmith | stephenfin: no, I think api would send them in some cases wouldn't it? | |
| 16:39:44 | dansmith | note I'm not saying we should keep them necessarily, just trying to think aloud | |
| 16:40:02 | stephenfin | yup, I get ya. Checking now myself | |
| 16:41:41 | stephenfin | Yeah, leave it with me. I'll check my queue of patches and see if any of those objects could get through to the APIs. I'll state whatever I find in the commit message | |
| 16:56:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add node owner pre-filter https://review.opendev.org/697187 | |
| 16:56:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: ironic: report a custom trait for the node owner https://review.opendev.org/697184 | |
| 16:56:47 | mriedem | efried: i wrote a functional test for ^ and it shows what i suspected - traits aren't going to work | |
| 16:56:49 | mriedem | not enough context | |
| 16:57:11 | efried | mriedem: yeah, I was noodling that yesterday and I concur it would be pretty tough to do. | |
| 16:57:50 | efried | mriedem: If you had a I_AM_IRONIC trait, and Placement had a ?required_if=CUSTOM_OWNER_XXX:I_AM_IRONIC syntax.... | |
| 16:58:19 | mriedem | and bingo bango you have metadata in placement :) | |
| 17:05:41 | sean-k-mooney | im pretty sure when i raised the idea of key:value traits in the past it was shot down pretty hard | |
| 17:10:59 | dansmith | please god no | |
| 17:11:47 | sean-k-mooney | yep that was the reaction back then too | |
| 17:18:57 | efried | I was not seriously proposing that. | |