Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-09-14
16:11:35 sean-k-mooney just gate capastity so no not really
16:11:43 elodilles and sean-k-mooney question is the next one: do we want to wait for something?
16:12:06 sean-k-mooney we might want to wait for the open redirect cve fixes
16:12:15 elodilles if not, then I can prepare the releases today or tomorrow
16:12:21 sean-k-mooney thats really the only thing im thinking of
16:13:05 elodilles sean-k-mooney: some part are merged back till ussuri,
16:13:05 sean-k-mooney they are merged to usuri i think so we could start with W->U
16:13:25 elodilles but if i'm not mistaken there is one part which is still waiting for review in victoria
16:13:27 sean-k-mooney and and do train after
16:13:45 sean-k-mooney ah right for the /// case
16:13:47 elodilles (reminder: train is EM, so there won't be any release)
16:13:56 sean-k-mooney ah ok cool
16:14:11 gibi I agree to release Wallaby now, then land the cve last fix to V and release that
16:14:17 elodilles https://review.opendev.org/c/openstack/nova/+/806626
16:14:25 elodilles this needs stable review ^^^
16:14:30 gibi then backort the last cve fix to U etc.
16:14:37 elodilles and the also ussuri version of it
16:14:47 gibi can I get stable power?
16:14:54 gibi ;)
16:14:58 elodilles :]
16:15:30 sean-k-mooney ok so are we agreed we shoudl merge those then release them
16:15:37 sean-k-mooney once we get the ack for bauzas
16:15:51 elodilles sounds good to me
16:16:02 sean-k-mooney lyarwood: melwitt if you have time to review those on stable that would also help
16:16:58 elodilles yes, reviews are welcome and appreciated for those patches
16:17:42 sean-k-mooney if there is nothing else we can likely wrap the meeting there
16:17:57 gibi yeah
16:17:59 gibi anything else?
16:18:08 elodilles nothing from me :X
16:18:25 gibi then lets close this
16:18:30 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-09-14-16.00.log.html
16:18:30 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-09-14-16.00.txt
16:18:30 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-09-14-16.00.html
16:18:30 opendevmeet Meeting ended Tue Sep 14 16:18:30 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:18:30 gibi #endmeeting
16:20:44 gibi thanks
16:21:16 elodilles thanks o/
16:37:25 artom elodilles, while we're kinda on the topic (con't from the meeting, sorta), could you give an opinion on https://review.opendev.org/c/openstack/nova/+/791481 ?
16:38:19 artom It's "blocking" a few backports, so it'd be good to get fixed on whether it's get-in-able or not
16:40:49 opendevreview Artom Lifshitz proposed openstack/nova stable/victoria: fixtures: Handle binding of first port https://review.opendev.org/c/openstack/nova/+/796905
16:40:50 opendevreview Artom Lifshitz proposed openstack/nova stable/victoria: Neutron fixture: don't clobber profile and vif_details if empty https://review.opendev.org/c/openstack/nova/+/796906
16:40:51 opendevreview Artom Lifshitz proposed openstack/nova stable/victoria: functional: Add live migration tests for PCI, SR-IOV servers https://review.opendev.org/c/openstack/nova/+/796907
16:40:53 opendevreview Artom Lifshitz proposed openstack/nova stable/victoria: Test SRIOV port move operations with PCI conflicts https://review.opendev.org/c/openstack/nova/+/796908
16:40:55 opendevreview Artom Lifshitz proposed openstack/nova stable/victoria: Update SRIOV port pci_slot when unshelving https://review.opendev.org/c/openstack/nova/+/796909
16:40:56 artom For now I've just stacked on top
17:04:34 elodilles artom: well, it's test-only so that's good. on the other hand it is just refactoring (which is usually refused to accept as valid backport - if it's not some trivial change), thus I think it's not really "blocking". I understand that it makes backporting easier for some cases, but...
17:05:48 artom elodilles, so the alternative is that every backport that goes back to train (and Red Hat has to care about stable/train for a loooon time) is harder to write and review because it'll have a note about having to adjust method params or w/e
17:06:54 elodilles well, there will be ONE point where a patch needs modification / resolve of conflicts, but further back it can be still clean
17:07:31 artom elodilles, right, I meant in the sense that *every* patch going back to train will need that modification
17:07:49 artom As opposed to landing the test refactor and forgetting about it
17:08:45 elodilles let's say if we backport it till train then a patch that needs backport to stein will need the very same modification (though I understand that stein expects way less backports)
17:09:32 artom elodilles, ah, I see your point. We'd just be pushing back the point at which we need manual adjustments to the backport
17:10:16 elodilles exactly
17:10:41 artom I agree, I just don't know how much of an issue it will be in practice...
17:11:31 elodilles it depends on the amount of similar patches I think :)
17:11:42 artom elodilles, so, you have more experience reviewing stable branches, what would you say the ratio of RH to non-RH backports is?
17:12:28 artom Or to put it slightly different, RH care about stable/train (queens is still a thing, though we expect way less work on it now)
17:12:28 elodilles definitely RH wins over non-RH, that's true :)
17:13:05 artom I'm trying to tread carefully here, because this is *not* just throwing our weight around
17:13:36 artom If CERN (to name a random example) or Vexxhost or whoever are still running stein a need loads of backports to it, it's a different conversation
17:16:45 elodilles anyway, I'm not completely against backporting this, I'm just thinking as well where is the line and maybe this is somewhere there :)
17:17:44 artom_ But if stable/train happens to be the stable branch that's most popular by virtue of being what RH supports, it would make sense to me to make backports to train as easy as possible? <-- repeating myself in case it didn't send before my connection dropped
17:17:55 mnaser artom: thanks for thinking of us :) we don't care about stein anymore (thankfully :])
17:18:12 mnaser in the next few weeks wallaby will be the only thing we care about
17:18:13 artom_ mnaser, \o/
17:23:51 artom 2021-09-14 13:22:47,973 ERROR [nova.api.openstack.wsgi] Unexpected exception in API method
17:23:51 artom Dammit, how the crap does a new func test cause this trace:
17:23:52 elodilles artom: another aspect is when we backport *everything* to train, then we make it harder (or even impossible?) to other contributors (with less weight) to backport a change from train to stein as they would require to resolve a mass of conflicts
17:23:52 artom TypeError: getresponse() got an unexpected keyword argument 'buffering'
17:23:52 artom httplib_response = conn.getresponse(buffering=True)
17:23:52 artom File "/home/artom/src/nova/.tox/functional-py36/lib/python3.6/site-packages/urllib3/connectionpool.py", line 417, in _make_request
17:23:52 artom Traceback (most recent call last):
17:26:17 artom elodilles, valid point, though I'd counter that part of that has already been done, by virtue of the backport chain already existing for train
17:26:24 artom So you know you need at least those patches
17:26:50 artom Like, I'm willing to bite that bullet, because I think overall it saves man hours
17:27:21 artom I'll happily resolve conflicts for someone's stable/stein backport if it means making stable/train backporting easier
17:27:38 artom The question is - how do we even advertise that?
17:27:44 artom To let backporters know
17:27:58 elodilles :) valid question :)
17:28:23 elodilles anyway, I'll sleep on it and will review the patch tomorrow
17:29:33 artom elodilles, ack, thanks for the conversation :)
17:30:02 elodilles artom: np :)
17:30:37 spatel anyone has any experience with server.com to rent servers?
17:31:10 spatel I am planning to rent to build openstack so looking for good feedback if anyone has :)
17:33:54 artom elodilles, one last data point, FWIW, in the last 6 months, there's been 3 "pages" of patches to stable/train, vs 1 for stable/stein
17:34:23 artom https://review.opendev.org/q/project:openstack/nova+branch:stable/train+-age:6month https://review.opendev.org/q/project:openstack/nova+branch:stable/stein+-age:6month
17:34:42 artom So about 3 times more backports to train than stein
17:35:07 artom Tbh, I expected a bigger difference, I thought stein would be way less active
17:35:56 artom Looks like we need Vlad Gusev, he's the main stein contributor who's not RH
18:22:14 opendevreview Merged openstack/nova stable/ussuri: Reduce mocking in test_reject_open_redirect for compat https://review.opendev.org/c/openstack/nova/+/803094
18:39:50 skazi elodilles: thx for additional info I didn't know that
18:39:58 skazi elodilles: thx for additional info I didn't know that :o(
18:40:04 skazi sean-k-mooney: thank you too!
#openstack-nova - 2021-09-15
00:16:39 opendevreview melanie witt proposed openstack/nova-specs master: Re-propose Unified Limits in Nova https://review.opendev.org/c/openstack/nova-specs/+/809020
07:35:14 bauzas morning folks
07:35:23 bauzas gibi: elodilles: good catch on the approval thing
07:35:36 bauzas I was about to propose the release liaison role to anyone who'd like
07:35:55 bauzas having a single person responsible for approving releases is a SPOF
08:51:15 gibi bauzas: I agree to push out such proposal. It would be nice to see somebody picks that up. If not then I can be hooked for it
08:51:41 bauzas I'll ask this at the next meeting

Earlier   Later