| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-05 | |||
| 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 | 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: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: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 | melwitt: +2 on tempest change, on nova change did you see my comment about CIRROS_VERSION | |
| 22:25:16 | gmann | setting https://review.opendev.org/c/openstack/nova/+/902217/9/.zuul.yaml#512 | |
| 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:25:52 | gmann | that in follow up | |
| 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: Add new nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902687 | |
| 09:51:22 | opendevreview | Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688 | |
| 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 | |
| 12:59:20 | sean-k-mooney[m] | ack | |
| 12:59:32 | sean-k-mooney[m] | lets try the self.addCleanup approch | |
| 13:00:23 | bauzas | for the sake of the series, I will remove https://review.opendev.org/c/openstack/nova/+/902084/3/nova/tests/unit/virt/libvirt/test_driver.py#26492 from the patch | |
| 13:00:48 | bauzas | and I'll provide this test in a separate change that would also add the addcleanup fix for the fixture | |
| 13:02:43 | bauzas | I maybe have an idea for recreating a new conf object but I need to test this | |
| 13:03:08 | bauzas | (stocking the original object at the beginning of setUp and then assigning it to self.conf in addcleanup) | |
| 13:03:31 | bauzas | shall work, provided oslo.config allows copying a CONF object | |
| 13:05:41 | eandersson | Anyone that can take a look at this minor patch? It just fixes some missing unt test coverage that was being ignored by coverage due to the threading model https://review.opendev.org/c/openstack/nova/+/900116 | |
| 13:27:57 | opendevreview | Sylvain Bauza proposed openstack/nova master: vgpu: Allow device_addresses to not be set https://review.opendev.org/c/openstack/nova/+/902084 | |
| 13:27:57 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: add coverage for registered dyn opts https://review.opendev.org/c/openstack/nova/+/902771 | |
| 13:47:27 | gibi | sean-k-mooney: I'm +2 on the PCI grouping spec. I think the direction there is good and we will anyhow need to touch the implementation to learn the gotchas of the current code | |
| 13:48:33 | gibi | sean-k-mooney: I also see we are on a similar page with the PXB spec about opt-in ness | |
| 14:17:20 | sean-k-mooney | gibi: ok am im more or less ok with merging the pci grouping spec. | |
| 14:17:48 | sean-k-mooney | i was getting a bit burnt out with the reviews this morning so i wanted to take another skim over it after a break | |
| 14:18:19 | sean-k-mooney | but assuumign i dont see anything on the second pass ill upgrade to +2w and we can dig into the detail mroe in the impelmenteion review and update the spec accordingly if required | |
| 14:23:54 | bauzas | I need to look at the specs | |
| 14:24:03 | bauzas | ETOOMANYTHINGSHERE | |
| 14:28:01 | bauzas | sean-k-mooney: do you have time to discuss about https://review.opendev.org/c/openstack/nova-specs/+/900636/comment/2948412c_75d00114/ ? | |
| 14:30:56 | sean-k-mooney | am i technially have back to back meeting for the next 4 hours but on irc yes | |
| 14:31:08 | sean-k-mooney | gmeet ectra no | |
| 14:31:47 | sean-k-mooney | basically i would like to keep the conductor check minimal and just to the main compatiblity check in in pre_live_migrate | |
| 14:33:06 | sean-k-mooney | its what we do for sriov live migration https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/libvirt-neutron-sriov-livemigration.html#resource-claims | |
| 14:33:38 | sean-k-mooney | well not quite | |
| 14:33:48 | sean-k-mooney | we actully added an rpc in check_can_live_migrate_destination | |
| 14:33:58 | sean-k-mooney | to do the claim i guess | |
| 14:34:21 | sean-k-mooney | if you are going to add an rpc to do that i woudl be fine with doing it in check_can_live_migrate_destination | |