Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-09-14
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 elodilles definitely RH wins over non-RH, that's true :)
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: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 Dammit, how the crap does a new func test cause this trace:
17:23:51 artom 2021-09-14 13:22:47,973 ERROR [nova.api.openstack.wsgi] Unexpected exception in API method
17:23:52 artom Traceback (most recent call last):
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 httplib_response = conn.getresponse(buffering=True)
17:23:52 artom TypeError: getresponse() got an unexpected keyword argument 'buffering'
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: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
08:51:53 bauzas for the moment, I'm still under the water
08:51:55 bauzas :(
08:51:59 gibi bauzas: no worries
08:52:04 bauzas some customer is getting 4 FTEs
08:52:16 bauzas ...
08:52:20 bauzas anyway
08:52:56 bauzas has anyone played with this ?
08:53:09 gibi I'm not
09:03:11 bauzas ok, I found how
09:03:15 bauzas that's working like a charm
09:03:40 bauzas it just binds a new greenlet where you can access the whole process
09:04:05 gibi bauzas: care to document that process somewhere after you surface from the escalations?
09:04:14 gibi I think it would be useful
09:04:30 bauzas gibi: yeah that's worth of interest, I'm also testing tracemalloc module
09:04:53 gibi +1 for the tracemalloc too.
09:05:28 bauzas context (I can tell if I don't tell the whole context) : the nova-compute service is consuming unusual memory space hence a potential memory leak to identify
09:06:05 bauzas so the strategy is to compare memory allocations snapshots over time
09:08:15 gibi does tracemalloc can differentiate between allocated but not used memory and actually used memory?
09:08:42 kashyap Very good question
09:09:51 kashyap tracemalloc.get_tracemalloc_memory()
09:10:01 bauzas gibi: we're litterally doing baby steps here
09:10:01 kashyap gibi: The above _should_ get the memory usag
09:10:17 bauzas gibi: the idea is that you can generate snapshots
09:10:31 bauzas and each snapshot (like a GMR) gives you bits of memory usage
09:10:49 bauzas tracemalloc even provides a compare method between snapshots
09:13:21 bauzas kashyap: tracemalloc.get_traced_memory() only gives you the memory usage of the tracking module itself
09:27:26 opendevreview Lee Yarwood proposed openstack/nova master: docs: Add nova-volume volume_attachment refresh admin workflow https://review.opendev.org/c/openstack/nova/+/809161
09:31:41 opendevreview Lee Yarwood proposed openstack/nova master: run-evacuate-hook: Switch to osc evacuate command and add --debug https://review.opendev.org/c/openstack/nova/+/809162
09:42:40 opendevreview Merged openstack/osc-placement stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/osc-placement/+/808456
09:45:24 opendevreview Merged openstack/python-novaclient stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/python-novaclient/+/808459
09:45:25 opendevreview Merged openstack/python-novaclient stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/python-novaclient/+/808460
09:54:13 opendevreview Merged openstack/osc-placement stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/osc-placement/+/808457
11:44:35 viks__ hi, what is the use of the code: `consumer_type = 'migration'` in https://github.com/openstack/nova/blob/01eaa627b406af9336a231caea6969aae9a62033/nova/cmd/manage.py#L2550 as the next condition after this line always overrides this? am i missing something?
11:45:58 sean-k-mooney it will not override it if there is not instance that matches
11:46:30 sean-k-mooney so we asume any allocation we find that doen have a consumer type are migration and then set them to instnace if we see a corresponding instnace
11:47:23 viks__ sean-k-mooney: but if we check the earlier condition, we see it always seems to be setting `consumer_type = 'instance'`
11:47:45 viks__ https://www.irccloud.com/pastebin/XOzn2XSW/
11:48:07 sean-k-mooney most allocation will be of type instance
11:49:06 sean-k-mooney the not is likely wrong
11:49:24 sean-k-mooney infact the not i think is wrong
11:49:45 viks__ sean-k-mooney: ok... that's what i was thinking

Earlier   Later