| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-11 | |||
| 16:56:24 | fungi | the global upper-constraints.txt wasn't introduced for the benefit of distributors. in was actually introduced to allow us to freeze the exact versions we're testing with so that they don't change in stable branches, but the supposition was that pip would be able to obey that list. it holds true for our normal jobs, but lower-constraints.txt files in projects aren't calculated from a known consistent | |
| 16:56:26 | fungi | set | |
| 16:56:59 | sean-k-mooney | fungi: oh i know upper-constraits is not for distos | |
| 16:57:02 | fungi | we rely on pip to calculate our upper-constraints.txt file, and we can do that because we want new packages and pip prefers the latest version of any dependency which can satisfy everyone's requirements | |
| 16:57:53 | fungi | the lower-constraints.txt files in projects are cobbled together by hand, are incomplete, and clearly inconsistent (i always suspected, but the dep solver in pip 2.3 has proven that now) | |
| 16:57:56 | sean-k-mooney | fungi: im just observing that i have seend requirement lower the lower constirant and higher then uppeor in our product | |
| 16:58:12 | sean-k-mooney | due to backprots and other reasons | |
| 16:58:22 | sean-k-mooney | e.g. rhel shiping only one verion of a dep | |
| 16:59:42 | sean-k-mooney | fungi: i still stongly belive in co instalablity and the benifit that upper-constrits provides | |
| 17:00:20 | sean-k-mooney | but without runnign tempest on lower-constriats i dotn really trust that they work | |
| 17:00:28 | fungi | right, i don't think we ever expected to be the proxy for distributors testing their offerings. upper constraints allows us to declare what we tested with at any point in time. we attempt to track what versions of direct deps we think we're compatible with, but that's really just a best effort | |
| 17:00:51 | sean-k-mooney | fungi: we have seen our functional and unit test pass on py39 for example even thouhg nova dose not run on py 39 | |
| 17:02:18 | sean-k-mooney | fungi: i assume other are aware that eventlet still does not work properly on py39 right | |
| 17:03:10 | fungi | i hope they're aware | |
| 17:03:54 | sean-k-mooney | fungi: slightly differnet topic i know just pointing out that while functional and unit test give me some confidence in the constriat lower or otherwise without tempest it really just a best guess that it shoudl work | |
| 17:04:04 | fungi | debian's going to hit that pretty soon... 3.9 is the planned default for bullseye and release freeze starts first phases in february | |
| 17:05:11 | fungi | sean-k-mooney: yeah, and lower-bounds testing with devstack/tempest would also be entirely tractable if someone writes an inverse version sorter for pip | |
| 17:07:07 | sean-k-mooney | i think 3.9 will be the default for rhel/centos 9 too whenever that happens | |
| 17:07:12 | sean-k-mooney | well 3.9 or newer | |
| 17:12:07 | stephenfin | If someone reverts a resize, the expectation is that any data created on the instance between the resize and the revert will be lost, yeah? | |
| 17:12:32 | stephenfin | I mean, I know that will happen given how it's implemented, but I wonder if we ever documented that quirk anywhere? | |
| 17:12:55 | sean-k-mooney | if it not boot form volume yes | |
| 17:13:00 | sean-k-mooney | or rbd | |
| 17:13:13 | sean-k-mooney | if its using a qcow we wont copy it back | |
| 17:13:45 | sean-k-mooney | for rbd or bfv the data will be untoched and you wont lose anything | |
| 17:14:17 | stephenfin | Oh yeah. Boot from volume would be fine too | |
| 17:14:22 | openstack | Launchpad bug 1907179 in OpenStack Compute (nova) "resize revert will let new data lost!" [Undecided,Opinion] | |
| 17:15:24 | sean-k-mooney | one edgecase of note is what happens if we resize up then revert down for rbd? | |
| 17:15:34 | sean-k-mooney | e.g. if we go form 100G to 200G | |
| 17:15:41 | sean-k-mooney | will the rbd volume shrink? | |
| 17:16:10 | sean-k-mooney | for bfv you the root gb shoudl be ignored( well it shoudl be 0) but for RBD its used | |
| 17:16:36 | sean-k-mooney | if rbd grows the voluem which it should we cant safely shrink it on revert | |
| 17:16:44 | stephenfin | Hmm, that's a fair point. I haven't a clue tbh. Resize revert is a bit of an ugly duckling imo | |
| 17:16:48 | sean-k-mooney | unless we snapshot it | |
| 17:16:57 | sean-k-mooney | ya | |
| 17:16:59 | stephenfin | I suspect very few people, if any, use it regularly | |
| 17:17:49 | sean-k-mooney | ya, i have suggested removing it in the pastand the confrim step. for example in my recreate api propsosal | |
| 17:18:05 | sean-k-mooney | but not sure we can really do that | |
| 17:18:13 | sean-k-mooney | in the existing apis | |
| 17:18:38 | stephenfin | No really. The config option to auto-confirm after a set time is as close to that as we can get | |
| 17:18:51 | stephenfin | Implementation details leaking out of the API, ftw | |
| 17:18:52 | openstackgerrit | Merged openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Wallaby https://review.opendev.org/c/openstack/nova-specs/+/759731 | |
| 17:19:59 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.resize_confirm_window | |
| 17:20:15 | sean-k-mooney | it would be nice if we could add a -1 to that | |
| 17:20:29 | sean-k-mooney | e.g. do it imedietly | |
| 17:20:37 | sean-k-mooney | normally i would call that 0 but that is taken | |
| 17:20:54 | sean-k-mooney | the best you can do now is set it to 1 second | |
| 17:20:56 | stephenfin | Good idea | |
| 17:21:30 | stephenfin | On another bug, you can't change the AZ of the host when there are instances on it, right? | |
| 17:21:40 | sean-k-mooney | correct | |
| 17:21:44 | stephenfin | We should probably have an API check to validate that | |
| 17:21:49 | sean-k-mooney | we do | |
| 17:22:00 | stephenfin | oh | |
| 17:22:05 | sean-k-mooney | its not backported to 13/train | |
| 17:22:05 | stephenfin | Is it recent? | |
| 17:22:12 | stephenfin | https://bugs.launchpad.net/nova/+bug/1907775 | |
| 17:22:12 | openstack | Launchpad bug 1907775 in OpenStack Compute (nova) "After change Host's Availability Zone, the deployed VMs Availability Zone data(in novaapi.request_specs table) can not be updated" [Undecided,New] | |
| 17:22:13 | sean-k-mooney | *queens | |
| 17:22:40 | sean-k-mooney | stephenfin: ill see if i can find it mriadem worte it i think | |
| 17:22:51 | stephenfin | no need, I'm looking | |
| 17:25:16 | sean-k-mooney | https://github.com/openstack/nova/blob/048250a4b76c0b6a85e459f92b436c448d592235/nova/compute/api.py#L6066 | |
| 17:25:32 | stephenfin | you're faster than me | |
| 17:25:51 | sean-k-mooney | i knew roughly where to look | |
| 17:26:19 | sean-k-mooney | https://github.com/openstack/nova/commit/0ad5a64dc9ac4b1cfb8038f9171b6385fdf07f28 | |
| 17:26:51 | stephenfin | hmm, I think that's different. That prevents us renaming an aggregates AZ | |
| 17:27:03 | sean-k-mooney | https://github.com/openstack/nova/commit/8e19ef4173906da0b7c761da4de0728a2fd71e24 | |
| 17:27:06 | sean-k-mooney | sorry ^ | |
| 17:27:10 | stephenfin | but it doesn't prevent us removing a host from an aggregate (and therefore the AZ) | |
| 17:29:09 | sean-k-mooney | we do it for add https://github.com/openstack/nova/blob/048250a4b76c0b6a85e459f92b436c448d592235/nova/compute/api.py#L6164 | |
| 17:29:31 | sean-k-mooney | stephenfin: we dont do it for remove | |
| 17:30:06 | sean-k-mooney | stephenfin: we should here ish https://github.com/openstack/nova/blob/048250a4b76c0b6a85e459f92b436c448d592235/nova/compute/api.py#L6211 | |
| 17:31:33 | sean-k-mooney | i guess line 6217 actully to be consitent | |
| 17:31:40 | sean-k-mooney | and do it after the notificaion | |
| 17:32:48 | sean-k-mooney | stephenfin: so that bug is half valid. what they are doing is not supported but we are not blocking the removal | |
| 17:32:56 | sean-k-mooney | it should be 1 line + tests however | |
| 17:32:59 | stephenfin | agreed | |
| 17:33:04 | stephenfin | I'm just creating a test now | |
| 17:33:06 | stephenfin | Easy win | |
| 17:33:27 | sean-k-mooney | i wonder why we did add but not remove in the first place | |
| 17:33:44 | stephenfin | not sure. It's very strange | |
| 17:33:56 | stephenfin | surprised no one has noticed before either | |
| 17:35:30 | sean-k-mooney | people dont do this often and we have a giant warning in the docs | |
| 17:36:54 | stephenfin | we do? | |
| 17:37:05 | stephenfin | about what? messing with AZs on hosts with instances? | |
| 17:37:49 | sean-k-mooney | ya i think spcificaly about moving host | |
| 17:39:55 | sean-k-mooney | https://docs.openstack.org/nova/latest/admin/availability-zones.html#implications-for-moving-servers | |
| 17:40:10 | sean-k-mooney | its got its own section | |
| 17:40:39 | sean-k-mooney | actully that not quite what i was thinking of | |
| 17:42:41 | sean-k-mooney | that partly covers it but i though we had addtion info specific to move compute nodes | |
| 17:43:35 | sean-k-mooney | hum i guess we dont | |
| 17:50:12 | stephenfin | sean-k-mooney: should you be allowed to add a host to an aggregate when it has instances on it? | |
| 17:50:58 | sean-k-mooney | no because if its not in an az it would be in an implcit nova az right | |
| 17:51:06 | stephenfin | good point | |
| 17:51:07 | sean-k-mooney | so that would result itn the instance moving az | |
| 17:51:27 | stephenfin | I was going to say it won't be in an AZ, but it will. The implicit one, as you note | |
| 17:51:31 | sean-k-mooney | it might be ok provide they dont have an explict nova request | |
| 17:51:46 | stephenfin | we tell people not to do that, iirc | |
| 17:52:16 | sean-k-mooney | yep here https://docs.openstack.org/nova/latest/admin/availability-zones.html | |
| 17:52:21 | sean-k-mooney | the warning at the top | |
| 17:52:39 | sean-k-mooney | but thats the edgecase you are hitting if you allow it | |