Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-12-11
15:54:15 melwitt gibi: that was nice of it :)
15:54:18 sean-k-mooney :) hehe helpful editors strike again
15:54:47 gibi I'm not even mad, it is soo friday and soo many fires
15:57:06 sean-k-mooney ya if that is the most pressing problem on a friday its not bad. hopefully the rest wont take you too long or can wait till monday
15:59:20 gibi sean-k-mooney: master is unblocked and the stable/v unblocking patch is going forward again. So yeah I will sleep well tonight
16:03:03 melwitt bauzas: could you take a look at https://review.opendev.org/c/openstack/nova/+/765749 ? gate unblock patch for stable/victoria has gotten a new patch squashed into it
16:03:13 bauzas melwitt: sure
16:04:11 melwitt thanks
16:04:31 bauzas melwitt: when squashing, should we add the cherry-picked SHA1s for all the squashed backports ?
16:04:33 bauzas gibi: ^
16:04:56 bauzas fortunately, we have the gerrit IDs within the commit msg, so it's more a procedural question
16:05:04 gibi bauzas: I can do that
16:05:14 gibi give me 5
16:05:16 bauzas it's an open question, I dunno
16:05:39 melwitt good question, I can't remember if we normally do. will do a quick gerrit search
16:05:41 bauzas we very rarely squash commits when backporting
16:06:55 bauzas eyes at https://docs.openstack.org/project-team-guide/stable-branches.html#proposing-fixes
16:08:04 gibi it says cherry-pick with -x
16:08:12 gibi and that does include that hash
16:08:14 melwitt yeah. I find examples of both in the gerrit search
16:08:42 gibi bauzas: if you feel that the commit hash is helpful then I can add that no problme
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

Earlier   Later