June 2023 - openstack-discuss - lists.openstack.org

[cinder] in-use volume retype error "Expecting to find domain in project"
by Eugen Block 20 Jun '23

20 Jun '23

Hi, while trying to reproduce the issue mentioned in [1] I stumbled upon [2], I commented there but because of the "wishlist" importance I don't expect too much attention. I have a production cloud with Victoria where I see the same issue as described in [2], trying to retype an in-use volume results in a stack trace in cinder: 2023-06-20 12:45:52.900 1085571 ERROR oslo_messaging.rpc.server keystoneauth1.exceptions.http.BadRequest: Expecting to find domain in project. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-6b412e96-a735-4b94-a5e6-8252dd949297) I have also a test cloud installed the same way as the production cloud with V and upgraded to Wallaby where this stack trace does not occur, retyping an in-use volume just works there. I tried the described workaround in [1] and added a [nova] section to the cinder.conf, and that worked. There is no such section in the W cloud. I checked the Wallaby release notes and the only thing related to retype with ceph as backend is [3]. Could that make the difference here? One difference between V and W I noticed was that in V I see two volumes with the same name (but a different UUID, of course) during the retype process while in W I see only one volume at all times. So I assume that W handles the retype differently and it doesn't require a nova section. I'd appreciate any comment. Thanks, Eugen [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-June/034160.ht… [2] https://bugs.launchpad.net/cinder/+bug/1941062 [3] https://bugs.launchpad.net/cinder/+bug/1886543

1 0

OpenStack (cinder) volumes retyping on Ceph back-end
by Andrea Martra 20 Jun '23

20 Jun '23

Hello, I configured different back-end storage on OpenStack (Yoga release) and using Ceph (ceph version 17.2.4) with different pools (volumes, cloud-basic, shared-hosting-os, shared-hosting-homes,...) for RBD application. I created different volume types towards each of the backends and everything works perfectly. If I perform a "change volume type" from OpenStack on volumes attached to the VMs the system successfully migrates the volume from the source pool to the destination pool and at the end of the process the volume is visible in the new pool and is removed from the old pool. The problem encountered is that when reconfiguring the VM, to specify the new pool associated with the volumes (performed through a resize of the VM, I haven't found any other method to change the information on the nova/cinder db automatically. I also did some tests shut-off of the VM and modification of the xml through virsh edit and startup the VM) the volume presented to the VM is exactly the version and content on the retype date of the volume itself. All data written and modified after the retype is lost. The VM after the retype continues to work perfectly in RW but the "new" volume created in the new pool is not used to write data and consequently when the VM is shut down all the changes are lost. Do you have any idea how to carry out a check and possibly how to proceed in order not to lose the data of the vm of which I have retyped the volume? The data is written somewhere (the IO is still going to the old pool/image although they already have been removed) because the VMs work perfectly. Thank you -- Andrea Martra +39 393 9048451

1 0

[kolla] rabbitmq failed to build image using 2023.1 release
by Satish Patel 20 Jun '23

20 Jun '23

Folks, Do you know how to solve this? I am using release 2023.1 of kolla to build images using ubuntu 22.04 root@docker-reg:/opt/kolla/etc/kolla# kolla-build --registry docker-reg:4000 --config-file kolla-build.conf --debug --threads 1 --skip-existing --push --cache --format none rabbitmq INFO:kolla.common.utils:Using engine: docker INFO:kolla.common.utils:Found the container image folder at /usr/local/share/kolla/docker INFO:kolla.common.utils:Added image rabbitmq to queue INFO:kolla.common.utils:Attempt number: 1 to run task: BuildTask(rabbitmq) DEBUG:kolla.common.utils.rabbitmq:Processing INFO:kolla.common.utils.rabbitmq:Building started at 2023-06-11 02:25:44.208880 DEBUG:kolla.common.utils.rabbitmq:Turned 0 plugins into plugins archive DEBUG:kolla.common.utils.rabbitmq:Turned 0 additions into additions archive INFO:kolla.common.utils.rabbitmq:Step 1/11 : FROM docker-reg:4000/kolla/base:2023.1 INFO:kolla.common.utils.rabbitmq: ---> 4551f4af8ddf INFO:kolla.common.utils.rabbitmq:Step 2/11 : LABEL maintainer="Kolla Project (https://launchpad.net/kolla)" name="rabbitmq" build-date="20230611" INFO:kolla.common.utils.rabbitmq: ---> Using cache INFO:kolla.common.utils.rabbitmq: ---> 6c2ef10499f7 INFO:kolla.common.utils.rabbitmq:Step 3/11 : RUN usermod --append --home /var/lib/rabbitmq --groups kolla rabbitmq && mkdir -p /var/lib/rabbitmq && chown -R 42439:42439 /var/lib/rabbitmq INFO:kolla.common.utils.rabbitmq: ---> Using cache INFO:kolla.common.utils.rabbitmq: ---> 29ef8940f40b INFO:kolla.common.utils.rabbitmq:Step 4/11 : RUN echo 'Uris: https://ppa.launchpadcontent.net/rabbitmq/rabbitmq-erlang/ubuntu' >/etc/apt/sources.list.d/erlang.sources && echo 'Components: main' >>/etc/apt/sources.list.d/erlang.sources && echo 'Types: deb' >>/etc/apt/sources.list.d/erlang.sources && echo 'Suites: jammy' >>/etc/apt/sources.list.d/erlang.sources && echo 'Signed-By: /etc/kolla/apt-keys/erlang-ppa.gpg' >>/etc/apt/sources.list.d/erlang.sources && echo 'Uris: https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/deb/ubuntu' >/etc/apt/sources.list.d/rabbitmq.sources && echo 'Components: main' >>/etc/apt/sources.list.d/rabbitmq.sources && echo 'Types: deb' >>/etc/apt/sources.list.d/rabbitmq.sources && echo 'Suites: jammy' >>/etc/apt/sources.list.d/rabbitmq.sources && echo 'Signed-By: /etc/kolla/apt-keys/rabbitmq.gpg' >>/etc/apt/sources.list.d/rabbitmq.sources INFO:kolla.common.utils.rabbitmq: ---> Using cache INFO:kolla.common.utils.rabbitmq: ---> 6d92a7342a90 INFO:kolla.common.utils.rabbitmq:Step 5/11 : RUN apt-get --error-on=any update && apt-get -y install --no-install-recommends logrotate rabbitmq-server && apt-get clean && rm -rf /var/lib/apt/lists/* INFO:kolla.common.utils.rabbitmq: ---> Running in 0deab7961445 INFO:kolla.common.utils.rabbitmq:Get:1 http://ubuntu-cloud.archive.canonical.com/ubuntu jammy-updates/antelope InRelease [5,463 B] INFO:kolla.common.utils.rabbitmq:Get:2 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [108 kB] INFO:kolla.common.utils.rabbitmq:Get:3 http://mirrors.ubuntu.com/mirrors.txt Mirrorlist [3,447 B] INFO:kolla.common.utils.rabbitmq:Get:7 http://ubuntu-cloud.archive.canonical.com/ubuntu jammy-updates/antelope/main amd64 Packages [126 kB] INFO:kolla.common.utils.rabbitmq:Get:8 https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/deb/ubuntu jammy InRelease [5,152 B] INFO:kolla.common.utils.rabbitmq:Get:9 https://ppa.launchpadcontent.net/rabbitmq/rabbitmq-erlang/ubuntu jammy InRelease [18.1 kB] INFO:kolla.common.utils.rabbitmq:Get:5 http://mirror.siena.edu/ubuntu jammy-updates InRelease [119 kB] INFO:kolla.common.utils.rabbitmq:Get:10 https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/deb/ubuntu jammy/main amd64 Packages [9,044 B] INFO:kolla.common.utils.rabbitmq:Get:6 http://ftp.usf.edu/pub/ubuntu jammy-security InRelease [110 kB] INFO:kolla.common.utils.rabbitmq:Get:11 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 Packages [27.0 kB] INFO:kolla.common.utils.rabbitmq:Get:4 https://archive.linux.duke.edu/ubuntu jammy InRelease [270 kB] INFO:kolla.common.utils.rabbitmq:Get:12 http://archive.ubuntu.com/ubuntu jammy-backports/main amd64 Packages [49.4 kB] INFO:kolla.common.utils.rabbitmq:Get:14 http://ubuntu.osuosl.org/ubuntu jammy-updates/main amd64 Packages [857 kB] INFO:kolla.common.utils.rabbitmq:Get:17 https://ppa.launchpadcontent.net/rabbitmq/rabbitmq-erlang/ubuntu jammy/main amd64 Packages [8,167 B] INFO:kolla.common.utils.rabbitmq:Get:16 http://pubmirrors.dal.corespace.com/ubuntu jammy-security/universe amd64 Packages [928 kB] INFO:kolla.common.utils.rabbitmq:Get:15 https://atl.mirrors.clouvider.net/ubuntu jammy-security/main amd64 Packages [575 kB] INFO:kolla.common.utils.rabbitmq:Get:19 http://www.club.cc.cmu.edu/pub/ubuntu jammy/main amd64 Packages [1,792 kB] INFO:kolla.common.utils.rabbitmq:Get:18 http://mirror.team-cymru.com/ubuntu jammy/universe amd64 Packages [17.5 MB] INFO:kolla.common.utils.rabbitmq:Get:13 http://mirrors.syringanetworks.net/ubuntu-archive jammy-updates/universe amd64 Packages [1,176 kB] INFO:kolla.common.utils.rabbitmq:Fetched 23.7 MB in 6s (4,091 kB/s) INFO:kolla.common.utils.rabbitmq:Reading package lists... INFO:kolla.common.utils.rabbitmq:Reading package lists... INFO:kolla.common.utils.rabbitmq:Building dependency tree... INFO:kolla.common.utils.rabbitmq:Reading state information... INFO:kolla.common.utils.rabbitmq:Some packages could not be installed. This may mean that you have INFO:kolla.common.utils.rabbitmq:requested an impossible situation or if you are using the unstable INFO:kolla.common.utils.rabbitmq:distribution that some required packages have not yet been created INFO:kolla.common.utils.rabbitmq:or been moved out of Incoming. INFO:kolla.common.utils.rabbitmq:The following information may help to resolve the situation: INFO:kolla.common.utils.rabbitmq:The following packages have unmet dependencies: INFO:kolla.common.utils.rabbitmq: rabbitmq-server : Depends: erlang-base (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: erlang-base-hipe (< 1:26.0) but it is not installable or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-crypto (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-eldap (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-inets (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-mnesia (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-os-mon (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-parsetools (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-public-key (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-runtime-tools (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-ssl (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-syntax-tools (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-tools (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq: Depends: erlang-xmerl (< 1:26.0) but 1:26.0.1-1rmq1ppa1~ubuntu22.04.1 is to be installed or INFO:kolla.common.utils.rabbitmq: esl-erlang (< 1:26.0) but it is not installable INFO:kolla.common.utils.rabbitmq:E: Unable to correct problems, you have held broken packages. INFO:kolla.common.utils.rabbitmq:

3 8

[tc] Technical Committee next weekly meeting on June 20, 2023
by Nikolla, Kristi 20 Jun '23

20 Jun '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday, June 20, 2023 at 1800 UTC on #openstack-tc on OFTC IRC. Please find below the agenda for the meeting: * Roll call * Follow up on past action items * Open Infra Summit retrospective * Gate health check * Open Discussion and Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open More information can be found and items proposed at the following link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Thank you, Kristi Nikolla

1 0

[puppet] Summary of discussions at PTG Vancouver June 2023
by Takashi Kajinami 20 Jun '23

20 Jun '23

Hello, Thank you all for joining our PTG session ! It was really nice to meet some of the team members in person. The etherpad for the discussion can be found in the link below, but I'll share a summary of our discussions in this email. In case you have any questions/concerns then feel free to let me know. https://etherpad.opendev.org/p/vancouver-june2023-puppet-openstack - Status update - We share the status of each person. - Unfortunately all of the members attending the discussion have limited resources especially for development - *Agreement:* we focus on priorities and de-prioritize items which does not cause immediate problems/breackages - *Agreement: *we ensure we finish the prioritized items in a specific release to keep our maintenance simple - Puppet 8 support - We added unit/lint tests with Puppet 8 for early testing, but adding integration tests is currently blocked by some ruby dependencies not yet available for Ruby 3.1 which is required by Puppet 8. - All of the operating system versions do not provide Ruby 3.1 now - Puppet 7 EOL is not yet declared - *Agreement*: We leave this as non-priority for now and re-work on it once Ruby 3.1 is globally available - Adaptation to puppetlab-stdlib 9.0.0 - Some deprecated items were removed. We adapted our modules but are still waiting for update in the dependent modules - validate_legacy was deprecated and causes large warning no*w* - Functions from stdlib should be now namespace-d to avoid warnings after bump is done - *Agreement:* We prioritize replacing validate_legacy by typed parameters - *Agreement*: We pin stdlib to an older version for now but attempt to bump it early - Module modernizations - Typed parameters - Replacing validate_legacy needs to be prioritized now to adapt to puppetlab-stdlib 9.0.0 - Implementing type validations for openstack config options require further discussions. Handling of os_service_defualt would be the main topic we have to sort - We prefer consistent implementations for all openstack service modules, while we can attempt some changes early in a few "independent" modules such as extras, vswitch, qdr - *Agreement: *We de-prioritize implementing validations for config options - *Agreement: *We ensure implementations is distributed to all modules consistently in a single release - Hieradata - This is "modern" design pattern, and it's ideal to replace legacy params class by it - However we don't have urgent requirement to complete this work - We have to create the common structure for hieradata files maintained in each repositories - Some concerns have been raised mainly how we can pick up some values once this change is made - *Agreement: *We de-prioritize this work for now - *Agreement: *We can start with the flat files (pattern 1 in https://etherpad.opendev.org/p/puppet-hieradata-structure ) - *Agreement: *tkajinam will submit a few examples and we review how this impact the existing usage - *Agreement: *Similarly to typed parameters, we should coordinate this work to make the change consistently - Making distro/version specific logic selectable by parameters - This work is tightly related to the hieradata work - *Agreement: *We basically leave this work until the above hieradata work is completed, and de-prioritize this. - Branch retirements - We have multiple branches open now and aim to reduce number of branches - Red Hat is interested in keeping train open until 2023Q3 (tentative) and wallaby for some times for donwstream - Others do not have requirement to maintain old releases in EM status - *Agreement: *We aim to retire train/ussuri/branch after 2023Q3. Retiring further branches is subject to future discussions Thank you, Takashi Kajinami

2 1

[nova] Summary of discussions at Vancouver June 2023 (PTG + Forum meet&greet)
by Sylvain Bauza 19 Jun '23

19 Jun '23

Thanks folks that were joining our PTG but also our meet&greet forum session ! IT was again a productive week for us, as we were able to discuss with a lot of operators during around 4 hours (3.30' for the PTG and 30 mins for the forum session) Below you'll find the summary of all the topics we discussed during those hours but you can also look at the etherpads directly : * Nova meet&greet https://etherpad.opendev.org/p/nova-vancouver2023-meet-and-greet * Nova PTG sessions https://etherpad.opendev.org/p/vancouver-june2023-nova While there were unfortunately very few Nova maintainers and developers in both rooms, we've seen a packed room for the meet&greet and then at every hour of the PTG, we got at least one operator wanting to discuss with us. Can't tell how much I love this, hopefully we'll continue to discuss it between us afterwards. Now, let me tell you the summary : === Short survey at the meet&greet === * most of the operators (~21) in the meet&greet were either running Train or Yoga. Some of them were already running 2023.1 Antelope. Wow. * all of them were running libvirt but one running ironic driver. * using virtual GPUs/mdevs and setting flavors to define CPU usage were the two most in-use features (the next one is SR-IOV) * accordingly, the most needed missing quotas are for PCI devices, obviously. === Pain points at the meet&greet === * Availability zones : Basically, some operators use massively AZs and they want to get off some AZ (even if the instance is pinned) for maintenance reasons. We continued to discuss this usecase at the PTG (see below) * Update of userdata : we said this was coming with a proposed spec * Filtering flavors by a resource : this would require a nova spec * Hard affinity problems : we continued to discuss this at the PTG (see below) * Ceph backend for Nova compute and need for local ephemeral storage (case of GPUs) : this should be discussed in a spec * attach/detach issues with BDMs : we said this is a known issue, some bug report has to be filled for proper triaging * state of CVEs and the fact that old releases are still impacted : this is known and relates to the state of Extended Maintenance releases, which was addressed by another Forum session. === The PTG === * Affinity/Anti-affinity migration problems if hard policy : we explained the consensus we had at the Bobcat vPTG and a Bloomberg operator kindly volunteered to capture this agreement in a backlog spec (tl,dr: allow operators to violate the policy and let the servergroup API show the violation). More to come hopefully soon. * Exposing metrics : Some operator explained how the current use of Prometheus exporter is super slow since it's using the Nova APIs for gathering usage metrics. We proposed him to look into using Placement APIs for such case, he'll test and eventually come back to us if the existing Placement APIs aren't viable for him. * memfd-backed memory backing per instance : there are multiple concerns that need to be addressed in a spec. For example, we need to ensure the flavor extraspec is driver-agnostic, we need to care about the defaults and the potential upgrade concerns (like changing from anonymous to memfd) and how to interact with the existing hugepages feature in Nova. * using virtio9p instead of virtiofs for Manila shares : we discussed it intensively to eventually come up to the conclusion this wasn't worth the effort to implement it. Let's revisit this decision by the next PTG if no progress has been made on virtiofs migration feature gaps. * Manila/Nova cross-project PTG discussion on Manila share support : we discussed on the next Manila features (lock API and use of service roles). We agreed on the mandatory Nova configuration for service roles as a requirement for Manila shares usage. We also agreed on Manila storing the instance UUID as the semaphore for the lock API. FWIW, there was a packed table with 7 operators (all public clouds) *REALLY* interested in this feature [1]. That's it for Nova-related bits at Vancouver but other topics were worth being discussed. You can find the list of all discussed Forum sessions here : https://wiki.openstack.org/wiki/Forum/Vanvouver2023 I've found particular interest in the ExtendedMaintainance potential abandon discussion, OSC and SDK sessions, live-migration usecases and problems and a couple of others. I'd urge you to glance at all etherpads' contents. [1] https://photos.app.goo.gl/t1tSyk67GG6TRRW59 HTH, -Sylvain

1 0

[neutron] Bug deputy report (June-12 - June-18)
by Lajos Katona 19 Jun '23

19 Jun '23

Hey Neutrinos, I was the bug deputy last week, so I send the summary from last week. GATE ISSUES: these seems to be related to OVN version bump and https://review.opendev.org/c/openstack/neutron/+/883681: * Gate: Fuctional test_virtual_port_host_update failes recently (#link https://bugs.launchpad.net/neutron/+bug/2023634 ) ** *Unassigned* * [trunk ports] subport doesn't reach status ACTIVE (#link https://bugs.launchpad.net/neutron/+bug/2024160 ) ** *Unassigned* HIGH * n-d-r: Peering failing on mixed IPv4 + IPv6 updates (#link https://bugs.launchpad.net/neutron/+bug/2023632 ) ** Dr. Jens Harbott * [OVN] Hash Ring nodes removed when "periodic worker" is killed (#link https://bugs.launchpad.net/neutron/+bug/2024205 ) ** Lucas Alvares Gomes * Adding a static route to router returns internal server error (#link https://bugs.launchpad.net/neutron/+bug/2024251 ) ** *Unassigned* MEDIUM * [sqlalchemy-20] Remove redundant indexes of some tables (#link https://bugs.launchpad.net/neutron/+bug/2024044 ) ** Rodolfo Alonso * OVN: Removal of chassis results in unbalanced distribution of LRPs (#link https://bugs.launchpad.net/neutron/+bug/2023993 ) ** *Unassigned* * create_subnet policy allows users to create subnet in the shared networks (#link https://bugs.launchpad.net/neutron/+bug/2023679 ) ** Slawek Kaplonski Lajos Katona (lajoskatona)

1 0

[heat] Heat discussions at PTG Vancouver June 2023
by Takashi Kajinami 19 Jun '23

19 Jun '23

Hello, Thank you all who attended the PTG discussions last week at Vancouver. We were small but it was nice to meet/see you in person and discuss how we can improve our projects I'll share a summary of the PTG discussions and also a few more topics related to our projects, which were discussed during Forum sessions. Please let me know if you have any questions or concerns. PTG sessions: - We exchanged information about how we use heat downstream. Jonathan and Alan from Georgia Cyber Center explained their quite interesting usage to launch an lab environment for their end users. - There are still a number of resource properties not yet supported by Heat but we want to prioritize implementations according to actual needs. We suggested creating a storyboard story in case any user finds out any missing properties to cover their use case. - Jonathan shared a very nice demo about their visualizer of heat stacks[1], which gives more meaningful visualization based on resource types. We agreed this can replace the current implementation in heat dashboard. We agreed that we'll explore if we can integrate this and deprecate the current implementation. [1] https://gitlab.com/gacybercenter/open/openstack-top-graph Forum sessions: - In SRBAC sessions status of individual projects were shared. Heat is lagging behind now and we have to focus on completing step 1(removing system scope). - In TC/Community Leaders communication, we agreed we are setting a timeline to bump sqlalchemy to 2.0 (followup would be sent separately). We removed usage of sqlalchemy-migrate as the first step to adapt sqlalchemy 2.0 but we still need some work for full adoption. We first need to add some testing as was done in Neutron already. Thank you, Takashi Kajinami

1 0

[nova] update_resources_interval parameter
by Arnaud Morin 19 Jun '23

19 Jun '23

Hey team, I'd like to understand the stakes behing the update_resources_interval parameter ([1]) We decided on our side to increase this value from 60sec to 600sec (see [2]). What I understand is that is will "delay" the update of metrics on nova side. I mostly think that these metrics are used by filter scheduler to select the best host when scheduling. Is there anything else it can affect? Cheers, Arnaud. [1] https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.up… [2] https://review.opendev.org/c/openstack/large-scale/+/886166

3 3

[kolla-ansible][zun] Deleting container within code without authentication
by James Leong 19 Jun '23

19 Jun '23

Hi all, I am currently playing around with the Zun component. I have deployed the yoga version of OpenStack using kolla-ansible. Is there a way to delete a container in the code base by giving the container id? It seems like without the proper context or authentication information, I will not be able to remove the container when calling the delete function in zun/api/controllers/v1/containers.py since the compute_api will not work. Would it be possible to create fake admin info within the code to enforce the container to be deleted? Apart from that, how can I create a compute API object from scratch? Best, Jame

1 0