Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-12-04
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 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:15:52 salmankhan fine.
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 sean-k-mooney yep that is one of the know ways to cause it
16:25:57 salmankhan though I have fixed that policy
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: ironic: report a custom trait for the node owner https://review.opendev.org/697184
16:56:45 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add node owner pre-filter https://review.opendev.org/697187
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.
17:19:13 efried forgot my /s
17:26:49 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add NodeOwnerFilter https://review.opendev.org/697331
18:51:16 salmankhan sean-k-mooney: Thanks mate! This fix worked for me https://review.opendev.org/#/c/679274/

Earlier   Later