Earlier  
Posted Nick Remark
#openstack-nova - 2019-05-28
14:27:13 mriedem "availability_zone": "AZ3",
14:27:39 zigo Yes.
14:31:16 mriedem i'm not sure what that group field is in nova server show...
14:31:23 mriedem nova cli or osc?
14:32:22 zigo osc
14:32:25 mriedem zigo: do you know if this server has been moved before?
14:32:40 zigo mriedem: I don't think it has.
14:32:54 zigo It has not.
14:33:01 mriedem did you check the instance actions records?
14:34:18 zigo mriedem: Nothing except my attempts.
14:35:23 mriedem and you're sure this instance was created from that rocky deployment?
14:37:19 mriedem i think we're somehow saving off a half-baked RequestSpec.instance_group after one failed attempt maybe and then that's causing a new issue loading the group from that busted request spec where the group.uuid isn't set
14:37:25 zigo mriedem: Yes, this cloud deployment has never been using something older.
14:37:46 mriedem i.e. we're hitting https://github.com/openstack/nova/blob/stable/rocky/nova/objects/request_spec.py#L228, saving that, and then failing later here https://github.com/openstack/nova/blob/stable/rocky/nova/objects/request_spec.py#L523
14:38:02 zigo mriedem: Can I somehow just patch my request_spec db entry?
14:39:04 mriedem you'd have to load http://paste.openstack.org/show/752161/ from json, update the instance_group["nova_object.data"] and set the uuid field to "295c99ea-2db6-469a-877f-454a3903a8d8"
14:39:07 mriedem to match that group scheduler hint
14:39:13 mriedem and then serialize and update that db record
14:43:17 mriedem could also be hitting a reschedule loop which in rocky, the compute didn't pass the request spec back to conductor on reschedule (during resize/cold-migrate) so conductor has to build it's own request spec, that might be why we're only getting a half-baked version
14:45:38 mriedem anyway, i'm not sure what the recreate is, but i can definitely see where we could not have a requestspec.instance_group.uuid so we should probably have a check for that in RequestSpec._from_db_object
14:45:45 mriedem zigo: have you reported a bug?
14:46:21 zigo mriedem: I don't think I'd be a good reporter for this one, I don't know enough about the internals of this request_spec stuff to know what's going on.
14:46:29 zigo That's the first time I see this json output in fact.
14:47:05 mriedem you don't need to know the internals to report the bug, just what is happening and how you think you got here
14:47:18 zigo Ok.
14:47:31 zigo mriedem: Has nova moved to storyboard yet?
14:47:36 mriedem no
14:47:39 mriedem still lp
14:48:38 mriedem my guess is something like this happened: 1. create server in a group, 2. cold migrate the server which fails on host A and does a reschedule to host B which maybe also fails (would be good to know if previous cold migration attempts failed with reschedules), 3. try to cold migrate again which fails with the instance_group.uuid thing
14:49:30 mriedem the reschedule might be the key b/c like i said conductor has to rebuild a request spec and i think that's probably where we're doing a partial build of the request spec but missing the group uuid
14:56:23 zigo mriedem: https://bugs.launchpad.net/nova/+bug/1830747
14:56:24 openstack Launchpad bug 1830747 in OpenStack Compute (nova) "Error 500 trying to migrate an instance after wrong request_spec" [Undecided,New]
14:56:26 mriedem zigo: yup, thanks
14:56:35 zigo mriedem: I'm trying to add the uuid to the db entry, as you suggested.
15:03:06 zigo mriedem: I think it all starts with this:
15:03:06 zigo 2019-05-28 15:02:35.534 30706 ERROR nova.compute.manager [instance: ae6f8afe-9c64-4aaf-90e8-be8175fee8e4] nova.exception.UnableToMigrateToSelf: Unable to migrate instance (ae6f8afe-9c64-4aaf-90e8-be8175fee8e4) to current host (clint1-compute-5.infomaniak.ch).
15:03:40 zigo (not sure)
15:04:35 mriedem are you requesting a target host when doing the cold migration?
15:08:18 zigo Nop.
15:08:26 zigo There's 3 computes on this AZ.
15:09:03 zigo mriedem: I just migrated another VM on the same compute, and it went fine.
15:09:50 zigo For that one instance, I had request_spec: "instance_group": null
15:10:00 mriedem yeah so that server wasn't in a group
15:10:12 zigo Right.
15:10:21 zigo mriedem: Maybe I can just remove the group from that other instance then?
15:10:28 zigo (that one failing ...)
15:10:44 mriedem that would break the affinity policy for that server
15:13:01 mriedem zigo: i can generate a patch for you quick if you're in a position to try it
15:13:20 zigo I can ... :)
15:13:28 mriedem ok i'll work on something quick
15:13:43 zigo I can always apt-get install --reinstall python3-nova to go back to what it was.
15:13:50 zigo (safely)
15:14:15 zigo mriedem: I'll have to go back home in 40 minutes though.
15:15:26 openstackgerrit Merged openstack/python-novaclient master: Add a description of --on-shared-storage https://review.opendev.org/661527
15:16:13 mriedem ack, should have this up in 5 min
15:18:53 openstackgerrit Adam Spiers proposed openstack/nova master: extract baselineCPU API call from _get_cpu_traits() https://review.opendev.org/661782
15:20:12 openstackgerrit Adam Spiers proposed openstack/nova master: extract baselineCPU API call from _get_cpu_traits() https://review.opendev.org/661782
15:20:34 openstackgerrit Matthew Booth proposed openstack/nova master: Add functional test for bug 1550919 https://review.opendev.org/631294
15:20:35 openstack bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9)
15:20:35 openstackgerrit Matthew Booth proposed openstack/nova master: libvirt: Don't delete disks on shared storage during evacuate https://review.opendev.org/578846
15:22:05 aspiers kashyap: hope that refactoring is OK ^^^
15:27:36 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Workaround missing RequestSpec.instance_group.uuid https://review.opendev.org/661786
15:27:37 mriedem zigo: ^ needs tests and to be prettied up but it should workaround the issue given the request spec you showed me
15:29:00 kashyap aspiers: Hiya
15:31:20 zigo mriedem: Is this for nova-conductor ?
15:31:26 zigo In which node should I apply it?
15:31:52 mriedem api and conductor
15:32:08 zigo mriedem: Ok, then restart conductor and API, I guess ...
15:32:14 mriedem yup
15:34:18 kashyap aspiers: Nice; no test to prove that "nothing is broken" with the refactoring, I presume?
15:35:02 aspiers kashyap: the existing tests should cover it. Refactoring => no change in functionality to test :)
15:35:49 kashyap aspiers: Right
15:36:59 kashyap I like the change, it makes things clearer. (And I intend to refactor _get_guest_baseline_cpu_features() in turn later as part of the CPU modelling spec)
15:38:54 aspiers kashyap: the follow-up patch to add the SEV trait will rename _get_cpu_traits() to _get_cpu_feature_traits() and _get_cpu_traits() will wrap around it
15:40:42 kashyap aspiers: Yep, nod.
15:40:54 aspiers kashyap: coming up in a few secs
15:41:21 gibi mriedem: I've fixed your comments in https://review.opendev.org/#/c/652608/
15:41:41 zigo mriedem: I still get a 500 error ...
15:43:48 mriedem zigo: do you have a paste of the logs?
15:43:55 mriedem note i added some debug logging
15:44:01 zigo mriedem: name "LOG" is undefined ...
15:44:09 zigo Problem with the logging ... :P
15:44:24 openstackgerrit Adam Spiers proposed openstack/nova master: Provide HW_CPU_AMD_SEV trait when SEV is supported https://review.opendev.org/638680
15:44:30 mriedem ah the LOG didn't exist in rocky...
15:44:34 mriedem i'll remove the logging
15:44:57 aspiers kashyap: https://review.opendev.org/#/c/638680/15/nova/virt/libvirt/driver.py@9638
15:45:16 aspiers kashyap: keeps the SEV bit nicely separated from the CPU feature code
15:46:00 aspiers efried: this should make you happy too :)
15:46:07 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Workaround missing RequestSpec.instance_group.uuid https://review.opendev.org/661786
15:46:08 mriedem zigo: ^
15:46:13 mriedem gibi: huh i thought that was approved by now
15:46:52 efried aspiers: Sans click, I'm still gonna say "what about the HW_CPU_X86_AMD_SEV trait?"
15:47:00 kashyap aspiers: A naming nit: "_kernel_supports_amd_sev" --> "_kernel_support_for_amd_sev"?
15:47:16 aspiers efried: haha, thanks for the reminder
15:47:17 gibi mriedem: I would like to get it approved :)
15:47:25 aspiers kashyap: why?
15:47:31 efried aspiers: Maybe kashyap incorporated it in his patch, I haven't looked yet.
15:48:09 kashyap aspiers: Maybe not. It returns either true or false, so as it stands is okay :-)
15:48:14 zigo mriedem: Thanks a lot, unfortunately, I have to go, so I'll try tomorrow.
15:48:45 kashyap efried: Morning; I addressed your remarks and made them part of the older PS; and even added a note in your patch to adjust the Depends-On ID

Earlier   Later