Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-12-05
16:32:52 sean-k-mooney it shoudl not be unless you did somethign odd
16:32:57 bauzas once the dynamic group is registered in some test, it's kept on the global CONF obj
16:33:09 bauzas sean-k-mooney: I can prove it
16:33:16 sean-k-mooney oh well i guess then the fixture is incomplete
16:33:28 sean-k-mooney and needs to be updated to supprot that
16:33:50 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/test.py#L219
16:34:10 sean-k-mooney we do use the fixture in any test case that inherits form nova.test.TestCase
16:34:34 sean-k-mooney its defiend here https://github.com/openstack/nova/blob/master/nova/tests/fixtures/conf.py#L26
16:35:16 bauzas I see it
16:35:19 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/tests/fixtures/conf.py#L69
16:35:24 sean-k-mooney that is likely relevent
16:35:37 bauzas this is normal if you did set the flags before
16:36:00 bauzas what's not normal is that I still have the groups registered in some test before I set them
16:36:00 sean-k-mooney the flags are not ment to exscape the current test case
16:36:17 bauzas anyway, I need to prepare some internal meetup
16:36:25 bauzas so I'll have to hardstop
16:36:30 sean-k-mooney ok
16:49:14 opendevreview Merged openstack/nova stable/2023.1: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/898945
17:05:53 melwitt sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/650172 is ready for review iirc, I don't remember if there are unaddressed comments so if there are, just lmk
17:06:56 melwitt sean-k-mooney: and the nova patch with uec images passed finally! https://review.opendev.org/c/openstack/nova/+/902217
17:57:58 sean-k-mooney melwitt: woot
17:58:21 sean-k-mooney i noticed you working on it quite late last night considering it was early in my morning :)
18:16:00 melwitt sean-k-mooney: the patch was so close to working 😁
18:16:00 melwitt sean-k-mooney: the patch was so close to working �
18:16:45 clarkb melwitt: fwiw we should have 30 day retention of job logs in our swift backends
18:17:37 clarkb that range originated with our old 10TB fileserver for logs. That was basically as much as we could fit at the time into that space with some headroom for maintenance and we carried it over when we moved to swift
18:18:40 melwitt clarkb: ah ok. good to know. I always use "last 30 days" but I feel like I haven't seen results that go back further than around 10 days. I'll check again
18:19:56 clarkb https://zuul.opendev.org/t/zuul/build/19dae94a70524ae28db9cd8ed4257136/logs these are almost 30 days old
18:21:19 melwitt hrrmm ok, thanks
18:31:27 melwitt dpawlik: do you know if there is a time limit of some kind on the opensearch log indexing? I generally see around 10 days worth of search results but the logs are actually kept for 30 days? ^
18:35:32 clarkb oh you are talking about retention in opensearch
18:35:54 clarkb in the old elasticsearch system we had between 7-10 days of retention due to indexing the data causing it to explode in size and that is after filtering out the debug logs
18:39:41 melwitt yes, sorry, I thought your comment was in reference to my ML post about the gate issues in nova and my mention of 10 days worth of opensearch results :)
18:43:01 clarkb it was and I misread it to say you are giving opensearch links because the static log storage doesn't have more than 10 days of retention
18:43:24 melwitt ahhh gotcha
18:44:05 sean-k-mooney the static log storage used to be 30 in the past right
18:44:20 sean-k-mooney then it was 30 days subject to storage not being full
18:44:38 sean-k-mooney when did it drop to 10 days for zuul logs out of interest
18:45:22 clarkb sean-k-mooney: when we moved to swift it has always been 30 days since we weren't limited by filesystems aynmore. The 10 day thing is opensearch specific I think
18:45:26 melwitt the opensearch share links were sometimes not working at all, for lack of a better way to describe it. I would copy paste or click the share icon and get the link, then to test it I pasted it into a new browser tab and after the first visit, the link no longer worked and would not bring up the search results and would just load the page with no search query at all
18:46:04 sean-k-mooney ah ok
18:46:23 sean-k-mooney melwitt: i alwasy put the opensarch link thorugh tiny url by the way
18:46:32 sean-k-mooney https://tinyurl.com/app
18:47:16 melwitt I'll try that. I tried the built in url shortener in opensearch but it doesn't work or isn't enabled or something and I didn't go to another one
18:58:35 melwitt gmann: you might be interested in these, some patches intended to improve our CI stability in nova https://review.opendev.org/q/topic:%22nova-ci-improvements%22 one patch is for tempest to support UEC images
19:13:45 gmann melwitt: ack, thanks
20:04:25 gmann melwitt: commented in https://review.opendev.org/c/openstack/nova/+/902217
20:04:40 gmann melwitt: also I did not get how tempest change is dependency of it
20:05:20 gmann melwitt: btw I like the idea of using UEC image, maybe we can try in a few of the tempest jobs also
22:16:51 melwitt won't work. the server won't boot. similarly when tempest creates a fresh image from the tarball, currently it can't support that, it won't extract the tarball and create the kernel and ramdisk images in glance, and associate the AMI image it creates with them
22:16:51 melwitt gmann: thanks for looking! the tempest change is needed bc there are a couple of places where tempest creates an image itself, and those couple of places currently don't support UEC images. without the tempest change, when tempest creates an image based on the default image, it doesn't set the kernel and ramdisk image IDs in the create request that are needed by the AMI image, so when it tries to create a server from that image, it
22:24:13 gmann melwitt: ah i see, tempest uses img_file in create, got it thanks https://review.opendev.org/c/openstack/tempest/+/902609/3/tempest/scenario/manager.py#771
22:25:16 gmann setting https://review.opendev.org/c/openstack/nova/+/902217/9/.zuul.yaml#512
22:25:16 gmann melwitt: +2 on tempest change, on nova change did you see my comment about CIRROS_VERSION
22:25:52 gmann that in follow up
22:25:52 gmann melwitt: as it has one +2 and work in current devstack default. I am ok to convert my vote and ok to do it
22:27:17 melwitt gmann: yes, just replied. you are right about not needing to set those default image vars for nova-next. setting those is residue from my original PS that was setting defaults in project.vars and trying to inherit from that. that ultimately couldn't work bc devstack-tempest sets IMAGE_URLS and overrides project.vars, so I had to change it around
22:28:04 melwitt gmann: ok sure, sounds good. I'll upload a follow up
22:31:02 gmann melwitt: thanks, +A
22:35:54 opendevreview melanie witt proposed openstack/nova master: Remove redundant setting of DEFAULT_IMAGE_NAME(_FILE) https://review.opendev.org/c/openstack/nova/+/902734
22:36:56 melwitt ^ thanks gmann
#openstack-nova - 2023-12-06
07:33:54 dpawlik melwitt: hey, so we have configured retention to 14 days - https://opendev.org/openstack/ci-log-processing/src/branch/master/opensearch-config#create-ilm-index-lifecycle-management - but we have enough space to keep it 30 days (until debug messages are sent to OpenSearch). Only subunit index got retention 7 days.
07:35:54 dpawlik should we increase?
07:37:34 dpawlik and if you expected the result within 30 days, unfortunately it will only be within 14 days :|
07:38:19 dpawlik let me know if I should change the policy to 30 days :)
09:27:22 bauzas happy spec review day everyone
09:33:09 gibi /o\
09:33:14 gibi (thanks for the reminder :D)
09:51:21 opendevreview Stephen Finucane proposed openstack/nova master: Remove nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902686
09:51:22 opendevreview Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688
09:51:22 opendevreview Stephen Finucane proposed openstack/nova master: Add new nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902687
10:22:31 bauzas gibi: I'll be honest, I'm currently fixing some problem I had with my machine for our company demo yesterday :)
11:01:53 opendevreview Stephen Finucane proposed openstack/nova master: Add new nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902687
11:01:54 opendevreview Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688
11:07:10 opendevreview Stephen Finucane proposed openstack/nova master: Add new nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902687
11:07:11 opendevreview Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688
11:12:54 stephenfin sean-k-mooney: jfyi https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/5RQGZZMCKKHAVH4OLSJCLBQNIHYDPGZD/
11:13:02 stephenfin I tested it locally. Works fine.
11:13:14 opendevreview Merged openstack/nova master: Use split kernel/initramfs Cirros UEC image by default in jobs https://review.opendev.org/c/openstack/nova/+/902217
11:18:03 sean-k-mooney[m] stephenfin: related i was able to demonstrate that the current support is broken https://review.opendev.org/c/openstack/pbr/+/900728
11:18:09 sean-k-mooney[m] in pbr
11:18:46 sean-k-mooney[m] and i think i know how to fix it but ya havent had time to try and implement it since
12:55:06 bauzas sean-k-mooney: thanks for your review of my mdev live-mig spec, will look at your points a bit later
12:55:48 bauzas sean-k-mooney: now, about my problem with the CONF object, I checked and basically the cleanups we have in the oslo.config fixture don't delete the dynamically created groups
12:56:04 bauzas I just checked, we pass the same object between tests
12:56:30 sean-k-mooney[m] ack so this is just a gap in the fixture
12:56:31 bauzas fixing it would require our nova fixture to add some cleanup that would delete the dynamically generated groups
12:56:43 sean-k-mooney[m] ya
12:56:50 sean-k-mooney[m] i think that is fine
12:57:02 sean-k-mooney[m] the fixture should be fully resetting the object
12:57:21 bauzas yeah, so after https://github.com/openstack/nova/blob/09b651540f120ad30fa7127e87b27a6363044dcf/nova/tests/fixtures/conf.py#L69 we would add a addCleanup(devices.unregister_dynamic_opts)
12:57:51 sean-k-mooney[m] am ya i guess that works that would do the cleanup at the end for the test
12:57:58 bauzas sean-k-mooney: I just checked and calling self.conf.reset is useless
12:58:11 sean-k-mooney[m] but we could also just reassing an empty config bject to the gloabl
12:58:25 bauzas that's even already done by the oslo.config fixture itself https://github.com/openstack/oslo.config/blob/master/oslo_config/fixture.py#L41
12:58:37 bauzas so there is no need to duplicate the useless call in the nova fixture
12:58:40 sean-k-mooney[m] that not what i ment
12:58:55 sean-k-mooney[m] i ment actully concruting a new object and assigning to the singleton
12:58:58 bauzas sean-k-mooney: yeah I thought about recreating a whole object
12:59:08 bauzas but I don't know how to make it cleanly

Earlier   Later