Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-07-14
08:12:21 opendevreview Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913
08:12:23 opendevreview Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147
08:42:36 gibi stephenfin: can we get this in https://review.opendev.org/c/openstack/os-resource-classes/+/796591 I'd like to get a os-release-classes lib released as neutron also needs this
09:34:21 opendevreview Merged openstack/os-resource-classes master: Add packet rate related resource classes https://review.opendev.org/c/openstack/os-resource-classes/+/796591
10:21:26 opendevreview Stephen Finucane proposed openstack/nova master: Use neutronclient's port binding APIs https://review.opendev.org/c/openstack/nova/+/706295
10:21:27 opendevreview Stephen Finucane proposed openstack/nova master: fixtures: Raise HTTP 409 if binding is already active https://review.opendev.org/c/openstack/nova/+/800767
10:21:49 stephenfin gibi: Respun that again (hopefully the last time) if you care to take a look ^
10:23:16 gibi on it
10:23:21 stephenfin ta
10:26:25 gibi done
10:26:37 gibi thanks for fixig the todo I left in the fixture
10:28:14 opendevreview Takashi Kajinami proposed openstack/nova master: Clean up allocations left by evacuation when deleting service https://review.opendev.org/c/openstack/nova/+/778696
10:33:43 opendevreview Takashi Kajinami proposed openstack/nova master: Clean up allocations left by evacuation when deleting service https://review.opendev.org/c/openstack/nova/+/778696
10:36:08 opendevreview Takashi Kajinami proposed openstack/nova master: Clean up allocations left by evacuation when deleting service https://review.opendev.org/c/openstack/nova/+/778696
10:47:14 opendevreview Balazs Gibizer proposed openstack/placement master: Move placement specs from nova https://review.opendev.org/c/openstack/placement/+/800769
11:32:02 sean-k-mooney stephenfin: if the recheck fails on https://review.opendev.org/c/openstack/os-vif/+/798055 ill adress the remaining typos
11:32:46 sean-k-mooney otherwise ill fix them in a followup when i start working on the trunk bridge deletion bug.
12:04:14 opendevreview Balazs Gibizer proposed openstack/nova-specs master: Move placement specs to placement repo https://review.opendev.org/c/openstack/nova-specs/+/800775
12:05:45 gibi melwitt: I think the best is to move the placement targeting specs to the placement repository. So I proposed a nova-specs and a placement patch to do so
12:05:48 gibi melwitt: https://review.opendev.org/c/openstack/nova-specs/+/800775
12:05:55 gibi melwitt: https://review.opendev.org/c/openstack/placement/+/800769
12:09:33 sean-k-mooney was that motivated by my comment on melwitt's consumer types path
12:09:36 sean-k-mooney *patch
12:11:55 gibi sean-k-mooney: I already detected my mistake when we merged my re-parent RP spec
12:12:03 gibi sean-k-mooney: just haven't had the time to do the move since
12:46:04 gibi \
13:03:20 opendevreview Stephen Finucane proposed openstack/nova master: db: Final cleanups https://review.opendev.org/c/openstack/nova/+/800484
14:45:16 gibi sean-k-mooney: I looked through the cyborg smartnic impl. I do miss the part when the smartnic arq triggers a piece of domain xml generated to pass through a VF. The flavor based arqs are handled via the arq uuids passed to the libvirt driver but the smartnic impl does not pass the smartnic arqs this way. Does this xml generation happens becuase of the port has some pci info in the bindig profile?
14:48:19 gibi the last bullet in the spec https://specs.openstack.org/openstack/nova-specs/specs/xena/approved/support-sriov-smartnic.html#nova seems to confirm my above guess
15:26:17 melwitt gibi: ack will review them, thanks for doing that
15:32:11 gibi melwitt: thanks
15:46:09 mnaser hmm, i ran into an interesting scenario. i have 2 az in a cloud with cross_az_attach=False, everything works as expected, but for bfv, since a volume type is only available in a specific az, volumes go to 'error' right away
15:47:08 mnaser would this be a 'cinder' bug technically because nova is requesting a volume with no type included but az=<foobar> and it's going to the default that is not available in az=<foobar> ?
15:48:33 mnaser yeah, i think that's more of a cinder thing now that i'm writing it out.. i'll take it there if anyone is curious
15:56:12 opendevreview Balazs Gibizer proposed openstack/placement master: Add support for RP re-parenting and orphaning https://review.opendev.org/c/openstack/placement/+/784020
15:56:24 gibi sean-k-mooney: I fixed nits and replied to your comment in ^^
15:56:55 NobodyCam morning Nova Folks.. I have a instance that is stuck in build state. it shows up with openstack server list. But I get "No server with a name or ID" when attempting to run a openstack server show.. would anyone be able to point me in the right direction to remove this failed instance
15:59:58 melwitt NobodyCam: you might have an orphaned build_requests record for the instance. if you have one of those records and no instance_mappings record for the instance, you will need to delete the build_requests record from the database manually
16:00:16 melwitt these tables are both in the nova_api database
16:00:54 NobodyCam ahh Thank you melwitt !!
16:01:09 NobodyCam been looking at nova db. haven't even looked at the api side ;p
16:06:25 melwitt was this bug https://bugs.launchpad.net/nova/+bug/1784093
16:06:25 melwitt NobodyCam: yeah.. you likely don't have any trace of the instance in the nova db. usually the reason you can see the instance in the 'server list' but not the 'server show' is because 'server list' will count build_requests as instances as well in order to preserve the behavior where you can see an instance immediately after you request to boot it. but if there's no instance_mappings record, nova will think it can't find anything. it
16:06:37 melwitt are you running a version older than queens?
16:09:16 NobodyCam actually in this region it is Queens, it's in process of migrating to ussuri but not complete yet
16:10:35 melwitt hm, ok. there might be another corner case but ^ was the most common one
16:11:22 melwitt released in 17.0.11
16:20:31 NobodyCam Interesting not in build_requests but did find reference to the instance_id in instance_mappings table in nova_api DB
16:24:00 melwitt oh, so the inverse? hm
16:25:21 NobodyCam I should not this region had a network outage, caused some strange things, I am attempting to recover
16:25:32 NobodyCam snot/note/
16:26:11 melwitt I need to go back through and look at all those again, there's some places where if one db write succeeds while another fails, you get these bad states
16:26:28 NobodyCam Safe to just nuke the instance_mapping record?
16:27:25 melwitt yeah, I'd make sure it's not in nova.instances and then delete nova_api.instance_mappings, nova_api.request_specs for the instance uuid
16:27:58 NobodyCam : thumbs_up :
16:42:19 NobodyCam Thank you melwitt I think this will get things back on track for us!
16:43:22 melwitt np, good luck
17:18:27 gmann gibi: dansmith replied on these comment for 'project admin getting hypervisor uuid spec' https://review.opendev.org/c/openstack/nova-specs/+/793011/3/specs/xena/approved/allow-project-admin-list-hypervisors.rst#43
17:18:29 gmann gibi: dansmith https://review.opendev.org/c/openstack/nova-specs/+/793011/3/specs/xena/approved/allow-project-admin-list-hypervisors.rst#49
17:18:54 gmann can you please confirm/reply for those, accordingly I will update spec
17:20:07 gmann sorry for responding late on this
17:31:27 opendevreview melanie witt proposed openstack/nova stable/train: [CI] Fix gate by using zuulv3 live migration and grenade jobs https://review.opendev.org/c/openstack/nova/+/795435
17:33:09 opendevreview Stephen Finucane proposed openstack/nova master: nova-manage: Introduce bdm show, refresh, get_connector commands https://review.opendev.org/c/openstack/nova/+/800634
18:25:38 opendevreview Ghanshyam proposed openstack/nova-specs master: Allow project admin to list hypervisors https://review.opendev.org/c/openstack/nova-specs/+/793011
18:26:05 gmann dansmith: ^^ updated
18:28:31 dansmith gmann: okay just to be clear, you're planning to accept the uuid as the hostname, in the same field, and without a microversion for that?
18:28:55 gmann dansmith: yeah.
18:29:47 dansmith okay I guess I dunno about the legitimacy of that.. because someone won't be able to know whether a nova is new enough to accept that behavior. it's not a structural change in the request/response, but it is a different behavior that they won't know if they can use or not, right?
18:31:23 gmann dansmith: humm, behavior wise yes it is changed..
18:32:42 dansmith yeah, so I dunno, probably best to get someone else's opinion on the matter, but it sure seems like that should go hand-in-hand with the microversion to expose it
18:34:25 gmann issue with microversion bump is then it would not be aligned with policy change which are without microversion.
18:34:48 sean-k-mooney why are we over loading the filed
18:35:00 gmann I think booting server with uuid will end up with error ?
18:35:06 sean-k-mooney i can kid of understand at the osc level allowign --host
18:35:12 gmann currently
18:35:13 sean-k-mooney to be the uuid or hostname
18:35:25 gmann humm
18:35:25 sean-k-mooney but at the api that feels weird to me
18:35:55 gmann testing here https://review.opendev.org/c/openstack/tempest/+/793632
18:36:06 sean-k-mooney we have instance of this i think for instnace show or flavor show where you can pass the name or uuid
18:37:22 sean-k-mooney but i kind of assume we were goning to add a new filed for this
18:38:18 sean-k-mooney its that not we ment by https://review.opendev.org/c/openstack/nova-specs/+/793011/4/specs/xena/approved/allow-project-admin-list-hypervisors.rst#97
18:38:36 gmann sean-k-mooney: for this case, we are thinking to allow in same field and that is why interop issue
18:38:56 sean-k-mooney well we said we would accpet hypervisor-uuid now
18:39:09 sean-k-mooney so that is a new field no?
18:39:17 sean-k-mooney i have not been following this closely sorry
18:39:42 gmann sean-k-mooney: no, in same field like in 'availability_zone' az:noda:host host as uuid
18:40:00 gmann if new field then sure we need microversion bump
18:41:10 sean-k-mooney i kind of feel like this should be a micoverion bump
18:41:48 sean-k-mooney i mean its unlikely you are suing uuids for your hypervior host names but it would have been allowed before
18:41:57 sean-k-mooney actully dont we do that for ironic
18:42:17 sean-k-mooney the hypervior_hostname is the ironic node uuid
18:42:56 dansmith but that is the actual hostname we record,
18:42:58 dansmith so it's different
18:43:05 sean-k-mooney so if we reuse the same filed dont we have the possibliyt of a uuid colission even thought that wont happen in reality
18:43:15 opendevreview Merged openstack/nova master: Use neutronclient's port binding APIs https://review.opendev.org/c/openstack/nova/+/706295
18:43:48 sean-k-mooney dansmith: well for ironic server the hypervior hostname for each server is the uuid right
18:44:18 dansmith right, that's my point.. so it's not like there's prior art for making them interchangeable, it's that we actually record the uuid *as* the hostname in that case
18:44:38 sean-k-mooney yes
18:44:57 sean-k-mooney do we also make the compute node uuid match the host name for ironic?

Earlier   Later