Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-12-11
15:39:04 melwitt ++
15:40:27 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Wallaby https://review.opendev.org/c/openstack/nova-specs/+/759731
15:40:30 kashyap gibi: Fixed the nit
15:41:00 gibi kashyap: re-applied my badge
15:41:14 kashyap Thanks! :)
15:41:20 gibi I thank you
15:47:49 openstackgerrit Balazs Gibizer proposed openstack/nova stable/victoria: lower-constraints: Bump packaging to 20.4 https://review.opendev.org/c/openstack/nova/+/765749
15:47:54 gibi lyarwood: ^^
15:48:16 lyarwood gibi: awesome thanks
15:48:47 gibi melwitt: could you babysitt ^^ during your day if needed?
15:49:06 melwitt gibi: yep
15:49:20 gibi thanks
15:49:29 sean-k-mooney gibi: fungi raised an interesting point regarding the usefullness of lower constriants. personlly i only found it use full to detect when we use a new feature that is not in the version used by lower constraits
15:49:48 sean-k-mooney it has some other uses but do we want to discuss if we ant to keep supporting it
15:50:48 gibi sean-k-mooney: I don't have to much past knowledge about why we added lower constraints in the first place
15:51:04 sean-k-mooney in principal i do like the idea of tracking you min requirements and testing it but on the other hand i dont know if distos actully use this
15:51:23 sean-k-mooney gibi: it was mainly for distos to tell them what the min version they could use was
15:51:33 openstackgerrit Balazs Gibizer proposed openstack/nova stable/victoria: lower-constraints: Bump packaging to 20.4 https://review.opendev.org/c/openstack/nova/+/765749
15:51:45 gibi OK, then we need to see if distros are depending on this information or not
15:52:00 gmann sean-k-mooney: gibi yeah that is very open thing to discuss on how we should test it and whether we should test it or not
15:52:29 gmann one place it is helpful is while upgrade
15:52:55 sean-k-mooney only partly
15:52:58 melwitt gibi: were you meaning to write more on this line or is it just a typo? "and bug" at the end https://review.opendev.org/c/openstack/nova/+/765749/7//COMMIT_MSG#15
15:53:07 sean-k-mooney knowing that there is an overlap is useful yes
15:53:21 gibi melwitt: typo, I've pushed a new ps
15:53:26 sean-k-mooney but in a none conatienrised env it get complicated bwtween multipel serivces
15:53:46 gibi melwitt: my editor moved the #<bugnumber> ot the beginning of the next line and git ignored that line as a comment :)
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?

Earlier   Later