Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-02-01
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
#openstack-nova - 2021-02-02
00:08:20 TheJulia Question, is the supports_image_type_ami driver capability flag, is that literally just supports raw partition image + kernel + ramdisk
00:18:17 dansmith TheJulia: all it means is that if the user tries to boot with an image that claims to be an ami, should we send it to you
00:18:53 dansmith TheJulia: so if that happens and we have some libvirt and some ironic and some, uh, some other hypervisor in the same cloud, we'll only consider nodes that are running drivers that claim to want to eat an ami
00:19:15 dansmith what you do with it and whether or not that's legal in all 50 states is not implied by the flag :)
00:20:50 TheJulia heh
00:21:05 TheJulia I'm just wondering if it would work because as I understand it, it should just work
00:21:36 dansmith *that* is not something I can answer
00:22:02 TheJulia Yeah, hmm maybe something to try one day
00:22:24 dansmith fwiw,
00:22:47 dansmith I barely think ami/ari/aki makes sense in a real VM type cloud, I would think it would make less sense for ironic,
00:22:59 dansmith but I don't really know why they (amazon) did it that way anyway, so..
00:26:01 TheJulia Yeah, I ended up chasing something earlier today for like 1.5 hours because someone put "aki" in instead of "qcow2"
00:26:37 dansmith PEBKAC
00:26:49 TheJulia but since we actually could just say "network boot a raw kernel/ramdisk" it could actually be a thing
00:49:29 openstackgerrit Merged openstack/nova master: Fix misleading documentation for live_migration_inbound_addr https://review.opendev.org/c/openstack/nova/+/741473
02:26:37 openstackgerrit Merged openstack/nova master: [FUP] this change removes an unused paramater https://review.opendev.org/c/openstack/nova/+/773409

Earlier   Later