Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-01-18
16:50:53 bauzas ok, so we know that we cache 1GB in memory
16:50:57 gibi te test is nice as it get the image metadata first so in the log there is a "size": 996147200 before the data is downloaded
16:51:24 bauzas gibi: I'm waiting for my test job to return but I guess we'll see a size of 1GB in memory for that variable
16:52:29 bauzas dansmith: about your question (why do we trigger now the kill and not earlier), my guess is that we were just below the line
16:52:34 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: Test that OOM triggering test is skipped https://review.opendev.org/c/openstack/nova/+/870950
16:53:34 dansmith bauzas: yeah, like I said, we're probably just swapping it all and never touching it again, so pressure is high and we're close to the edge :)
16:53:45 bauzas one way to alleviate this issue would be to make sure we run that greedy test into a specific test runner worker
16:54:06 opendevreview Aaron S proposed openstack/nova master: Add further workaround features for qemu_monitor_announce_self https://review.opendev.org/c/openstack/nova/+/867324
16:54:10 bauzas https://stestr.readthedocs.io/en/latest/MANUAL.html#test-scheduling
16:54:29 gibi bauzas: we just shouldn't load the whole image data in memory at once
16:54:29 bauzas tempest exposes the worker configs from stestr
16:54:57 gibi as in general image size can be way bigger than memory size
16:55:10 bauzas gibi: that's true
16:55:20 bauzas caching the metadata seems ok to me
16:55:34 bauzas caching the data itself seems unnecessary
16:55:44 bauzas unless you want to compare bytes per bytes
16:55:46 gibi yeah meatadata is bound by glance API
16:55:59 gibi image size is unbound
16:56:05 bauzas but agreed you could and should compare streams and not objects
16:56:15 bauzas for the dataz
16:56:28 dansmith it's just a naive test not thinking about the world outside a 16MB image
16:56:30 bauzas glance team is added on the bug report
16:56:38 dansmith anyone using this for verification of a real cloud likely has an even larger image,
16:56:41 dansmith so it's clearly not okay to do this
16:56:45 bauzas agreed
16:56:55 bauzas whoami-rajat: hey, happy new year :)
16:57:03 opendevreview Aaron S proposed openstack/nova master: Add further workaround features for qemu_monitor_announce_self https://review.opendev.org/c/openstack/nova/+/867324
16:58:53 opendevreview Aaron S proposed openstack/nova master: Add further workaround features for qemu_monitor_announce_self https://review.opendev.org/c/openstack/nova/+/867324
16:59:49 opendevreview Merged openstack/nova master: Strictly follow placement allocation during PCI claim https://review.opendev.org/c/openstack/nova/+/855650
17:01:08 bauzas hmmm, stackalytics.io is fone
17:01:10 bauzas gone*
17:01:57 gibi what do you mean by gone?
17:02:00 gibi it loads for me with
17:02:01 gibi Last updated on 18 Jan 2023 12:44:21 UTC
17:02:06 bauzas I got a timeout
17:02:16 bauzas oh this works now
17:04:20 gibi gmann, dansmith: was there some policy change recently that can cause that the nova functional test locally gets 403 from placement?
17:04:33 gibi {'errors': [{'status': 403, 'title': 'Forbidden', 'detail': 'Access was denied to this resource.\n\n placement:allocations:list ', 'request_id': 'req-c5c03029-ba79-4e4a-8ec8-03deadb24ded'}]}
17:04:43 dansmith gibi: reliably?
17:04:46 gibi yes
17:04:51 dansmith oof, then probably
17:04:51 gibi this is pure nova master functional test
17:04:53 gmann gibi: yeah we changed the default and placement fixture needed fix whihc is merged i think
17:05:00 bauzas gibi: yeah
17:05:09 gmann gibi: can you rebase the placement repo?
17:05:12 bauzas gibi: we switched to new RBAC policies
17:05:28 gibi it is just my nova repo locally
17:05:32 gmann this one https://review.opendev.org/c/openstack/placement/+/869525
17:05:58 gmann gibi: because nova functional test use placement fixture from placement repo
17:06:17 bauzas which we pull as a dependency, right?
17:06:31 gmann yes
17:06:57 gibi openstack-placement>=1.0.0
17:06:57 gibi so nova's tox.ini has
17:07:06 gibi that should pull in the latest openstack-placement
17:07:12 gibi in the functional venv
17:07:35 bauzas tox -r ?
17:07:42 gibi I have openstack-placement==8.0.0
17:07:44 gibi in the venv
17:07:56 gibi I guess we merged the fix in placement but we haven't released it
17:08:04 gmann i do not think we released placement with that
17:08:17 gmann yeah not released yet, we should do
17:08:17 gibi so nova's tox.ini pulls placement from pypi
17:08:25 gibi ^^ yepp
17:08:43 gibi or change nova's tox.ini to pull placement from github
17:08:55 gmann yeah for now this can be workaround
17:08:57 gmann let me push it today unless bauzas you want to do?
17:10:15 gmann I feel placement fixture import from placement in functional test should be changed like we do for cinder/glance fixture otherwise we need new placement release for any change in there
17:11:11 bauzas gmann: do the push and I'll +1
17:11:30 gmann bauzas: ok
17:12:22 gibi gmann: based on the constraint in tox.ini openstack-placement>=1.0.0 this is the first time we need such a release due to the fixture
17:13:37 bauzas gibi: gmann: shall we consider to pull from gh ?
17:13:57 gibi I would keep pypi
17:14:07 gmann gibi: yeah because this actually change the things like default policy. but this can occur if change in default for policy or config unless we change nova functional test to move to those new defaults. for example
17:14:12 gibi if this becomes a frequent problem then I would change the placemnet fixture in nova
17:14:25 gmann placement policy need different token default than what nova is using for access
17:19:33 gibi I just confimed switching to gh locally in the tox.ini fixes the problem. Still I vote for release a new placement version and bumping the constarint in nova's tox.ini
17:21:06 gmann ok. yeah once released we should bump the constraint if we wan to use it from pypi
17:21:21 gmann I will push the release
17:21:25 gibi yepp
17:21:27 gibi and thanks
17:27:35 bauzas gmann: I need to disappear soon
17:28:08 gmann bauzas: https://review.opendev.org/c/openstack/releases/+/870989
17:31:43 bauzas gmann_afk: gibi: that's where I'm struggling to consider 8.1.0 as a correct number
17:32:03 bauzas placement is cycle-with-rc
17:32:44 gibi bauzas: you mean 8.0.0 was Zed, so 8.1.0 should come from stable/ze?
17:33:04 bauzas gibi: yup
17:33:20 bauzas but we have tools for creating YAMLs
17:33:33 gibi yeah I'm not sure either if we can relase 8.1 from placement master
17:33:36 gibi elodilles: ^^?
17:34:02 bauzas https://releases.openstack.org/reference/using.html#using-new-release-command
17:36:24 bauzas so, I'd say we should call out this release using the tool with "new-release antelope placement milestone"
17:37:40 bauzas elodilles: right?
17:38:33 elodilles we could just release beta from cycle-with-rc projects
17:39:04 gibi that would be 9.0.0 beta I assume
17:39:11 elodilles answering in #openstack-release
17:39:24 elodilles gibi: yes, 9.0.0.0b1
17:39:59 bauzas elodilles: using new-release, I guess this is 'milestone' arg I presume ?
17:41:39 gmann i see, you are right. 8.1.0 is not right
17:43:40 elodilles bauzas: yes, 'milestone' generates 9.0.0.0b1 (to answer it here as well :))
17:43:56 bauzas ack, gtk

Earlier   Later