| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-11 | |||
| 16:09:00 | bauzas | I'm not *that* opiniated | |
| 16:09:12 | bauzas | gibi: but if you feel OK with it, please do | |
| 16:09:14 | bauzas | it doesn't harm | |
| 16:09:25 | bauzas | the more the better in this case | |
| 16:12:18 | gibi | oops, we need to merge | |
| 16:12:19 | gibi | ||
| 16:12:23 | gibi | https://review.opendev.org/c/openstack/nova/+/766720 | |
| 16:12:26 | gibi | to master first | |
| 16:12:57 | gibi | as now it is part of the squashy commit on stable/v | |
| 16:13:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: lower-constraints: Bump packaging to 20.4 https://review.opendev.org/c/openstack/nova/+/765749 | |
| 16:13:23 | gibi | bauzas: could you look at https://review.opendev.org/c/openstack/nova/+/766720 please? | |
| 16:13:27 | bauzas | done | |
| 16:13:40 | gibi | thanks | |
| 16:32:00 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit to 1.6.2 and raise hacking to 1.1.0 in LC https://review.opendev.org/c/openstack/nova/+/766171 | |
| 16:33:56 | lyarwood | okaas~. | |
| 16:34:42 | lyarwood | gah sorry ssh died | |
| 16:45:19 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: [stable-only] lower-contraints: Bump hacking to 3.0.1 and amqp to 2.5.2 https://review.opendev.org/c/openstack/nova/+/766738 | |
| 16:45:37 | lyarwood | ^ so I can't actually build these lower-constraint venvs locally thanks to virtualenv pulling in weird versions of setuptools | |
| 16:46:03 | lyarwood | I'm going to go afk for a few hours to deal with some childcare stuff and then attack this again later, with beer. | |
| 16:47:51 | sean-k-mooney | lyarwood: you can contol the version fo setup tools with a flag | |
| 16:50:27 | fungi | sean-k-mooney: i did not mean to suggest that jobs testing lower-bounds of our (transitive) dependency sets wouldn't be useful, simply that we don't have (and haven't ever had) them. when they were originally proposed i pointed out the problem is intractable without implementing it in pip or duplicating a large portion of pip's routines, but folks decided to just punt because the (in this case | |
| 16:50:29 | fungi | especially incorrect) version selections pip failed to particularly enforce were considered "good enough" | |
| 16:52:57 | sean-k-mooney | fungi: sure but i konw at least form a redhat downstream point of view lower constratis and upper constraits are not really used | |
| 16:53:48 | sean-k-mooney | they are useful but due to downstream backports and other issues outside of a pip based install they are not directly translateable to distro versions | |
| 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 | stephenfin | Is it recent? | |
| 17:22:05 | sean-k-mooney | its not backported to 13/train | |
| 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:12 | stephenfin | https://bugs.launchpad.net/nova/+bug/1907775 | |
| 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 | |