| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-01 | |||
| 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 | |
| #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 | |