Earlier  
Posted Nick Remark
#openstack-nova - 2021-02-01
14:44:21 gibi dansmith: looking
14:44:27 sean-k-mooney dansmith: i assume we are not doing that policy file upstae in [post-config| /etc/glance/policy.json]
14:44:29 sean-k-mooney for some reason
14:44:58 sean-k-mooney the default policy file shoudl be empty
14:45:29 sean-k-mooney also i guess at somepoint that need to be a policy.yaml file
14:46:04 lyarwood would post-config bounce the service?
14:46:17 sean-k-mooney no but it runs before its started
14:46:22 sean-k-mooney so it does not need too
14:46:43 sean-k-mooney post-config is after all the files are generated but before the services are started for the first time
14:47:03 sean-k-mooney excluddign rabbit and mariadb which start before post-config for reasons
14:47:04 lyarwood ah understood
14:47:32 sean-k-mooney if that was doing something more complicated post-cofnig would not work
14:47:52 sean-k-mooney but for this i think it would and they could then override it by inheriting form the job if they needed too
14:48:13 sean-k-mooney as a quick fix however that will work hence +1
14:50:13 openstackgerrit Lee Yarwood proposed openstack/nova master: Add regression test for bug #1908075 https://review.opendev.org/c/openstack/nova/+/766976
14:50:15 openstackgerrit Lee Yarwood proposed openstack/nova master: fup: Merge duplicate volume attachment checks https://review.opendev.org/c/openstack/nova/+/773380
14:50:15 openstackgerrit Lee Yarwood proposed openstack/nova master: api: Reject volume attach requests when an active bdm exists https://review.opendev.org/c/openstack/nova/+/768472
14:50:15 openstack bug 1908075 in OpenStack Compute (nova) "Nova allows a non-multiattach volume to be attached to multiple instances *if* its volume state is reset by an admin" [Undecided,New] https://launchpad.net/bugs/1908075 - Assigned to Lee Yarwood (lyarwood)
14:52:16 gibi dansmith: done
15:03:32 openstackgerrit sean mooney proposed openstack/nova master: [FUP] this change removes an unused paramater https://review.opendev.org/c/openstack/nova/+/773409
15:03:40 dansmith gibi: thanks
15:03:59 sean-k-mooney FYI that ^ is really trivial if we can merge that quickly
15:04:51 sean-k-mooney lyarwood: i asked you about squash merging it into the backport of the original patch. are you still ok with that
15:05:10 sean-k-mooney lyarwood: if so ill repin those now
15:08:30 lyarwood sean-k-mooney: yup that's fine, lets land this first and then respin the backports
15:08:53 sean-k-mooney ok ill hold off then untill its merged on master
15:13:49 sean-k-mooney dansmith: are you still finding gerrit slow. currently im having the same multi second post behavior you were having when submitting comments
15:14:03 dansmith sean-k-mooney: yeah
15:14:15 dansmith sean-k-mooney: apparently that's just "how it is" with the new version of gerrit
15:14:19 sean-k-mooney ok so its not on my end so.
15:14:21 sean-k-mooney ack
15:14:27 dansmith suspected because they now use git as their db (!)
15:14:55 sean-k-mooney i wonder if that menas its more disk io sensitive then it used to be
15:15:30 sean-k-mooney im sure storing the data in git has proably resulted in more updates for that
15:15:33 dansmith it is, a lot
15:16:27 sean-k-mooney we need to get intel,samsung or micron to donate some fast ssds to infra :)
15:56:41 openstackgerrit Merged openstack/nova master: libvirt: Use specific user when probing encrypted rbd disks during extend https://review.opendev.org/c/openstack/nova/+/772869
16:00:45 openstackgerrit Lee Yarwood proposed openstack/nova stable/victoria: libvirt: Use specific user when probing encrypted rbd disks during extend https://review.opendev.org/c/openstack/nova/+/773443
16:01:07 openstackgerrit Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Use specific user when probing encrypted rbd disks during extend https://review.opendev.org/c/openstack/nova/+/773444
16:02:01 supamatt sean-k-mooney: I'd talk to Koxia and see if they want to sponsor our lab with storage ssd's lol
16:11:53 openstackgerrit Balazs Gibizer proposed openstack/nova stable/ussuri: Warn when starting services with older than N-1 computes https://review.opendev.org/c/openstack/nova/+/770764
16:11:54 openstackgerrit Balazs Gibizer proposed openstack/nova stable/ussuri: Add upgrade check about old computes https://review.opendev.org/c/openstack/nova/+/770765
16:26:27 ganso Hi Nova folks! Quick question: is there any way to migrate a VM that is in an affinity group without using the deprecated --live option? I have 2 VMs in the same host, they're in the same affinity group, and trying to move either (without --live) results in "No valid host". My main concern is, when that option is removed will there be no way to migrate those VMs?
16:28:14 supamatt ganso: try with --os-compute-api-version 2.11
16:30:32 ganso supamatt: I'm actually already using --os-compute-api-version 2.30 to use the --host parameter. I still get "No valid host"
16:31:30 supamatt okay so try 2.11
16:32:40 ganso supamatt: same error
16:33:05 supamatt you may want to check the nova scheduler logs and see whats going on
16:33:49 ganso supamatt: already did, "Filter ServerGroupAffinityFilter returned 0 hosts"
16:34:14 ganso which brings me back to my first question
17:59:36 sean-k-mooney ganso: you would need to force the migration
18:00:06 ganso sean-k-mooney: with the deprecated option --live <host> ?
18:00:06 sean-k-mooney ganso: i dont think there is any supported way beyond that
18:00:16 sean-k-mooney ganso: hat release of nova are you deploying
18:00:21 sean-k-mooney *what
18:00:36 ganso sean-k-mooney: stein
18:00:45 sean-k-mooney im pretty sure you would need to disable the compute node late affinity check
18:00:57 sean-k-mooney and i think you need to pass a --force option
18:01:39 ganso sean-k-mooney: it works with --live <host>. But my concern is that this option is deprecated. Has it been removed from a later release or planned to be removed?
18:01:40 sean-k-mooney ganso: so you would have to set this to true https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_group_policy_check_upcall
18:02:26 sean-k-mooney ganso: it has been removed in a later microversion yes
18:02:30 sean-k-mooney its still in the api
18:02:37 sean-k-mooney but not with the latest version
18:03:21 sean-k-mooney ganso: basically there no fully supported way to move vms in a server affinity group
18:03:35 sean-k-mooney we cant do a group migration for example
18:04:09 sean-k-mooney the best you could do without forcing the migration would likely be to shelve all vms in the server group
18:04:26 sean-k-mooney then unsleve them
18:04:54 sean-k-mooney thats a specualtion and not something i have tested by the way
18:05:11 sean-k-mooney i guess if you shelved all but 1 of the vms you could live migrate it too and then unshelve the rest
18:05:32 ganso sean-k-mooney: but then the VMs have to be shut down. If the main point was do have a live-migration, it cannot be shelved
18:05:35 sean-k-mooney but server affinity basically disbales move operations
18:06:03 ganso sean-k-mooney: yea that's exactly what I realized :\
18:06:25 ganso sean-k-mooney: thanks!
18:06:36 sean-k-mooney so using the deprecated options you can force the migration but then you are violating the policy
18:06:45 sean-k-mooney since you can move them all at once
18:08:28 sean-k-mooney ganso: by the way we removed the ablity to do force live migration in 2.68 https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id62
18:08:36 sean-k-mooney and it was added in 2.30
18:09:23 ganso sean-k-mooney: as long as v2 is not removed (I guess this will take a while), it will still be able to be used I assume
18:09:37 ganso just need to specify a lower microversion in the CLI
18:10:24 sean-k-mooney so this is the release note for the removal https://github.com/openstack/nova/blob/master/releasenotes/notes/remove-live-migrate-evacuate-force-flag-cb50608d5930585c.yaml
18:11:33 sean-k-mooney i belive we cap the ablity to force migration with 2.30-2.67
18:13:36 sean-k-mooney ganso: http://paste.openstack.org/show/802192/
18:14:26 sean-k-mooney so you need to do "nova --os-compute-api-version=2.30 live-migration --force <server> <host>"
18:14:44 ganso sean-k-mooney: yes, it will still work as long as I need a funcionality >2.68 in the same API call
18:14:51 ganso as long as I *don't need
18:14:57 sean-k-mooney ganso: i belive we intentionally do not support it with the openstsck client
18:15:33 sean-k-mooney ganso: well in very rare cases we also drop all compatiablity for older microversions
18:15:39 ganso sean-k-mooney: I've been using the openstack client, and it is slightly different there. The parameter name is "--live" instead of "--force". Where "--live" uses that force behavior, and "--live-migration" uses the non-forced behavior
18:16:04 sean-k-mooney ah right correct
18:17:03 sean-k-mooney v4
18:17:10 sean-k-mooney we had a v3 already which we then deleted
18:17:41 sean-k-mooney ganso: we only drop all support if we are fully removing a subsystem
18:18:07 sean-k-mooney ganso: for example when we removed nova-networks or xenapi code entirely
18:18:50 ganso ah great then it is going to be fine \o/
18:19:16 sean-k-mooney yep untill we do a v3/4 which wont be anytime soon if ever
18:19:39 sean-k-mooney that said we are getting close to 2.100 so at somepoint we proably should
18:23:00 openstackgerrit Merged openstack/nova master: Restart glance after updating policy in job https://review.opendev.org/c/openstack/nova/+/773192
18:23:32 openstackgerrit Merged openstack/nova master: vmware tests: Support different moref backend representations https://review.opendev.org/c/openstack/nova/+/749488
20:18:21 openstackgerrit Merged openstack/nova master: Raise 409 when removing security group from instance https://review.opendev.org/c/openstack/nova/+/735572
22:57:50 openstackgerrit Ghanshyam proposed openstack/nova master: DNM:try l-c with direct deps https://review.opendev.org/c/openstack/nova/+/772780

Earlier   Later