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:33 |
---|---|---|
dpawlik | should we increase? | 07:35 |
dpawlik | and if you expected the result within 30 days, unfortunately it will only be within 14 days :| | 07:37 |
dpawlik | let me know if I should change the policy to 30 days :) | 07:38 |
*** Guest8552 is now known as layer8 | 08:37 | |
*** layer8 is now known as Guest9391 | 08:37 | |
*** Guest9391 is now known as layer9 | 08:39 | |
*** layer9 is now known as l8 | 08:45 | |
bauzas | happy spec review day everyone | 09:27 |
gibi | /o\ | 09:33 |
gibi | (thanks for the reminder :D) | 09:33 |
opendevreview | Stephen Finucane proposed openstack/nova master: Remove nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902686 | 09:51 |
opendevreview | Stephen Finucane proposed openstack/nova master: Add new nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902687 | 09:51 |
opendevreview | Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688 | 09:51 |
bauzas | gibi: I'll be honest, I'm currently fixing some problem I had with my machine for our company demo yesterday :) | 10:22 |
opendevreview | Stephen Finucane proposed openstack/nova master: Add new nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902687 | 11:01 |
opendevreview | Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688 | 11:01 |
opendevreview | Stephen Finucane proposed openstack/nova master: Add new nova.wsgi module https://review.opendev.org/c/openstack/nova/+/902687 | 11:07 |
opendevreview | Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688 | 11:07 |
stephenfin | sean-k-mooney: jfyi https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/5RQGZZMCKKHAVH4OLSJCLBQNIHYDPGZD/ | 11:12 |
stephenfin | I tested it locally. Works fine. | 11:13 |
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:13 |
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 |
sean-k-mooney[m] | in pbr | 11:18 |
sean-k-mooney[m] | and i think i know how to fix it but ya havent had time to try and implement it since | 11:18 |
bauzas | sean-k-mooney: thanks for your review of my mdev live-mig spec, will look at your points a bit later | 12:55 |
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:55 |
bauzas | I just checked, we pass the same object between tests | 12:56 |
sean-k-mooney[m] | ack so this is just a gap in the fixture | 12:56 |
bauzas | fixing it would require our nova fixture to add some cleanup that would delete the dynamically generated groups | 12:56 |
sean-k-mooney[m] | ya | 12:56 |
sean-k-mooney[m] | i think that is fine | 12:56 |
sean-k-mooney[m] | the fixture should be fully resetting the object | 12:57 |
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 |
sean-k-mooney[m] | am ya i guess that works that would do the cleanup at the end for the test | 12:57 |
bauzas | sean-k-mooney: I just checked and calling self.conf.reset is useless | 12:57 |
sean-k-mooney[m] | but we could also just reassing an empty config bject to the gloabl | 12:58 |
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 |
bauzas | so there is no need to duplicate the useless call in the nova fixture | 12:58 |
sean-k-mooney[m] | that not what i ment | 12:58 |
sean-k-mooney[m] | i ment actully concruting a new object and assigning to the singleton | 12:58 |
bauzas | sean-k-mooney: yeah I thought about recreating a whole object | 12:58 |
bauzas | but I don't know how to make it cleanly | 12:59 |
sean-k-mooney[m] | ack | 12:59 |
sean-k-mooney[m] | lets try the self.addCleanup approch | 12:59 |
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 |
bauzas | and I'll provide this test in a separate change that would also add the addcleanup fix for the fixture | 13:00 |
bauzas | I maybe have an idea for recreating a new conf object but I need to test this | 13:02 |
bauzas | (stocking the original object at the beginning of setUp and then assigning it to self.conf in addcleanup) | 13:03 |
bauzas | shall work, provided oslo.config allows copying a CONF object | 13:03 |
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:05 |
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 |
opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: add coverage for registered dyn opts https://review.opendev.org/c/openstack/nova/+/902771 | 13: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:47 |
gibi | sean-k-mooney: I also see we are on a similar page with the PXB spec about opt-in ness | 13:48 |
* gibi stops reviewing specs now, if I need to re-review something the please ping me | 13:49 | |
sean-k-mooney | gibi: ok am im more or less ok with merging the pci grouping spec. | 14:17 |
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:17 |
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:18 |
bauzas | I need to look at the specs | 14:23 |
bauzas | ETOOMANYTHINGSHERE | 14:24 |
bauzas | sean-k-mooney: do you have time to discuss about https://review.opendev.org/c/openstack/nova-specs/+/900636/comment/2948412c_75d00114/ ? | 14:28 |
sean-k-mooney | am i technially have back to back meeting for the next 4 hours but on irc yes | 14:30 |
sean-k-mooney | gmeet ectra no | 14:31 |
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:31 |
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 |
sean-k-mooney | well not quite | 14:33 |
sean-k-mooney | we actully added an rpc in check_can_live_migrate_destination | 14:33 |
sean-k-mooney | to do the claim i guess | 14:33 |
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 | 14:34 |
sean-k-mooney | baiscally i want to minimise the amount of rpc callses we need and reuse the ones we already have currently | 14:35 |
bauzas | sean-k-mooney: tbc, I tried to do like for other features | 14:36 |
opendevreview | Merged openstack/nova-specs master: resubmit per-process-healthchecks spec for 2024.1 https://review.opendev.org/c/openstack/nova-specs/+/897225 | 14:36 |
bauzas | I thought it would be nice to check the types by the conductor | 14:37 |
bauzas | because operators couldn't use traits or something else | 14:37 |
bauzas | say custom rcs | 14:37 |
sean-k-mooney | well if they are using traits ro customer reousces | 14:37 |
bauzas | we could do this in pre-live-migrate for sure, after the conductor | 14:37 |
sean-k-mooney | then the type is checked by placment | 14:37 |
bauzas | sean-k-mooney: yeah indeed, but that's optional | 14:38 |
sean-k-mooney | right i think that shoudl be requried | 14:38 |
bauzas | I don't think so | 14:38 |
sean-k-mooney | i know | 14:38 |
bauzas | some operators just want to provide VGPUs | 14:38 |
sean-k-mooney | so i think the conductor check could be doen but im worried it will be somewhat expensive | 14:38 |
bauzas | given every new GPU has specific types | 14:38 |
bauzas | sean-k-mooney: shouldn't be that expensive as we already have the calls | 14:39 |
sean-k-mooney | so what i can do is try and reivew the code and that section again | 14:39 |
sean-k-mooney | when i got to your spec i was starting tot get review burn out | 14:39 |
bauzas | no worries | 14:40 |
bauzas | this is somehow an implementation question | 14:40 |
bauzas | I mean, testing the types is a design point | 14:40 |
bauzas | but where can be something related to the implementation | 14:41 |
bauzas | I can modify my spec accordingly | 14:41 |
sean-k-mooney | so you plan ot extend https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L359-L362 | 14:42 |
sean-k-mooney | if check_can_live_migrate_destination was passed the currnt mdev type and uuid touple | 14:42 |
sean-k-mooney | and did the claim and populated it in migrate_data | 14:42 |
sean-k-mooney | i would be happy with that | 14:43 |
sean-k-mooney | that would be like how sriov works | 14:43 |
sean-k-mooney | what i didnt really liek about your proposal is it was only checking the types | 14:43 |
sean-k-mooney | we currntly call into the driver here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L8537-L8539 | 14:45 |
opendevreview | Merged openstack/nova-specs master: Re-propose "Add maxphysaddr support for Libvirt" for 2024.1 Caracal https://review.opendev.org/c/openstack/nova-specs/+/895135 | 14:45 |
sean-k-mooney | so you could update the in memory dict and pass back the uuids there | 14:46 |
sean-k-mooney | for sriov we do the claim here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L8563-L8565 but that is not in the driver specific section since the pci_tracker is driver independent | 14:47 |
bauzas | yeah I saw your optimization point | 14:47 |
bauzas | and yeah I saw for SRIOV | 14:47 |
sean-k-mooney | its not just optimisztion | 14:47 |
sean-k-mooney | what im hoping to prevent is racing for the same mdev betwen boots and live migrations | 14:47 |
sean-k-mooney | so if we can atomically allocate the mdev that will be used in check_can_live_migrate_destination | 14:48 |
sean-k-mooney | then i think that helps prevent a subset of possibel issues | 14:48 |
sean-k-mooney | perhaps im wrong but that was part of the motivation | 14:48 |
bauzas | oh | 14:49 |
bauzas | I see | 14:49 |
sean-k-mooney | doiong only the tyep check here seams wasteful but if we also selefct the mdev here | 14:49 |
bauzas | I need to remember | 14:49 |
sean-k-mooney | then im all for it | 14:49 |
bauzas | because I cared about the races indeed | 14:49 |
bauzas | and I wanted to reserve the mdev as close as we claim | 14:49 |
sean-k-mooney | for sriov it slight diffent as we have 3 states avaiable claimed and allocated | 14:50 |
bauzas | that's why I added the 'claim' in post_claim_migrate_data() | 14:50 |
bauzas | as it was literally just after the claim | 14:50 |
sean-k-mooney | the diffent between the later too is cliamed means the vm is not running on the node yet and allcoated is after it is | 14:50 |
bauzas | we could 'claim' those mdevs a bit ealier | 14:50 |
bauzas | but that means we would claim by check_can_live_migrate_destination() | 14:51 |
sean-k-mooney | yes | 14:51 |
sean-k-mooney | so i would like to do that | 14:51 |
bauzas | wfm | 14:51 |
bauzas | so we would return the tuple like you said | 14:52 |
bauzas | sounds good to me | 14:52 |
sean-k-mooney | ok care to update that in the spec and im happy to review | 14:52 |
bauzas | yeah, I'll try | 14:52 |
bauzas | I'm also packed with meetings the day along :) | 14:52 |
sean-k-mooney | the one i was in finished early so i had a break | 14:52 |
bauzas | happy you | 14:52 |
bauzas | next one sounds optional to me | 14:53 |
bauzas | so I'll probably have time | 14:53 |
gibi | Is it me or we don't have vTPM tempest tests? Would it be possible to run a simple server create with vTPM in the gate? | 15:15 |
bauzas | can't tell | 15:47 |
bauzas | gibi: I guess we need to use barbican for this, right? | 15:48 |
bauzas | so it would be a specific job | 15:48 |
bauzas | enabling both vTPM and barbican | 15:49 |
gibi | right it needs barbican | 15:49 |
bauzas | https://github.com/openstack/nova/blob/master/.zuul.yaml#L897C37-L897C37 | 15:49 |
bauzas | gibi: ^ | 15:50 |
bauzas | I just see barbican but without vTPM https://opendev.org/openstack/barbican-tempest-plugin/src/branch/master/.zuul.yaml#L23-L59 | 15:53 |
gibi | OK, so our default jobs does not have barbican, but we have a separate job with barbican | 15:54 |
bauzas | correct, but we run barbican jobs on our check pipeline | 15:55 |
bauzas | https://zuul.opendev.org/t/openstack/builds?job_name=barbican-tempest-plugin-simple-crypto&skip=0 | 15:55 |
bauzas | (n-v) | 15:56 |
bauzas | but I'm not able to see a single job definition setting vtpm | 15:56 |
gibi | I will try to put together a simple tempest test that boot a VM with vtpm, and put it behind a tempest feature flag. Then we can try to enable that flag in our barbican doc | 16:10 |
gibi | s/doc/job/ | 16:10 |
bauzas | sean-k-mooney: I now remember why I needed to do the claim in post_claim_migrate_data() and not in one lockstep by check_can_live_migrate_destination() | 16:32 |
bauzas | tl;dr: when we call check_can_live_migrate_destination(), we don't know neither the used mdev from the guest nor its type | 16:33 |
bauzas | we just have an instance object | 16:33 |
bauzas | so we need this kind of tic-tac-toe between dest>src>dest | 16:34 |
bauzas | call it TCP handshake :p | 16:34 |
artom | gibi, we have vTPM tests in whitebox | 16:43 |
artom | gibi, example run: https://70d77d1b8efad238ddf5-24c1b4d0bad6f112f42872ab6905686e.ssl.cf5.rackcdn.com/824772/32/check/whitebox-devstack-multinode/2a8b9df/testr_results.html | 16:45 |
artom | (expand the last line) | 16:45 |
gibi | nice | 16:45 |
gibi | thanks | 16:45 |
gibi | now I just need to figure out if we have whitebox available in our tempest container used in openstack-k8s-operators testing... | 16:45 |
artom | Out of the box? I suspect not, but hopefully they have the framework in place to add arbitrary tempest plugins | 16:46 |
gibi | artom: we will see shortly https://github.com/openstack-k8s-operators/openstack-operator/pull/589 :D | 16:56 |
sean-k-mooney | bauzas: i see. thats less then ideal but if you can docuemnt it in the spec i guess i can live with that for now | 17:07 |
sean-k-mooney | im not really sure how to adress that otherwize | 17:07 |
sean-k-mooney | im not sure we reallly need to do the mdev type check at the conducor level | 17:08 |
sean-k-mooney | but if you think it helps then ok | 17:08 |
bauzas | sean-k-mooney: I can write something indeed explaining more the ping-pong | 17:08 |
sean-k-mooney | thanks | 17:08 |
bauzas | sean-k-mooney: we could just pass the source mdevs to the dest and then the dest would claim a type | 17:09 |
bauzas | so basically removing the first item | 17:09 |
bauzas | dest would claim a *mdev* | 17:09 |
sean-k-mooney | right that why i was orginlly suggetion jsut doing it in pre_live_migrate | 17:10 |
bauzas | pre_live_migration is after the claim | 17:10 |
bauzas | so I think we need to reserve the mdev in the conductor call to compute | 17:10 |
sean-k-mooney | but we dont have the mdev types at that point right | 17:11 |
sean-k-mooney | form the souce node | 17:11 |
sean-k-mooney | well i guess | 17:11 |
sean-k-mooney | we can claim them | 17:11 |
sean-k-mooney | but we wont detect if the type are diffent | 17:11 |
sean-k-mooney | until after we call the souce node | 17:11 |
sean-k-mooney | so we will claim them on the test | 17:11 |
sean-k-mooney | then apass the info to the soruce with the types | 17:11 |
sean-k-mooney | and it can check if they change and abort | 17:12 |
bauzas | hum | 17:12 |
bauzas | actually, this is not possible, damn | 17:13 |
bauzas | we call the destination first, then we call the sourcer | 17:13 |
bauzas | and then we claim | 17:13 |
sean-k-mooney | right but the call to the dest coudl do the claim | 17:17 |
sean-k-mooney | then pass to the souce to confirm if the types match | 17:17 |
sean-k-mooney | actully no | 17:17 |
sean-k-mooney | we are stuck with the 3 stpes i think | 17:17 |
sean-k-mooney | lets pick up this converstaion tomorrow | 17:17 |
gibi | artom: we have a chance https://github.com/openstack-k8s-operators/tcib/blob/4aef81881de941f0251aa848515243f666b18672/container-images/tcib/base/os/tempest/tempest-extras/tempest-extras.yaml#L4 | 17:32 |
artom | Oh wow | 17:32 |
artom | jparker++ | 17:32 |
artom | I'm assuming he's to blame :D | 17:32 |
artom | (Not literal `git blame`) | 17:33 |
gibi | almost :) https://github.com/openstack-k8s-operators/tcib/commit/199178028bba73548e21df5171a620df7981b451 | 17:34 |
artom | James was pulling the strings | 17:40 |
gibi | indeed, he is still pulling it https://github.com/openstack-k8s-operators/tcib/pull/110 | 17:41 |
artom | He's pull requesting them :D | 17:42 |
gibi | exactly :D | 17:46 |
opendevreview | melanie witt proposed openstack/nova master: Set UEC image vars for jobs not defined in Nova https://review.opendev.org/c/openstack/nova/+/902809 | 19:04 |
sean-k-mooney | melwitt: oh right i guess we should do that for those too | 19:15 |
sean-k-mooney | ill try and take a look at ^ tomorrow | 19:17 |
sean-k-mooney | one thing we might want to consider is actully makeing this change in the base devstack job | 19:18 |
sean-k-mooney | nova is really the only project that likely cares about testing the full disk image code path | 19:18 |
sean-k-mooney | so defaulting to the uec image might be worth considering in the tempest/devstack base job | 19:18 |
sean-k-mooney | gmann: ^ we should proably conisder that after we have run nova on them for a few weeks | 19:19 |
gmann | sean-k-mooney: melwitt yeah, i am thinking on that, if not default at least we can do that for most of the general integrated jobs in tempest and keep a few of them for example tempest-full-py3 on full image | 19:20 |
gmann | yes, let's observe it in nova for a few weeks first | 19:21 |
melwitt | sean-k-mooney, gmann: I realized the above (jobs not defined in nova) bc I saw tempest-integrated-compute fail on the follow up patch and it was the guest kernel panic. at first I was confused how/why could that be if we've got the UEC image but then I realized it is _not_ using the image bc I had only set the vars for the jobs defined by us in our .zuul.yaml | 19:34 |
sean-k-mooney | yep i forgot about the other jobs too | 19:35 |
melwitt | sean-k-mooney: semi related to that, I had been meaning to ask you, why does using the UEC image work to avoid guest kernel panics? | 19:35 |
melwitt | just a curiosity question | 19:36 |
opendevreview | Merged openstack/nova-specs master: Add spec for PCI Groups https://review.opendev.org/c/openstack/nova-specs/+/899719 | 19:40 |
sean-k-mooney | melwitt: i dont actully know. i suspect it takign a slightly diffent path in both qemu and in the init shell script | 19:41 |
sean-k-mooney | melwitt: i know neutron had previosuly added apci=off or something like that | 19:41 |
sean-k-mooney | to disable the apic timer | 19:41 |
melwitt | ah ok | 19:41 |
sean-k-mooney | but they dont actully do that any more | 19:41 |
sean-k-mooney | basiclly one of the panics suggeted doign that and when you use the split image | 19:42 |
sean-k-mooney | nova supprot passing kernel command line args to qemu | 19:42 |
sean-k-mooney | so orginally they explored this just to follow the mesage output which said A X to the command line to turn this off | 19:42 |
sean-k-mooney | melwitt: https://bugs.launchpad.net/openstack-gate/+bug/1713162 | 19:45 |
sean-k-mooney | Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. | 19:45 |
sean-k-mooney | so ya they orgianlly tied setting noapic on the kernel commadn line | 19:45 |
melwitt | ohh I see | 19:45 |
sean-k-mooney | i "fixed" this a diffent way in devstack | 19:46 |
sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.libvirt_disable_apic | 19:46 |
sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/766043 and https://github.com/openstack/devstack/commit/1e86a25cc28e34d7f73a4c6ccbbc3fc667598d50 | 19:47 |
sean-k-mooney | lee actully enabeld it in devstack | 19:48 |
melwitt | oh, so using the split image seems to be a way to alleviate the problem without disabling the apic timer? | 19:48 |
sean-k-mooney | so i tought at one point we were addign the noapic thign somewhere | 19:48 |
sean-k-mooney | i just dont know where that is exactly | 19:49 |
sean-k-mooney | melwitt: but ya apprently the split imag eis enouch i just cant prove that | 19:49 |
melwitt | well that's confusing. it's already been set to disabled but it was still panicking? 🤔 | 19:50 |
sean-k-mooney | so there are two tings | 19:50 |
sean-k-mooney | the apic and ioapic | 19:50 |
sean-k-mooney | we are disabling the apic | 19:50 |
melwitt | oh | 19:50 |
sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1939108 | 19:51 |
sean-k-mooney | im not sure if i orgianlly got those mixed up or not | 19:51 |
sean-k-mooney | in anycase i think thats a slighly idffent kernel panic | 19:52 |
melwitt | 🤯 | 19:52 |
sean-k-mooney | as that speicic one was a upstrema bug in the cirros iamge kernel that was fixed in a later release | 19:52 |
sean-k-mooney | basically this specific panicn in that bug should not happen in 6.x cirros iamges | 19:52 |
melwitt | I see | 19:53 |
sean-k-mooney | for what its worth it might be interesting to see if we can disabel that workaround once we have moved to the split miage | 19:55 |
sean-k-mooney | *image | 19:55 |
sean-k-mooney | we are using cirros 6.x now so it should not eb required | 19:56 |
melwitt | gotcha | 19:57 |
sean-k-mooney | so we could perhaps deprecate it this cycle and remove it in a future release | 19:57 |
melwitt | none of the panics I have seen had the message that specifically names the APIC timer so that seems to track | 19:57 |
melwitt | (from that bug) | 19:58 |
sean-k-mooney | ya same | 19:58 |
sean-k-mooney | ok im going to call it a day | 20:00 |
sean-k-mooney | ill chekc back on your patches tomorrow o/ | 20:00 |
melwitt | thanks sean-k-mooney, seeya tomorrow o/ | 20:05 |
JayF | sean-k-mooney: I know you're interested in getting sharding in this cycle; I'm trying to land stephen's chain here https://review.opendev.org/c/openstack/nova/+/659691/38 before re-landing sharding; if you want to take a look I think Ironic cores are happy (Ironic CI passes on the head of that chain) | 20:15 |
melwitt | dpawlik: hi, thanks for confirming! it was just a misunderstanding about swift log retention vs opensearch index retention. the swift log retention is 30 days but opensearch retains less. I think this is ok :) | 20:24 |
opendevreview | Merged openstack/nova master: Fix coverage issues with eventlet https://review.opendev.org/c/openstack/nova/+/900116 | 21:32 |
-opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily to restart it onto an updated replication key | 21:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!