April 2024 - openstack-discuss - lists.openstack.org

[openstack-helm] 2024.2 PTG summary
by Vladimir Kozhukalov 16 Apr '24

16 Apr '24

Dear Openstack-helmers, Here is the short summary of our discussion during PTG 2024.2. If you would like to further discuss some of these topics or have any other questions you are welcome to continue the discussion either in this mailing thread or start a new one. ## Migration from legacy Ceph OSH charts to Rook During 2024.1 we developed the migration procedure which seems to work well at least for some configurations. At the moment we have a doc [1] that describes the procedure and also there is a script [2] which can be used as an example. The procedure is obviously quite dangerous and we decided to put some efforts to create a test job for this. Anyway, at this point it is recommended to use Rook for managing Ceph clusters. Once we have the migration test job and we are sure it works well enough we will officially deprecate the legacy Ceph charts with the deprecation period of one or two release cycles. ## MariaDB operator At the moment the OSH MariaDB chart [3] is recommended by default for managing MariaDB clusters. We are not yet ready to switch to the MariaDB-operator [4] (and the mariadb-cluster OSH chart [5]) by default for our test jobs. We will continue supporting MariaDB-operator test job and will try to work closer with the operator community. Ideally, we would like the MariaDB-operator project to provide their own Helm chart which we could utilize. ## OVN Our OVN test deployment jobs seem to work well and we can recommend using OVN as the default Openstack networking backend. However, migrating from OVS to OVN is not trivial and assumes addressing at least the following two points: - Currently we don't have the migration procedure like, for example, this [6], [7] in the context of OSH. It would be great to have a volunteer to contribute this. - Some of our users have OVS customizations which seem not to have 1-1 feature parity with OVN. So, even if we have the migration strategy, the feature alignment is going to take some time. We agreed to continue supporting OVS and OVN jobs 50/50 in this release cycle. Also it seems to worth it to initiate a wider discussion about the migration itself and about the timeline. ## Tacker documentation and testing During 2023.2 we added the Tacker chart [8] but it is not mentioned in the user deployment documetation. We agreed that the Tacker team will contribute the Tacker and the Barbican sections to the OSH deployment documentation (Barbican is needed for Tacker). There is a deployment test job for Tacker [9] although it is not currently a part of the check pipeline. We agreed to improve it so it not only deploys the Tacker project but also it should run some test scenarios against it. ## Third party RabbitMQ chart Our long term strategy is to focus more on Openstack charts and to use third parties for manging backend infrastructure wherever possible. So it looks like it worth it to do research regarding possible usage of the RabbitMQ operator [10]. We agreed that we are going to put efforts during 2024.2 release cycle to give it a try and probably to create a test job that will utilize this operator. ## Improve end user experience Most of our users consume the OSH charts as part of their CI/CD infrastructure and consider OSH as a Openstack managing framework rather than end-to-end solution. However, for the new users who would like to try the Openstack running on top of K8s with the minimal efforts it is important to have an experience similar to what they usually have with other Helm charts. This assumes the following - a user has a K8s cluster (possibly with some prerequisites) and the K8s API endpoint - a user has kubectl/helm command line tools configured (to connect to K8s API endpoint) and ready to use (probably from a remote host) - a user is not supposed to clone any git repositories to deploy the Openstack - a user is able to consume Helm charts published on a Helm repo During 2024.1 we have been working to imporove the deploy-env Ansible role to support single/multi-node environments, to make it possible to run kubectl/helm CLI tools from a remote node, to expose Openstack services via Metallb, etc. At this point we are ready to have a test job that will imitate the end user behavior with the only exception that for test jobs we heavily rely on two scripts `get-values-overrides.sh` [11] and `wait-for-pods.sh` [12]. They are not absolutely necessary but still users can benefit from using them and it looks like we can easily move this functionality to a Helm plugin. So, eventually the deployment can be performed with minimal efforts using pre-published charts. ## Widen the range of K8s configurations used for Openstack deployment Now all the test jobs are run with the same K8s configuration (Calico as a CNI, Ingress-Nginx as a ingress controller) and we are trying to stay as less K8s details dependent as possible. At the same time we could probably create test jobs that will exercise some other K8s configurations like for example - Cilium/Kube-Router as a CNI implementation - HAProxy as an ingress controller This seems to be minor, but still volunteers are welcome to contribute. [1] https://docs.openstack.org/openstack-helm/latest/troubleshooting/migrate-ce… [2] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/tools/… [3] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/mariadb [4] https://github.com/mariadb-operator/mariadb-operator [5] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/mariad… [6] https://docs.openstack.org/neutron/latest/ovn/migration.html [7] https://opendev.org/openstack/neutron/src/branch/master/tools/ovn_migration [8] https://opendev.org/openstack/openstack-helm/src/branch/master/tacker [9] https://opendev.org/openstack/openstack-helm/src/branch/master/zuul.d/base.… [10] https://www.rabbitmq.com/kubernetes/operator/install-operator [11] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/tools/… [12] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/tools/… -- Best regards, Kozhukalov Vladimir

1 0

[tc] Next Meeting of Technical Committee Tomorrow, April 16
by Jay Faulkner 16 Apr '24

16 Apr '24

Hi all, The next scheduled meeting of the OpenStack Technical Committee is Tomorrow, Tuesday April 16 at 1800 UTC in #openstack-tc on OFTC. The proposed agenda is: * Roll call * Follow up on tracked action items ** gmann to add grenade skip level job simplification topic in QA PTG ** gmann will send an email to the openstack-discuss list to cancel next week's TC IRC meeting * Gate health check * TC vPTG 2024.2 Follow-ups ** https://etherpad.opendev.org/p/apr2024-ptg-os-tc * TC Chair Election ** https://governance.openstack.org/tc/reference/charter.html#tc-chair * Open Discussion and Reviews See you there! -- Jay Faulkner OpenStack TC Chair

1 0

Red hat Configuration with Ceph(Cephadm tool on ubuntu
by Adivya Singh 15 Apr '24

15 Apr '24

Hi All, Regarding red hat open stack integration with ubuntu ceph installed with ceph adm tool Can you please guide me on this, What file changes need to be in Storage -config, Storage Environment for a Deployer script to pick it up regarding Cinder integration with Ceph Regards Adivya Singh

3 7

[neutron] Bug deputy report (week starting on April 8)
by Bernard Cafarelli 15 Apr '24

15 Apr '24

Hey neutrinos, here is the list of bugs filled during the PTG week - not too long as apparently people were busy attending the PTG sessions! The first 2 bugs are currently unassigned Medium * OVN DNS not working as documented - https://bugs.launchpad.net/neutron/+bug/2059405 Needs further triaging * [OVN] Changing public network MTU does not update router port gateway_mtu option - https://bugs.launchpad.net/neutron/+bug/2060828 Unassigned, reproducer described in bug Low * [ML2][OVS] more precise flow table cleaning - https://bugs.launchpad.net/neutron/+bug/2060587 Patch in progress https://review.opendev.org/c/openstack/neutron/+/915302 Opened RFE * Add 'trusted_vif' field to the port attributes - https://bugs.launchpad.net/neutron/+bug/2060916/ Opinion * already associated floating ip can be associated to another server without check or warning - https://bugs.launchpad.net/neutron/+bug/2060808 * removing floating ip from server does not check the server - https://bugs.launchpad.net/neutron/+bug/2060812 Linked bugs (one for removal, one for reassigning), discussed last week in PTG, waiting on nova team opinion Needs more info * neutron-dhcp-agent attemps to read pid.haproxy but can't - https://bugs.launchpad.net/neutron/+bug/2060974 Discussed on IRC last week, waiting for confirmation but this should soon be closed -- Bernard Cafarelli

1 0

[release] Release countdown for week R-24
by Thierry Carrez 12 Apr '24

12 Apr '24

Welcome back to the release countdown emails! These will be sent at major points in the 2024.2 "Dalmatian" development cycle, which should conclude with a final release on October 2nd, 2024. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2024.2 "Dalmatian" development cycle, assessing Dalmatian community goals and approving Dalmatian specs. General Information ------------------- The Dalmatian cycle is of pretty standard length, 26 weeks. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/dalmatian/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2024.1 "Caracal" release are continued in 2024.2 "Dalmatian" with a similar release model. Upcoming Deadlines & Dates -------------------------- Dalmatian-1 milestone: May 16 -- Thierry Carrez (ttx)

1 0

[cinder][vmt] updating the cinder core security contacts team
by Brian Rosmaita 12 Apr '24

12 Apr '24

Greetings to all people interested in cinder security, The “Cinder Core security contacts” team [0] is a proper subset of the cinder core team who are notified when the OpenStack VMT assigns a private security bug to cinder following the vulnerability management process [1]. The VMT prefers that this group be kept small, so often adding someone entails removing someone else. I propose the following changes: add: - Jon Bernard (current cinder core, and Cinder PTL for Dalmatian) remove: the following people, who have not worked on security bugs over the past few development cycles: - Ivan Kolodyazhny - Sean McGinnis - Walt Boring The Cinder project team thanks Ivan, Sean, and Walt for their past security service to the project. If you have any comments or concerns, please reply on the mailing list before 12:00 UTC Friday 12 April 2024. cheers, brian [0] https://launchpad.net/~cinder-coresec/+members [1] https://security.openstack.org/vmt-process.html

3 3

[openstack][kolla-ansible]
by Nguyễn Hữu Khôi 12 Apr '24

12 Apr '24

Hello. I am testing a case when I lost all my openstack cluster. I just have a full db backup and volumes(my storage node still alive). I deploy a new cluster with same node's name after that I recover db from backup and the cluster is up but I cannot see my instances. When I click on instance tab or volume tab, I see errors: [image: image.png] I hope you will share experiences. Nguyen Huu Khoi

1 2

[openstacksdk][older pythons] Reverting a small mypy change in openstackapi
by Michael Still 12 Apr '24

12 Apr '24

Hi, I discovered the issue fixed by https://review.opendev.org/c/openstack/openstacksdk/+/915199 accidentally while rebased Kerbside patches, and I am wondering who I should ask nicely for a review. Its a relatively small change, but does regress mypy support in return for working correctly on python versions below python 3.10, which we promise to support right now. Thanks, Michael

1 0

[Glance] Dalmatian vPTG Updates
by Pranali Deore 12 Apr '24

12 Apr '24

Hello Everyone, We have concluded Glance Dalmatian vPTG yesterday. I will share the summary early next week. You can find tentative milestone wise priorities for glance in PTG etherpad[1]. Join us in the weekly meeting on Thursday(1400 UTC) if you have any doubts/suggestions. Thanks & Regards, Pranali Deore [1: https://etherpad.opendev.org/p/apr2024-ptg-glance#L390

1 0

[i18n][PTG] I18n SIG 2024.2 (Dalmatian) PTG Planning
by Ian Y. Choi 12 Apr '24

12 Apr '24

Hi, PTG is happening this week. @seongsoo and I have blocked time slots (Thu 21-22 UTC & Fri 14-16 UTC). Anyone can check via https://ptg.opendev.org/ptg.html and please let me know if more discussion is needed during PTG. Those are topics what I am thinking currently but it is open - feel free to suggest any topic to be discussed: - Moving forward on open reviews for i18n: at least, there are several pending items on openstack/i18n repo - openstack/i18n repository structure discussion to embrace the use of weblate - wlc library on tools/weblate and others including the addition of tox environment and corresponding requirements.txt - Pilot work progress discussion on governance translation support on weblate platform - Overall feasible migration plan discussion to sunset translate.openstack.org earlier than zanata.translate.org Discussions will be shared via Etherpad: https://etherpad.opendev.org/p/apr2024-ptg-i18n . Lastly, please don't forget to register if you have forgotten: https://ptg2024.openinfra.dev/ :) Looking forward to a productive PTG with I18n. Thank you, /Ian

2 1

[ironic]About the OS supported by Diskimage-builder
by Junya Noguchi (Fujitsu) 12 Apr '24

12 Apr '24

To whom it may concern. My name is Junya Noguchi. I have some questions about the supported OS for Diskimage-builder operation. Please respond. References https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html Does it mean that the OS that says "work but receive only limited testing and support" works but is not supported? References https://docs.openstack.org/diskimage-builder/latest/ This document describes RHEL and other operating systems that are not supported in the previous question. Are these operating systems supported? Also, are there any plans to support more operating systems in the future? Best regards, Junya Noguchi

4 3

[all][tc] Modernize Python Stack
by Niklas Schwarz 11 Apr '24

11 Apr '24

Hello, I have just ran over the mailing listing post OpenStack 2024.2 testing runtime by Ganshyam Mann [1] on dropping support for python3.8 for the upcoming Openstack 2024.2 release. This post and some small contributions to some openstack components have lead me to write this post. What I would like to suggest to modernize the Python-Stack used for OpenStack. Such a modernization includes: - A current python version - A modern and up to date static code analysis - Introduce type annotations Let me explain what I mean: A current python version: The current supported Python versions are Python 3.8 to Python 3.11 [2]. As of writing, OpenStack Yoga was just moved to unmaintained. To install this release, e.g. on an Ubuntu Jammy operating system the packages are included in the Ubuntu-Packages. The default Python version on an Ubuntu 22.04 operating system is Python3.10. And looking at the support of the Python versions [3] Python 3.8 to 3.10 only receive security updates but the end is near for Python 3.8 to be out of support. The policy defined which Python version should be used for testing [4] will result that Python 3.8 is still used for the OpenStack 2024.1 release [5]. And this will also result in required support for Python3.8 in the upcoming releases of OpenStack. I my opinion the policy should be reworked and the OpenStack releases should be more aggressive on dropping support for older Python versions. Modern features of the language cannot be otherwise be used, therefor improvements in speed, security and general toolchain/ecosystem cannot be fully leveraged. By defining the lower bound of the Python Version we are limiting ourself to this version but we might also reduce the features we can use because of deprecations of the newer versions . A modern and up to date static code analysis: Currently flake8 and pylint are used both of which are modern analysis tools. But their configuration is in my opinion not up to date. Lets have a look at the configuration of the neutron-lib [6]. As seen a lot of rules are disabled by the configuration and are needed at the current moment at the state of the project. In addition some rules need to be adjusted such as the line length (80 characters is a very aggressive limit and on most modern displays a line length of 100 to 120 can fit without any problems, personal opinion). The adjustment of the static code analysis besides opinionated rules will lead me to my third point to modernize the Python stack used Introduce type annotations Python type annotations are well supported in the current Python versions and through the typing package additional types are added. The introduction of type annotations will improve the developer experience. This is also motivated by the Python foundation in pep-484 [7]. Because of the type annotation all modern IDEs can provide (more precise) type hints. The type hints can and in in my experience will reduce the introduction of bugs (accessing members or calling methods, no logical bugs) and will shorten the time to develop a new feature or fix a logical bug and do not run in runtime exceptions. The datatypes passed to a method are clear and we do not need to dig down a rabbithole to find out what is passed to a method. The name of a variable does not always tell the truth. As an example I want to look at a patch [8] for the neutron-vpnaas component. Christian Rohmann and I worked on this patch for the component together (this has also lead me to write this email) to improve the reconciling for VPNaaS. It took as along time to find out that a RouterInformation object is passed in to a method instead of a router but the variable was named router. We both agreed on that in the first place the naming of the variable was wrong but type annotations would have saved us a good amount of time. This does not mean that the naming is not important and that type annotations will save the world, the context which includes the name of variables is important and type annotations will add additional information to the context. And I have just touched the surface on what is possible with the introduction of type annotations, thinking of automatic document generation, test generation, even code generation,... As a reference to my point modernizing the static analysis this can then also include the introduction of mypy to check the types used. Of course such a change cannot be done in one big commit and needs time but I suggest to start adding type annotations and improve the overall code quality of the OpenStack services, starting with the oslo packages as they are used by mostly all OpenStack components. Of course such changes cannot be done for such a huge project in one day. It took a long time to remove support for Python 2. So I do not expect such changes to happen immediately. But it would be nice to have a discussion about it and maybe create a road map and adjust some policy on supported Python versions and create new policies how to write Python code and what additional tools should be used. I can also understand if not everything is possible but the last two points need to be addressed in my opinion. These changes will lead overall to better code quality but most important the introduction to the big code base will be easier for new developers and reviewers will also have a better time. Best regards Niklas [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://docs.openstack.org/tempest/latest/supported_version.html [3] https://devguide.python.org/versions/ [4] https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… [5] https://governance.openstack.org/tc/reference/runtimes/2024.1.html [6] https://github.com/openstack/neutron-lib/blob/master/.pylintrc [7] https://peps.python.org/pep-0484/#rationale-and-goals [8] https://review.opendev.org/c/openstack/neutron-vpnaas/+/875745

15 27

[manila] Cancelling Apr 11th and Apr 18 weekly meetings
by Carlos Silva 11 Apr '24

11 Apr '24

Hello, zorillas! As this is PTG week, let's cancel this week's upstream meeting and also next week's meeting as we usually do. Thank you! carloss

1 0

[kolla-ansible][horizon]Create instance default parameters
by Franck VEDEL 11 Apr '24

11 Apr '24

Hi, With horizon, is it possible de have this default parameter when you create an instance: in source, create a new volume: « No ». And.. if it’s possible, how configure this with kolla-ansible ? Thank’s for your help. Franck

2 4

[keystone] Weekly meeting canceled 10-April-2024
by Dave Wilde 10 Apr '24

10 Apr '24

Hello all, I'm canceling this weeks keystone meeting in lieu of the PTG sessions we're holding today and tomorrow. Hope to see you there! /Dave

1 0

[kolla][kolla-ansible] How to debug container crashing or restarting
by Satish Patel 10 Apr '24

10 Apr '24

Folks, As soon as I deployed opensearch on the Zed release of openstack and found the opensearch_dashborad container kept restarting. So my question is how do I troubleshoot this kind of container crashing issue. Are there any guides to follow like stop container restart tasks and then get inside container check logs etc? I have checked docker logs <container_name> but didn't find any strange issue and logs are empty in /var/log/kolla/opensearch_dashborad/ In short I am clueless and I would like to change restart policy in docker so I can manually restart daemon to debug my issue. This is what logs showing in docker logs opensearch_dashboard INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/index.js INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/meta-data.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/core.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/unevaluated.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/content.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/applicator.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/format-annotation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/validation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/schema.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/index.js INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/meta-data.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/core.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/content.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/applicator.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/validation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/format.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/core INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/format INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/discriminator INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/jtd INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/validation INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/applicator INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/dynamic INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_mo

2 1

[ironic] PTG schedula
by Riccardo Pittau 10 Apr '24

10 Apr '24

Hello ironicers! A quick reminder on the Ironic PTG schedule for this week: Tuesday 09/04 13-17 UTC Wednesday 10/04 13-17 UTC Thursday 11/04 13-16 UTC You can find the full schedule and topics here https://etherpad.opendev.org/p/ironic-ptg-april-2024 Ciao Riccardo

1 2

[Glance] Cancelling Weekly Meeting for this Week
by Pranali Deore 09 Apr '24

09 Apr '24

Hello, As discussed during last week's meeting, cancelling the meeting for this week(11th April) since we all are meeting in PTG. See you all at PTG ! Thanks & Regards, Pranali

1 0

[Octavia] weekly meeting cancelled
by Gregory Thiemonge 09 Apr '24

09 Apr '24

Hi Folks, Tomorrow's weekly meeting is cancelled because of the PTG. Thanks, Greg

1 0

[kolla] cancelling weekly meeting on 10th April
by Michał Nasiadka 09 Apr '24

09 Apr '24

Hello, Since we all met on PTG sessions - let’s cancel weekly meeting this week. See you on 17th April Michał Nasiadka mnasiadka(a)gmail.com

1 0

[all] Package reproducibility: shall we hard-wire our CI to avoid it in the future?
by Thomas Goirand 09 Apr '24

09 Apr '24

Hi, It used to be that a number of packages were not reproducible. If you do not know why reproducibility of packages is important, please read on: https://reproducible-builds.org/ This has been patched numerous times in numerous packages. However, it looks like the community is still not aware of the problem, and how to avoid it. One of the very common pitfall, is adding a default in an oslo.config string, that leaks properties of the build host, like for example the hostname, the number of CPU cores, and so on. Here's a very common example that was commited last summer: https://review.opendev.org/c/openstack/oslo.messaging/+/889425/9/oslo_messa… Yet the fix is super simple, thanks to oslo.messaging sample_default: https://review.opendev.org/c/openstack/oslo.messaging/+/915314 If I'm writing this, it is *not* to point at anyone, especially *not* the commiter of the above patch. it just happen to be the latest occurrence I noticed thanks to the Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068377 This message is only to raise awareness of the problem, and avoid having it happen again. I also wonder: would it be possible to have our CI avoid this type of mistake? It wouldn't be so hard to have the doc build twice, with different hostname, CPUs, etc. configuration, would it? (note: I'm not volunteering, just pushing for the idea...) Cheers, Thomas Goirand (zigo)

2 1

[openstack-helm] PTG schedule
by Vladimir Kozhukalov 09 Apr '24

09 Apr '24

Hey team, This is just a reminder that we booked two hours on Wednesday 04/10/2024 at 13:00 UTC and 14:00 UTC in the Cactus meeting room. Etherpad is here [1]. Feel free to add your topics for the discussion. Booking table is here [2]. [1] https://etherpad.opendev.org/p/apr2024-ptg-os-helm [2] https://ptg.opendev.org/ptg.html -- Best regards, Kozhukalov Vladimir

1 0

OpenStack OVN add secondary external network
by damage.alders-0j＠icloud.com 09 Apr '24

09 Apr '24

I've setup OpenStack version 2023.2 with with devstack on a Ubuntu 22.04 baremetal. I originally had one NIC (eth1, 192.XX.XX.XX) that works fine. Now I added a second NIC (eth2, 10.XX.XX.XX) to my machine and tried to add a secondary external network through: sudo ovs-vsctl add-br br-ex2 sudo ovs-vsctl add-port br-ex2 eth2 sudo ovs-vsctl set open . external-ids:ovn-bridge-mappings=public2:br-ex2 sudo ovs-vsctl set open . external-ids:ovn-cms-options="enable-chassis-as-gw" then my whole machine (including host and all instances) lost dns service, I can only ping ip addresses such as 8.8.8.8 instead of google.com. To be precise, I found out I lose dns service after `sudo ovs-vsctl add-port br-ex2 eth2` command. (Yes, I've moved ip from eth2 to br-ex2, but didn't help) I kept on creating a network and a router: openstack network create public2 --provider-network-type flat --provider-physical-network public2 --external openstack subnet create public2-subnet --network public2 --subnet-range 10.XX.XX.0/24 --no-dhcp --gateway 10.XX.XX.1 --allocation-pool start=10.XX.XX.10,end=10.XX.XX.30 openstack router create bridge-router --external-gateway public2 openstack router add subnet bridge-router shared-public2-subnet At this point, the router is accessible from eth2 after `sudo ovs-vsctl set open . external-ids:ovn-bridge-mappings=public2:br-ex2` command, but after I tried to allocate a floating ip from public2 to any instance, the instance is just not accessible from that ip. My ultimate goal is to be able to allocate floating ip to instances from eth2, so I can access instances from both eth1 and eth2 networks, but now I lost dns service and I'm unable to access instances from the allocated eth2 floating ip. Any suggestions?

1 0

[kolla] Dalmatian vPTG reminder
by Michał Nasiadka 09 Apr '24

09 Apr '24

Hello Koalas, This year the PTG slots are following: Kolla/Kolla-Ansible: Monday, 8th April, 13:00 - 17:00 UTC Kayobe: Tuesday, 9th April, 13:00 - 15:00 UTC You can check the slots always on the PTG website - https://ptg.opendev.org/ Etherpad link: https://etherpad.opendev.org/p/kolla-dalmatian-ptg See you on Monday!

2 1

[neutron] CI Meeting cancelled this week
by Yatin Karel 08 Apr '24

08 Apr '24

Hello Neutron Team !! As discussed over the previous meeting cancelling this week CI meeting for vPTG. -- Thanks and Regards Yatin Karel

1 0

Nova filter based on VM metadata?
by Ken D'Ambrosio 08 Apr '24

08 Apr '24

Hey, all. I'm looking for a way to to filter to a particular aggregate based on arbitrary VM metadata. (E.g., maybe FACTER facts from Puppet that we pass to the VM as metadata.) Could someone point me toward documentation that might outline how to accomplish that? As I see it, there's really one thing I need to understand -- the rest I can probably glean from extant filters: how (or if) a filter could access a given VM's metadata from the API creation request (if that's even possible). Thanks! -Ken

3 3

[nova][ptg] Nova at the Dalmatian vPTG
by Sylvain Bauza 08 Apr '24

08 Apr '24

Hey folks, During this week, the Nova community will discuss on their own topics in between Tuesday-Friday 1300-1700UTC, all of the slots being in the Diablo room. You can find the related connection details and the proposed schedule in the etherpad [1] but here's a rough schedule for people interested in attending our sessions : - *Tuesday* *13:00 UTC - 17:00 UTC* - Nova sessions - retro + dalmatian schedule - nova above k8s - unified limits - *Wednesday 13:00 UTC - 17:00 UTC*: Nova sessions - vmware discussions about scheduling and metadata api - cleaning old microversions ? - ephemeral encryption status and next steps - memory encryption next steps - *Thursday 13:00 UTC - 17:00 UTC* - Nova sessions - stateless firmware support - vTPM detection by libvirt - Gap between legacy deprecated live migration options vs new live migration options - event actions missing in our API - OpenAPI schemas support - *Friday 13:00 UTC - 17:00 UTC* - Nova sessions - SPICE-direct console support + remote-consoles problem - userdata update - volume-backed instance migration requiring SSH conn - can we push removal of tunnelled libvirt migrations in dalmatian or do we need to wait for next slurp? - no validation if queued oslo.messaging messages are targeted for this specific nova-compute (based on hostname) As also said in the etherpad, you're free to add your own topics to the etherpad (at the bottom please) so I can schedule them, but fwiw our sessions will already be pretty packed with a lot of things to discuss so maybe some of the topics will be on a temptative effort. [1] https://etherpad.opendev.org/p/nova-dalmatian-ptg Thanks, -Sylvain

1 1

Fix for arguments for subnet module for Ansible
by George Shuklin 08 Apr '24

08 Apr '24

Hello everyone. I wrote a small fix for subnet Ansible module to allow use of cidr together with subnet_pool, with tests and so on. I got an approval, it passed CI, but it is not merged. What steps are required to have it merged? https://review.opendev.org/c/openstack/ansible-collections-openstack/+/9073… Sorry for nagging.

1 2

[kolla] [Wallaby] Openstack operations 2x slower after rebuilding from RHEL8/Train to RHEL9/Wallaby
by Albert Braden 08 Apr '24

08 Apr '24

After rebuilding a couple of our clusters, moving from Train on RHEL8 to Wallaby on RHEL9, we see all openstack operations taking 2x longer. Even simple database reads such as "openstack user show" average 1.5 seconds on old regions and 3 seconds on rebuilt regions. I enabled debug and poked around in the logs but nothing is jumping out at me. I was thinking maybe mariadb needed to be tuned differently from RHEL8->9 but if I log into the mariadb container and query the database it seems equally fast; I can do 100 simple queries in a second. Where should I be looking for the source of this delay?

5 10

Re:[skyline] Running a Skyline in "subdirectory"
by 吴文相 08 Apr '24

08 Apr '24

Hello, Dmitriy Rabotyagov Sorry for late response, dev team will raise a ticket and update the conclusion later. Thanks Best Regrads Wu Wenxiang Original: From：Dmitriy Rabotyagov <noonedeadpunk(a)gmail.com>Date：2024-03-16 02:45:49(中国 (GMT+08:00))To：openstack-discuss <openstack-discuss(a)lists.openstack.org>Cc：Subject：[skyline] Running a Skyline in "subdirectory"Hey folks, I was looking into a way to make both Horizon and Skyline work at the same time, and found out that I'm not really able to make Skyline to run in sub-URL. So for instance the plan was to place Horizon under /horizon (which is easily doable) and then Skyline under /skyline. However so far I haven't found any setting or anything that would allow me to do so. Basically, I've realized that static content is _really_ static, which means it does have hardcoded URIs: https://opendev.org/openstack/skyline-console/src/branch/master/skyline_con… So either I'm just not realizing the very simple technique which allows to overcome hardcoded in static files URIs (like some rewrite?), or just serving Skyline from a subdirectory is not possible by design... Would be great if someone could share their experience about Skyline and if anyone managed to do what I'm looking for. Thanks in advance

2 1

[neutron][zun] Container not able to communicate via dummy interface
by James Leong 08 Apr '24

08 Apr '24

Hi all, Using the OpenStack dashboard, we have launched two containers, Container-1 and Container-2, on two different hosts, Host-1 and Host-2. We attached both containers to a virtual network called VirtualNet (10.10.20.0/24). During container creation, both of them get an IP address via DHCP, as provided in the figure attached. Container-1 can successfully ping to 10.10.20.176 (Container-2 eth0 address) and Container-2 can successfully ping to 10.10.20.113 (Container-1 eth0 address). After this, we created a dummy interface (dummy0) on Container-1 and assigned an IP address (192.168.20.113). We want to ping 192.168.20.113 from Container-2. Therefore, we added a route in Container-2 using the command "ip add route 192.168.20.113 via 10.10.20.113 dev eth0." The ping is not successful. We captured the packets in Container-1 using tcpdump command on eth0, and we were able to observe that the icmp echo requests are received and the icmp echo replies are generated. However, the responses are not reaching back to Container-2. The screenshot of the tcpdump on eth0 for Container-1 is attached herewith. In the security groups, we added a rule allowing all ICMP traffic (ingress and egress) to 0.0.0.0/0. Any recommendations or suggestions are greatly appreciated. Best, James

1 0

[security-sig] PTG schedule
by Jeremy Stanley 08 Apr '24

08 Apr '24

Quick reminder that the Security SIG has a couple of sessions scheduled at the PTG this week: * Thursday, 2024-04-11, 21:00-22:00 UTC * Friday, 2024-04-12, 13:00-14:00 UTC There are no particular items on the agenda; feel free to join if you have something OpenStack security-related you want to talk about. The relevant Meetpad and Etherpad URLs can be found on https://ptg.opendev.org/ as usual. -- Jeremy Stanley

1 0

[neutron] Bug Deputy Report April 1 - April 7
by Miro Tomaska 08 Apr '24

08 Apr '24

Hello All Below is the bug deputy report for the week of April 1 High: - https://bugs.launchpad.net/neutron/+bug/2060163 - Partially confirmed, making it high since sporadically affects CI Medium: - https://bugs.launchpad.net/neutron/+bug/206005 - Owner: iulhaq RFE: - https://bugs.launchpad.net/neutron/+bug/2059897 - I don't see this being a bug, maybe an RFE? Undecided: - https://bugs.launchpad.net/neutron/+bug/2059902 - Waiting on more validation using filter-validation extension -- Miro Tomaska Senior Software Engineer

1 0

[all] Review dependencies without update for long time
by Takashi Kajinami 07 Apr '24

07 Apr '24

Hello, I recently spent some time reviewing the packages currently in the requirements repo and found some packages which haven't been updated for multiple years. This is a good indication that we have to review the features dependent on these packages to determine if the features should be re-implemented by a different package or dropped. Keeping such features with unmaintained library may likely cause problems in future maintenance (Python 3.12 support is a good example). Ideally we should have done this during 2024.1 cycle because of SLURP, but the sooner is always the better. I'd suggest that all projects spend some time to review the packages which haven't get updated for long time. I quickly grepped the packages which haven't get any bump in 202X and got the list which shows number of libraries. $ git blame -e upper-constraints.txt | grep -e '201[0-9]-' | sed -e 's/.* 201/201/' | sort 2015-06-08 22:09:46 +1200 500) simplegeneric===0.8.1 2016-05-19 06:30:24 +0000 169) extras===1.0.0 2016-11-14 17:07:49 +0000 69) XStatic-Font-Awesome===4.7.0.0 2016-12-18 07:20:50 +0000 583) xvfbwrapper===0.2.9 2017-02-21 14:05:54 -0600 118) pyinotify===0.9.6 2017-02-21 14:05:54 -0600 146) jsonpath-rw===1.4.0 2017-02-21 14:05:54 -0600 150) traceback2===1.4.0 2017-02-21 14:05:54 -0600 163) XStatic-roboto-fontface===0.5.0.0 2017-02-21 14:05:54 -0600 208) unittest2===1.1.0 2017-02-21 14:05:54 -0600 226) XStatic-objectpath===1.2.1.0 2017-02-21 14:05:54 -0600 256) dib-utils===0.0.11 2017-02-21 14:05:54 -0600 283) XStatic-Angular-Schema-Form===0.8.13.0 2017-02-21 14:05:54 -0600 287) XStatic-bootswatch===3.3.7.0 2017-02-21 14:05:54 -0600 290) XStatic-term.js===0.0.7.0 2017-02-21 14:05:54 -0600 317) pydotplus===2.0.2 2017-02-21 14:05:54 -0600 332) murano-pkg-check===0.3.0 2017-02-21 14:05:54 -0600 347) testscenarios===0.5.0 2017-02-21 14:05:54 -0600 354) nose-exclude===0.5.0 2017-02-21 14:05:54 -0600 357) elasticsearch===2.4.1 2017-02-21 14:05:54 -0600 366) XStatic-tv4===1.2.7.0 2017-02-21 14:05:54 -0600 367) XStatic-JSEncrypt===2.3.1.1 2017-02-21 14:05:54 -0600 380) linecache2===1.0.0 2017-02-21 14:05:54 -0600 390) openstack.nose-plugin===0.11 2017-02-21 14:05:54 -0600 403) testrepository===0.0.20 2017-02-21 14:05:54 -0600 41) requests-aws===0.1.8 2017-02-21 14:05:54 -0600 420) zake===0.2.2 2017-02-21 14:05:54 -0600 448) proboscis===1.2.6.0 2017-02-21 14:05:54 -0600 465) XStatic-smart-table===1.4.13.2 2017-02-21 14:05:54 -0600 487) testresources===2.0.1 2017-02-21 14:05:54 -0600 60) pysendfile===2.0.1 2017-02-21 14:05:54 -0600 613) XStatic-D3===3.5.17.0 2017-02-21 14:05:54 -0600 70) nose===1.3.7 2017-02-21 14:05:54 -0600 88) nosexcover===1.0.11 2017-02-21 14:05:54 -0600 96) Tempita===0.5.2 2017-06-28 10:13:14 +0000 576) logutils===0.3.5 2017-09-10 10:31:03 +0000 514) repoze.lru===0.7 2017-11-22 13:05:07 +0000 184) whereto===0.4.0 2017-11-24 06:19:46 +0000 501) python-pcre===0.7 2018-01-08 14:19:08 +0000 203) oslosphinx===4.18.0 2018-01-30 00:00:05 +0000 486) requestsexceptions===1.4.0 2018-03-01 06:25:09 +0000 537) CouchDB===1.2 2018-03-01 06:25:09 +0000 540) ws4py===0.5.1 2018-03-01 06:25:09 +0000 97) ply===3.11 2018-03-28 06:24:01 +0000 349) sadisplay===0.4.9 2018-05-11 06:33:27 +0000 236) threadloop===1.0.2 2018-05-13 06:27:38 +0000 289) XStatic-JS-Yaml===3.8.1.0 2018-05-13 06:27:38 +0000 309) XStatic-Angular-UUID===0.0.4.0 2018-05-13 06:27:38 +0000 524) XStatic-Json2yaml===0.1.1.0 2018-05-13 06:27:38 +0000 579) XStatic-Angular-Vis===4.16.0.0 2018-05-13 06:27:38 +0000 64) XStatic-FileSaver===1.3.2.0 2018-06-02 06:29:39 +0000 262) lockfile===0.12.2 2018-07-09 06:36:15 +0000 408) python-consul===1.1.0 2018-07-14 06:36:14 +0000 525) boto===2.49.0 2018-09-11 06:22:11 +0000 381) oauth2client===4.1.3 2019-01-01 06:10:54 +0000 471) cotyledon===1.7.3 2019-02-14 06:49:02 +0000 299) XStatic-mdi===1.6.50.2 2019-02-14 06:51:11 +0000 113) XStatic-Jasmine===2.4.1.2 2019-04-15 06:20:25 +0000 362) pysmi===0.3.4 2019-04-23 13:47:12 +0100 572) sphinx-testing===1.0.1 2019-05-12 12:14:16 +0000 343) os-service-types===1.7.0 2019-05-14 06:11:31 +0000 275) retryz===0.1.9 2019-05-14 06:11:31 +0000 400) bitmath===1.3.3.1 2019-05-14 06:11:31 +0000 535) cachez===0.1.2 2019-05-26 06:27:47 +0000 195) URLObject===2.4.3 2019-05-26 06:27:47 +0000 215) pact===1.12.0 2019-05-26 06:27:47 +0000 30) vintage===0.4.1 2019-05-26 06:27:47 +0000 313) capacity===1.3.14 2019-05-26 06:27:47 +0000 365) infi.dtypes.iqn===0.4.0 2019-05-26 06:27:47 +0000 422) flux===1.3.5 2019-05-26 06:27:47 +0000 442) api-object-schema===2.0.0 2019-05-26 06:27:47 +0000 46) waiting===1.4.1 2019-05-26 06:27:47 +0000 481) sentinels===1.0.0 2019-05-26 06:27:47 +0000 609) confetti===2.5.3 2019-05-26 06:27:47 +0000 84) infi.dtypes.wwn===0.1.1 2019-07-13 06:50:09 +0000 53) jsonpath-rw-ext===1.2.2 2019-08-15 06:36:56 +0000 528) mitba===1.1.1 2019-09-05 07:13:47 +0000 293) gossip===2.4.0 2019-10-07 06:11:48 +0000 112) rsd-lib===1.2.0 2019-10-07 06:11:48 +0000 74) pysnmp===4.4.12 2019-10-22 21:19:25 +0000 336) sqlalchemy-migrate===0.13.0 2019-11-01 17:20:28 +0200 71) nosehtmloutput===0.0.7 2019-11-30 06:10:48 +0000 513) ndg-httpsclient===0.5.1 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 3

[openstack][cinder-backup] How check backup retain size.
by Nguyễn Hữu Khôi 07 Apr '24

07 Apr '24

Hello. I use s3 as cinder backup driver. My volume size is 2TB and It runs forever. I would like to know if we can check how many mb retain in this job. Thank you. Regards Nguyen Huu Khoi

1 0

[openstack][cinder][backup] ransomware with cinder volume
by Nguyễn Hữu Khôi 07 Apr '24

07 Apr '24

Hello, I would like to know if volumes which were attached to compute nodes and they will be impacted by ransomware. Could I have some sharing in this scenario? Currently, I just backup configure instance configure and create a new one with this configuration. Thank you. Nguyen Huu Khoi

2 2

[Diversity] PTG Schedule
by Amy Marrich 07 Apr '24

07 Apr '24

The Diversity and Inclusion working group will hold a session Tuesday, April 9th at 14:00 UTC in the Cactus room. Agenda is available[0], please add any topics. Amy 0 - https://etherpad.opendev.org/p/apr2024-ptg-diversity

1 0

Re: [all] Review dependencies without update for long time
by Sean McGinnis 07 Apr '24

07 Apr '24

> Subject: Re: [all] Review dependencies without update for long time In case it's not known, there is a script in the repo that was created to help find some of this information: https://opendev.org/openstack/requirements/src/branch/master/tools/get-heal… > > > > I recently spent some time reviewing the packages currently in the requirements repo > > and found some packages which haven't been updated for multiple years. This is a good > > indication that we have to review the features dependent on these packages to determine > > if the features should be re-implemented by a different package or dropped. Keeping such > > features with unmaintained library may likely cause problems in future maintenance > > (Python 3.12 support is a good example). > > > > > > $ git blame -e upper-constraints.txt | grep -e '201[0-9]-' | sed -e 's/.* 201/201/' | sort > > 2015-06-08 22:09:46 +1200 500) simplegeneric===0.8.1 > > 2016-05-19 06:30:24 +0000 169) extras===1.0.0 > > 2016-11-14 17:07:49 +0000 69) XStatic-Font-Awesome===4.7.0.0 > > 2016-12-18 07:20:50 +0000 583) xvfbwrapper===0.2.9 > > 2017-02-21 14:05:54 -0600 118) pyinotify===0.9.6 > > 2017-02-21 14:05:54 -0600 146) jsonpath-rw===1.4.0 > > 2017-02-21 14:05:54 -0600 150) traceback2===1.4.0 > > 2017-02-21 14:05:54 -0600 163) XStatic-roboto-fontface===0.5.0.0 > > 2017-02-21 14:05:54 -0600 208) unittest2===1.1.0 > > 2017-02-21 14:05:54 -0600 226) XStatic-objectpath===1.2.1.0 > > 2017-02-21 14:05:54 -0600 256) dib-utils===0.0.11 > > 2017-02-21 14:05:54 -0600 283) XStatic-Angular-Schema-Form===0.8.13.0 > > 2017-02-21 14:05:54 -0600 287) XStatic-bootswatch===3.3.7.0 > > 2017-02-21 14:05:54 -0600 290) XStatic-term.js===0.0.7.0 > > 2017-02-21 14:05:54 -0600 317) pydotplus===2.0.2 > > 2017-02-21 14:05:54 -0600 332) murano-pkg-check===0.3.0 > > 2017-02-21 14:05:54 -0600 347) testscenarios===0.5.0 > > 2017-02-21 14:05:54 -0600 354) nose-exclude===0.5.0 > > 2017-02-21 14:05:54 -0600 357) elasticsearch===2.4.1 > > 2017-02-21 14:05:54 -0600 366) XStatic-tv4===1.2.7.0 > > 2017-02-21 14:05:54 -0600 367) XStatic-JSEncrypt===2.3.1.1 > > 2017-02-21 14:05:54 -0600 380) linecache2===1.0.0 > > 2017-02-21 14:05:54 -0600 390) openstack.nose-plugin===0.11 > > 2017-02-21 14:05:54 -0600 403) testrepository===0.0.20 > > 2017-02-21 14:05:54 -0600 41) requests-aws===0.1.8 > > 2017-02-21 14:05:54 -0600 420) zake===0.2.2 > > 2017-02-21 14:05:54 -0600 448) proboscis===1.2.6.0 > > 2017-02-21 14:05:54 -0600 465) XStatic-smart-table===1.4.13.2 > > 2017-02-21 14:05:54 -0600 487) testresources===2.0.1 > > 2017-02-21 14:05:54 -0600 60) pysendfile===2.0.1 > > 2017-02-21 14:05:54 -0600 613) XStatic-D3===3.5.17.0 > > 2017-02-21 14:05:54 -0600 70) nose===1.3.7 > > 2017-02-21 14:05:54 -0600 88) nosexcover===1.0.11 > > 2017-02-21 14:05:54 -0600 96) Tempita===0.5.2 > > 2017-06-28 10:13:14 +0000 576) logutils===0.3.5 > > 2017-09-10 10:31:03 +0000 514) repoze.lru===0.7 > > 2017-11-22 13:05:07 +0000 184) whereto===0.4.0 > > 2017-11-24 06:19:46 +0000 501) python-pcre===0.7 > > 2018-01-08 14:19:08 +0000 203) oslosphinx===4.18.0 > > 2018-01-30 00:00:05 +0000 486) requestsexceptions===1.4.0 > > 2018-03-01 06:25:09 +0000 537) CouchDB===1.2 > > 2018-03-01 06:25:09 +0000 540) ws4py===0.5.1 > > 2018-03-01 06:25:09 +0000 97) ply===3.11 > > 2018-03-28 06:24:01 +0000 349) sadisplay===0.4.9 > > 2018-05-11 06:33:27 +0000 236) threadloop===1.0.2 > > 2018-05-13 06:27:38 +0000 289) XStatic-JS-Yaml===3.8.1.0 > > 2018-05-13 06:27:38 +0000 309) XStatic-Angular-UUID===0.0.4.0 > > 2018-05-13 06:27:38 +0000 524) XStatic-Json2yaml===0.1.1.0 > > 2018-05-13 06:27:38 +0000 579) XStatic-Angular-Vis===4.16.0.0 > > 2018-05-13 06:27:38 +0000 64) XStatic-FileSaver===1.3.2.0 > > 2018-06-02 06:29:39 +0000 262) lockfile===0.12.2 > > 2018-07-09 06:36:15 +0000 408) python-consul===1.1.0 > > 2018-07-14 06:36:14 +0000 525) boto===2.49.0 > > 2018-09-11 06:22:11 +0000 381) oauth2client===4.1.3 > > 2019-01-01 06:10:54 +0000 471) cotyledon===1.7.3 > > 2019-02-14 06:49:02 +0000 299) XStatic-mdi===1.6.50.2 > > 2019-02-14 06:51:11 +0000 113) XStatic-Jasmine===2.4.1.2 > > 2019-04-15 06:20:25 +0000 362) pysmi===0.3.4 > > 2019-04-23 13:47:12 +0100 572) sphinx-testing===1.0.1 > > 2019-05-12 12:14:16 +0000 343) os-service-types===1.7.0 > > 2019-05-14 06:11:31 +0000 275) retryz===0.1.9 > > 2019-05-14 06:11:31 +0000 400) bitmath===1.3.3.1 > > 2019-05-14 06:11:31 +0000 535) cachez===0.1.2 > > 2019-05-26 06:27:47 +0000 195) URLObject===2.4.3 > > 2019-05-26 06:27:47 +0000 215) pact===1.12.0 > > 2019-05-26 06:27:47 +0000 30) vintage===0.4.1 > > 2019-05-26 06:27:47 +0000 313) capacity===1.3.14 > > 2019-05-26 06:27:47 +0000 365) infi.dtypes.iqn===0.4.0 > > 2019-05-26 06:27:47 +0000 422) flux===1.3.5 > > 2019-05-26 06:27:47 +0000 442) api-object-schema===2.0.0 > > 2019-05-26 06:27:47 +0000 46) waiting===1.4.1 > > 2019-05-26 06:27:47 +0000 481) sentinels===1.0.0 > > 2019-05-26 06:27:47 +0000 609) confetti===2.5.3 > > 2019-05-26 06:27:47 +0000 84) infi.dtypes.wwn===0.1.1 > > 2019-07-13 06:50:09 +0000 53) jsonpath-rw-ext===1.2.2 > > 2019-08-15 06:36:56 +0000 528) mitba===1.1.1 > > 2019-09-05 07:13:47 +0000 293) gossip===2.4.0 > > 2019-10-07 06:11:48 +0000 112) rsd-lib===1.2.0 > > 2019-10-07 06:11:48 +0000 74) pysnmp===4.4.12 > > 2019-10-22 21:19:25 +0000 336) sqlalchemy-migrate===0.13.0 > > 2019-11-01 17:20:28 +0200 71) nosehtmloutput===0.0.7 > > 2019-11-30 06:10:48 +0000 513) ndg-httpsclient===0.5.1

1 0

[ptg][openstack-ansible] OpenStack-Ansible vPTG time and date
by Dmitriy Rabotyagov 06 Apr '24

06 Apr '24

Hi folks, Sorry for the late scheduling of vPTG this time. I've booked an Icehouse room for Tuesday, April 9 from 16:00 (4PM) till 18:00 (6PM) UTC. You can find the meeting link below [1]. An etherpad with some agenda is here: [2] [1] https://meetpad.opendev.org/apr2024-ptg-os-ansible [2] https://etherpad.opendev.org/p/osa-dalmatian-ptg

1 0

[opnestack][kolla-ansible]Mix compute inventory
by Nguyễn Hữu Khôi 06 Apr '24

06 Apr '24

Hello. I am reading about Kolla Ansible Inventory https://docs.openstack.org/kolla-ansible/latest/user/multinode.html In my environment, Controllers and Compute01>>>03 have same network interfaces But from compute04>>06 have different interface neutron_external_interface=*eth0.1 *api_interface=*eth0.2 *tunnel_interface= *eth0.3* Which is the best group for my case? [compute-custom] compute04 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* compute05 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* compute06 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* Then put them to same block services which have Nova? I see the we prefer to use host_vars or*group_vars. *Do we have some examples about it? Thank you. Nguyen Huu Khoi

1 0

[Nova][Kolla][VDI] Introducing Kerbside delivery of VDI console sessions
by Michael Still 06 Apr '24

06 Apr '24

Hi all, for the longest time I've thought it was super cool that you could do something like this with Google Cloud: `gcloud compute ssh ...instance...` This causes a SSH session to run in your terminal that transparently proxies you through to the instance. It even orchestrates SSH authentication using a CA, but that's a story for another day. Aptira had a similar business need, but with more of a focus on virtual desktop environments, and therefore kindly supported my development work on a SPICE protocol native proxy I've called Kerbside [1][2]. The proxy works by scraping various clouds' REST APIs for "VDI capable" instances, and then making those available via short lived session tokens. The intention is that a service like Horizon or Skyline could request a session token for a specific instance, which is returned to the user as a `.vv` style virt-viewer configuration file. The user then opens the configuration file and a connection to the console on the relevant hypervisor is provided by Kerbside. Kerbside can do more than that of course. It has a simple management UI and API, which allows for things like forced termination of a console session once setup, logging and audit history, TLS support, and so forth. Kerbside and all associated work is licensed under the Apache 2 license, just the same as OpenStack, and positions clouds to offer Citrix-like virtual desktops to their users in a seamless manner. Why a SPICE proxy? As best as I can tell, SPICE still provides the richest virtual desktop experience. It supports high resolution desktops, multi-screen desktops, USB device passthrough, sound, multiple user connections to a single console, and so forth. Why not the current HTML5 transcoding proxy as used by Horizon? Unfortunately, the current HTML5 SPICE client does not support most of the features listed in the previous paragraph. While originally intended for the purposes of my personal Shaken Fist project, Kerbside now supports OpenStack and oVirt as well. In the case of OpenStack, this required a number of patches to OpenStack projects to get working [3]. Specifically I'd like to propose a new Nova API microversion to support a new "spice-direct" console type. I intend to work through the Nova specs process for the Nova related changes, and have created a blueprint [4] to track that work. I am working on a draft spec at the moment [5], but do not see the required changes to Nova as particularly invasive. You can of course assess that yourself by reading the proof of concept patches in the kerbside-patches repository. This raises some questions for me. Specifically: - is this functionality interesting to others? Or is it just me? - what is the process of proposing changes like this for Kolla and Kolla-Ansible? I chose to build my proof of concept on that platform, so I also have a number of aligned deployment patches there. - I've been out of the OpenStack universe for a while now. Is it too late to propose this work for Dalmation? Thanks, Michael 1: https://github.com/shakenfist/kerbside and https://github.com/shakenfist/kerbside-client 2: Why Kerbside? Well because Horizon and Skyline are distant things, whereas I wanted to create something closer... Like Kerbside pickup from a shop. 3: https://github.com/shakenfist/kerbside-patches 4: https://blueprints.launchpad.net/nova/+spec/libvirt-spice-direct-consoles 5: https://github.com/shakenfist/kerbside-patches/blob/develop/nova-specs/patc…

3 3

[blazar][ptg] Dalmatian PTG schedule
by Pierre Riteau 05 Apr '24

05 Apr '24

Hello, I have booked a PTG slot on Thursday, April 11 from 1500 to 1700 UTC for the Blazar project. The meeting will be held in the Bexar room. The initial agenda can be found here: https://etherpad.opendev.org/p/apr2024-ptg-blazar Please add any topics you would like to discuss. Anyone interested in Blazar is welcome to join. Cheers, Pierre Riteau (priteau)

1 0

[ptg][tacker]Dalmatian vPTG Planning
by Yasufumi Ogawa 05 Apr '24

05 Apr '24

Hi all, I've booked the slots[1] from Apr 9th to 11th, 6-8 UTC all the days, and setup the etherpad[2] for Tacker team. Please feel free to add your topics. [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/apr2024-ptg-tacker Thanks, Yasufumi

1 0

[swift][ptg] Ops Feedback Session - 10th April at 1300 UTC
by Matthew Oliver 05 Apr '24

05 Apr '24

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in the dalmation swift meetpad room ( https://meetpad.opendev.org/swift-ptg-dalmatian) on Wednesday at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, we'd appreciate it if you can offer some feedback on the etherpad ( https://etherpad.opendev.org/p/swift-dalmation-ops-feedback) This has always been a highlight at every PTG for us swift devs. Have your say and help make Swift even better! Matt

1 0

[kolla] [mariadb] Backups failing if they take over an hour
by Chris DiLorenzo 05 Apr '24

05 Apr '24

Were using the mariadb_backup command of kolla-ansible to backup the database. We're doing daily, full backups. It's been working fine until recently. Now we are getting this error: 2024-04-03 21:16:33 0 [Note] InnoDB: Read redo log up to LSN=317647271424 2024-04-03 21:16:48 0 [Note] InnoDB: Read redo log up to LSN=317647424512 2024-04-03 21:17:03 0 [Note] InnoDB: Read redo log up to LSN=317647586304 2024-04-03 21:17:18 0 [Note] InnoDB: Read redo log up to LSN=317647733248 [01] 2024-04-03 21:17:23 ...done [00] FATAL ERROR: 2024-04-03 21:17:23 failed to execute query SET SESSION lock_wait_timeout=31536000: Server has gone away It started as soon as the DB backup took more than 1 hour. In our other environments where the backup is < 1hr, it works fine. There are no errors in the logs when this happens, other then the above output from mariabackup Any suggestions? Thanks, Chris

2 1

[neutron] Dalmatian vPTG reminder
by Brian Haley 05 Apr '24

05 Apr '24

Hello Neutrinos, This year our vPTG slots are: Tuesday, April 9th, 13:00 - 17:00 UTC Wednesday, April 10th, 13:00 - 17:00 UTC Thursday, April 11th, 13:00 - 17:00 UTC (if necessary) See https://ptg.opendev.org/ptg.html for room info and other teams' sessions. Etherpad is at https://etherpad.opendev.org/p/apr2024-ptg-neutron - please add anything you would like to discuss by tomorrow so I can create a schedule. See you on Tuesday! -Brian

1 0

[manila] Dalmatian vPTG Schedule
by Carlos Silva 05 Apr '24

05 Apr '24

Hello, Zorillas and interested stackers, I would like to share with you our agenda for next week's PTG [1]. In case you would like a topic to be moved around, please let me know and I'll be happy to accommodate changes. [1] https://etherpad.opendev.org/p/dalmatian-ptg-manila Looking forward to having many productive discussions with you! Regards, carloss

1 0

help
by Carita Ndibe 05 Apr '24

05 Apr '24

I am trying to customize my dashboard but keep getting this error: uncompressableFileError at auth/login static/dashboard/scss/custom.scss' could not be found in the COMPRESS_ROOT '/opt/stack/horizon/static' or with staticfiles I previously had an offline compression error by i resolved be settion COMPRESSION_ENABLED to False. how can I resolve this?

1 0

[release]OpenStack Caracal 2024.1 Highlights on OpenInfra Live
by Allison Price 04 Apr '24

04 Apr '24

Hi everyone, Happy OpenStack Caracal 2024.1 release day! Tomorrow, at 1400 UTC, there will be an OpenInfra Live episode [1] to cover some of the project highlights from this project cycle and what can be expected for OpenStack Dalmatian 2024.2. Here is a lineup of the OpenStack community leaders and the updates they will be covering: Sylvain Bauza (Nova), Ghanshyam Mann (Technical Committee), Riccardo Pittau (Ironic), Rajat Dhasmana (Cinder), Carlos Silva (Manila) Join us as we celebrate OpenStack’s 29th release! Cheers, Allison [1] https://www.youtube.com/watch?v=3BgAXbFaVqw

1 1

[openstack-ansible] : Ussuri minor version update.
by keshav bareja 04 Apr '24

04 Apr '24

Hi Team I am planning to update my environment from the current ussuri minor version to the latest minor version available for the Ussuri. I found the procedure below. https://docs.openstack.org/openstack-ansible/ussuri/admin/upgrades/minor-up… I have some queries on this: 1. How to find the current minor release version of the Ussuri deployed on my environment? Is there any command or way that can help? 2. What is the latest minor version available for Ussuri? In the Ussuri release notes page I could see 2.10, can someone please confirm if 2.10 is the latest version? 3. Also I need to know the bug fixes between my current release to the latest minor ussuri release. 4. Can someone confirm what all pre-requisite I need to take care of before going with the update. 5. Anyone having experience with such minor updates , Please share precaution and recommendations, Ussuri Series Release Notes <https://docs.openstack.org/releasenotes/openstack-ansible/victoria.html> <https://docs.openstack.org/releasenotes/openstack-ansible/train.html> <https://bugs.launchpad.net/openstack-ansible/+filebug?field.title=Ussuri%20…> 21.2.10 <https://docs.openstack.org/releasenotes/openstack-ansible/ussuri.html#relno…>Security Issues <https://docs.openstack.org/releasenotes/openstack-ansible/ussuri.html#secur…> - This release eliminates following security issues: - OSSA-2021-005: https://security.openstack.org/ossa/OSSA-2021-005.html - OSSA-2021-006: https://security.openstack.org/ossa/OSSA-2021-006.html

2 5

Panko Service get_events function returning none
by Sandesh Kulkarni 04 Apr '24

04 Apr '24

Hi Openstack Team, I am using Panko for events retrieval, but I am getting None from the below query. My current SqlAlchemy version is 1.4.31. Could you please guide me in retrieving the correct events from the database? Output from the panko events api :- { "message_id": "2b4d83b4-3e23-4326-bedb-557a405c16db", "event_type": "audit.http.response", "traits": [ { "name": "action", "value": "None", "type": "string" }, { "name": "eventTime", "value": "2024-03-27T03:59:52.192750", "type": "datetime" }, { "name": "eventType", "value": "None", "type": "string" }, { "name": "id", "value": "None", "type": "string" }, { "name": "initiator_host_address", "value": "None", "type": "string" }, { "name": "initiator_id", "value": "None", "type": "string" }, { "name": "initiator_name", "value": "None", "type": "string" }, { "name": "initiator_typeURI", "value": "None", "type": "string" }, { "name": "observer_id", "value": "None", "type": "string" }, { "name": "outcome", "value": "None", "type": "string" }, { "name": "project_id", "value": "None", "type": "string" }, { "name": "reason_code", "value": "None", "type": "string" }, { "name": "requestPath", "value": "None", "type": "string" }, { "name": "request_id", "value": "None", "type": "string" }, { "name": "service", "value": "None", "type": "string" }, { "name": "target_id", "value": "None", "type": "string" }, { "name": "target_name", "value": "None", "type": "string" }, { "name": "target_typeURI", "value": "None", "type": "string" }, { "name": "typeURI", "value": "None", "type": "string" }, { "name": "user_id", "value": "None", "type": "string" } ], "generated": "2024-03-27T03:59:52.693294", "raw": {} } Query Link :- https://github.com/openstack/panko/blob/4d0c0d66da6833e5283d71fe5bdee9594e4… Thanks and Regards, Sandesh Kulkarni

1 0

[all][elections][tc] 2024.2 Dalmatian Technical Committee Election Results
by Ian Y. Choi 04 Apr '24

04 Apr '24

Please join me in congratulating the 5 newly elected members of the Technical Committe (TC). Amy Marrich (spotz) Goutham Pacha Ravi (gouthamr) Dmitriy Rabotyagov (noonedeadpunk) Artem Goncharov (gtema) (replacing Sylvain Bauza - bauzas as per the TC resolution) [1] Slawek Kaplonski (slaweq) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_f8044ce7af316bf3 Election process details and results are also available here: https://governance.openstack.org/election/ Note that we encountered a situation where not all members as elected could be seated which requires TC resolution. More details on the resolution are explained in [1], and thank you all for the understanding and support in resolving this matter. Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. [1] https://governance.openstack.org/tc/resolutions/20240322-adjudication-of-20…

1 0

OpenStack 2024.1 Caracal is officially released!
by Herve Beraud 04 Apr '24

04 Apr '24

Hello OpenStack community, The official OpenStack 2024.1 Caracal release announcement has been sent out: https://lists.openstack.org/archives/list/openstack-announce@lists.openstac… Thanks to all who were a part of the 2024.1 Caracal development cycle! This marks the official opening of the openstack/releases repository for 2024.2 Dalmatian releases, and freezes are now lifted. stable/2024.1 is now a fully normal stable branch, and the normal stable policy applies from now on. Thanks, -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

3 2

User survey 2023 - TC questions
by Sławek Kapłoński 04 Apr '24

04 Apr '24

Hi, I am doing analysis of the TC questions in the 2023 user survey [1] and I need some additonal information. In the results of the survey which I some time ago got from Allison there are only short "names" of the questions, like e.g. "TCContributions" but no full question which was asked. This is ok for me for the questions which were in the survey in previous years but this year TC added couple of new questions for which I don't have full questions at all. Short names of those questions are: - TCConsumingOpenStack - TCConsumingOpenStackOther - TCInteractOpenStack - TCInteractOpenStack - TCInteractOpenStackSkyline - TCInteractOpenStackSkylineList - TCInteractSkylineOther - TCInteractOpenStackInternal - TCInteractOpenStackInternalOther - TCCloudServices Can You maybe share with me what were those full questions in the survey? Or point me to the place where I can maybe find it? Thx in advanve for help with this. [1] https://review.opendev.org/c/openstack/governance/+/900516 -- Slawek Kaplonski Principal Software Engineer Red Hat

2 2

[all][tc] Next week TC meeting is canceled
by Ghanshyam Mann 03 Apr '24

03 Apr '24

Hello Everyone, As next week is vPTG happening, we are canceling next week's (April 9th) TC meeting. -gmann

1 0

[freezer] Project status update
by Dmitriy Rabotyagov 03 Apr '24

03 Apr '24

Hey there! In a previous email thread [1] an interest toward reviving the Freezer project was raised. As a result of the thread we've organized a first sync meeting with interested parties. It was a quite productive discussion and we came up with a couple of action points as a result of it. You can find more information in the etherpad [2] Among everything, one of the most important parts for now, is to step into the PTL role or move a project to a distributed leadership. At the moment the project is leadless, since there was no candidacy submitted for this election. We also agreed to schedule the next meeting on April 2 from 16-00 till 17-00 UTC and discuss progress and blockers which were found. I'm attaching an invitation to the meeting to the email. If it doesn't work, you can join on the mentioned time via the link [3] Hope to see you there and thanks for everyone who participated and stepped in for the project! [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://etherpad.opendev.org/p/freezer-status [3] https://meet.google.com/ckc-gevi-epe

1 2

[cinder] Canceling this week's meeting (3rd April)
by Rajat Dhasmana 02 Apr '24

02 Apr '24

Hello Argonauts, Given that tomorrow is the 2024.1 Caracal release and PTG coming up next week, we decided in last week's meeting to cancel the cinder meeting, which was going to be held on 3rd April, 2024. See you all next week at the PTG! Thanks Rajat Dhasmana

1 0

[neutron] Proposing Ihar Hrachyshka as neutron core reviewer
by Brian Haley 02 Apr '24

02 Apr '24

Hello Neutrinos, I would like to nominate Ihar Hrachyshka for Neutron core reviewer (again). He's been leaving some very useful comments lately, moved-up in the reviewer stats over the past 90 days [0], and has a lot of OVN knowledge. Ihar was previously a core reviewer from 2015-2018 so most might already know him. I think he'd be a great re-addition to the team. Please vote with a +1/-1. [0] https://www.stackalytics.io/report/contribution?module=neutron-group&projec… Thanks, -Brian, Neutron PTL

8 8

Re: [neutron][magnum][mcapi] floating IP delete permission issue
by Satish Patel 02 Apr '24

02 Apr '24

Thank you Mohammed, It would be really good if we have a flag in template to say release floating IP instead of delete. Technically operator assign floating IPs to project and only that project should use them as per need instead of delete floating ips and put it back to book. Let’s see if we can get some eyeballs on this feature. But this is very important feature for us to control public IP usage. On Mon, Apr 1, 2024 at 10:16 PM Mohammed Naser <mnaser(a)vexxhost.com> wrote: > Hi Satish, > > This is actually something that would have to be handled on the Cluster > API level, since it is the one that owns that resource. > > I would start raising an issue there first, if that gets traction then we > can integrate that with the driver after, however, if it doesn't make sense > for it to be there, we can maybe include a config flag to handle this (but > I'm not sure what other implications this would have) > > Thanks > Mohammed > ------------------------------ > *From:* Satish Patel <satish.txt(a)gmail.com> > *Sent:* April 1, 2024 10:09 PM > *To:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > *Subject:* [neutron][magnum][mcapi] floating IP delete permission issue > > Folks, > > For regulatory purposes we set a neutron policy to not let normal users > delete their public floating IPs because they are assigned to specific > customers and we don't want them to delete them. So far that policy works. > > But now when it comes to magnum / mcapi. I am able to create a cluster but > not able to delete because when magnum is going to delete floating IP I am > getting an error saying you are not allowed to delete floating IP and k8s > are stuck in deleting state. > > Is there any way magnum can do floating IP release instead of delete? > > Following error I am seeing in CAPI logs. > > I0402 01:50:03.412447 1 recorder.go:104] "events: Failed to delete > floating IP 101.xx.xx.70: Request forbidden: [DELETE > https://os2.example.com:9696/v2.0/floatingips/492b2c4c-151b-437e-acfc-4778a…] > error message: {\"NeutronError\": {\"type\": \"PolicyNotAuthorized\", > \"message\": \"rule:delete_floatingip is disallowed by policy\", > \"detail\": \"\"}}" type="Warning" > object={"kind":"OpenStackMachine","namespace":"magnum-system","name":"kube-6aqje-csgft-nkz6s","uid":"97acabe1-e547-4bbc-8406-aebc563212cd","apiVersion":" > infrastructure.cluster.x-k8s.io/v1alpha7","resourceVersion":"31170690"} > reason="Faileddeletefloatingip" >

1 0

how to use policy.json in kolla
by mohammad kokabi 02 Apr '24

02 Apr '24

Hello, I'm using OpenStack Kolla Ansible, and I want to define a specific level of access for each user, but I couldn't find any documentation on this matter. For example, I have two users named David and Adrian, and I want the user David to have the ability to delete an instance, while the user Adrian should not have this access. Both users are members of a shared project. The only documentation I found is a sample policy.yaml file, which states that it should be placed in the /etc/nova directory. Could you please clarify where this file should be located for OpenStack Kolla Ansible? https://docs.openstack.org/nova/latest/configuration/sample-policy.html

1 0

[neutron] Bug Deputy Report March 25 - March 31
by Yatin Karel 02 Apr '24

02 Apr '24

Hi Neutrinos, Below is the bug deputy report for last week:- High ------ - https://bugs.launchpad.net/neutron/+bug/2058908 fix auto_scheduler_network understanding dhcp_agents_per_network Assigned to Sahid Orentino Medium ---------- - https://bugs.launchpad.net/neutron/+bug/2058712 [openvswitch-agent] Trunk extension should not be loaded if service plugin is disabled Assigned to Julien Cosmao Low ----- - https://bugs.launchpad.net/neutron/+bug/2059236 Add a RBAC action field in the query hooks Assigned to Rodolfo Alonso Undecided -------------- - https://bugs.launchpad.net/neutron/+bug/2059716 [ovn] Multihomed backend (IPv4 + IPv6) with floating IP unreachable, requested more information. -- Thanks and Regards Yatin Karel

1 0

[sunbeam][PTG] Sunbeam Dalmatian 2024.2 PTG schedule
by Hemanth N 02 Apr '24

02 Apr '24

Hi All, OpenStack PTG has been scheduled for next week Apr 8th to Apr 12th 2024 [1] and I have scheduled the following time slots for the OpenStack Sunbeam project. Wednesday 10 April 2024 0500 UTC to 0700 UTC Thursday 11 April 2024 1400 UTC to 1600 UTC The meeting links and details are in ptg link [2] or etherpad [3]. Feel free to add the topics of interest to discuss in the etherpad [3]. [1] https://openinfra.dev/ptg/ [2] https://ptg.opendev.org/ptg.html [3] https://etherpad.opendev.org/p/apr2024-ptg-sunbeam Looking forward to seeing you next week! Best Regards, Hemanth Nakkina

1 0

[publiccloud-sig] Reminder - next meeting April 4th - 0700 UTC
by Felix Kronlage-Dammers 02 Apr '24

02 Apr '24

Hi everyone, This Wednesday (April 4th) the next meeting of the public cloud sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG This week we’ll likely prepare the vPTG Sessions for next week. This will include our own sessions that happen on Tuesday (April 9th) at 07:00 UTC and Thursday (April 11th) at 14:00 UTC. regards felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 1

[qa][ptg] Virtual Dalmatian vPTG Planning
by Martin Kopec 02 Apr '24

02 Apr '24

Hello everyone, here is [1] our etherpad for the Dalmatian/2024.2 virtual PTG. Please, add your topics there if there is anything you would like to discuss / propose ... You can also vote for time slots for our sessions so that they fit your schedule at [2]. We will most likely go with 1-hour slot per day, as they usually fit easier into everyone's schedule. The number of slots will depend on the number of topics proposed in [1]. [1] https://etherpad.opendev.org/p/apr2024-ptg-qa [2] https://framadate.org/pklG59pH47w6ZdJI Thanks, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 1

[all][tc] Technical Committee next weekly meeting on April 2nd 2024 at 1800 UTC
by Ghanshyam Mann 02 Apr '24

02 Apr '24

Hello Everyone, Below is the agenda for the next TC meeting scheduled on April 2nd 2024 at 1800 UTC Location: Zoom Video Meeting: https://us06web.zoom.us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09 * Roll call * Follow up on past action items * Gate health check * Implementation of Unmaintained branch statuses * TC vPTG 2024.2 ** https://etherpad.opendev.org/p/apr2024-ptg-os-tc * TC Chair Election ** Incoming TC needs to select a new chair and vice chair: https://governance.openstack.org/tc/reference/charter.html#tc-chair *Open Discussion and Reviews -gmann

1 0

[neutron][magnum][mcapi] floating IP delete permission issue
by Satish Patel 02 Apr '24

02 Apr '24

Folks, For regulatory purposes we set a neutron policy to not let normal users delete their public floating IPs because they are assigned to specific customers and we don't want them to delete them. So far that policy works. But now when it comes to magnum / mcapi. I am able to create a cluster but not able to delete because when magnum is going to delete floating IP I am getting an error saying you are not allowed to delete floating IP and k8s are stuck in deleting state. Is there any way magnum can do floating IP release instead of delete? Following error I am seeing in CAPI logs. I0402 01:50:03.412447 1 recorder.go:104] "events: Failed to delete floating IP 101.xx.xx.70: Request forbidden: [DELETE https://os2.example.com:9696/v2.0/floatingips/492b2c4c-151b-437e-acfc-4778a…] error message: {\"NeutronError\": {\"type\": \"PolicyNotAuthorized\", \"message\": \"rule:delete_floatingip is disallowed by policy\", \"detail\": \"\"}}" type="Warning" object={"kind":"OpenStackMachine","namespace":"magnum-system","name":"kube-6aqje-csgft-nkz6s","uid":"97acabe1-e547-4bbc-8406-aebc563212cd","apiVersion":" infrastructure.cluster.x-k8s.io/v1alpha7","resourceVersion":"31170690"} reason="Faileddeletefloatingip"

1 0

[manila] PTG topics reminder
by Carlos Silva 02 Apr '24

02 Apr '24

Hello, Zorillas! Sending this kind last reminder to please add your topics to the PTG topics etherpad [1] by tomorrow (Apr 2nd). I will be working on the slots on Wednesday and intend to share the agenda with you in this Thursday's weekly meeting. [1] https://etherpad.opendev.org/p/dalmatian-ptg-manila-planning Thank you! Regards, carloss

1 0

One Week Out! PTG April 2024 Registration & Schedule
by Kendall Nelson 02 Apr '24

02 Apr '24

Hello Everyone! The April 2024 Project Teams Gathering is right around the corner and the schedule has been largely set up! Slots are going fast, so make sure to get your time booked ASAP! You can find the schedule and available slots on the PTGbot website [1]. *REMINDER: The default meeting rooms are no longer Zoom rooms, they are meetpad rooms. When the PTGbot was setup initially, the meetpad rooms had been configured to match the etherpads auto generated by the bot. If your team has updated the etherpad and also wants to maintain the meetpad integration, your meetpad room URL will need to be updated as well. One thing to keep in mind about this integration - meetpad is not case sensitive, but etherpad is so to keep the integration your etherpad URL should be all lowercase. Your team does not HAVE to use meetpad (or make use of the integration with etherpad) however; just as before, the URL can be updated by your team moderator to use a different meeting tool.* The PTGbot site is regularly updated both before *and* during the PTG. Be sure to bookmark the page so you can keep track of what's being discussed and any last-minute schedule changes. It is driven via commands in the #openinfra-events IRC channel (on the OFTC network) where the PTGbot listens. If you have questions about the commands that you can give the bot, check out the documentation here[2]. Also, if you haven’t connected to IRC before, here are some docs on how to get setup![3] Lastly, please don't forget to register[4] - It’s FREE. Please let us know if you have any questions via email to ptg(a)openinfra.dev. Thanks! -Kendall (diablo_rojo) [1] PTGbot Site: https://ptg.opendev.org/ptg.html [2] PTGbot Documentation: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst [3] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [4] PTG Registration: https://ptg2024.openinfra.dev/

1 0

openstacksdk, ironicclient, os-fault: Please replace python3-appdirs dependency with platformdirs
by Thomas Goirand 01 Apr '24

01 Apr '24

Hi, 3 bugs have been opened in Debian to get appdirs replaced by platformdirs: https://bugs.debian.org/1067995 https://bugs.debian.org/1067999 https://bugs.debian.org/1068000 Here's the bug report content: > python3-appdirs is dead upstream[1] and its Debian maintainer has > indicated that it should not be included in trixie[2]. A recommended > replacement is python3-platformdirs[3], which is a fork of appdirs > with a very similar API. > > Please migrate from appdirs to platformdirs or some other replacement, > so that appdirs can be removed. > > Thanks, > smcv > > [1] https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e9… > [2] https://bugs.debian.org/1060427 >[3] https://pypi.org/project/platformdirs/ Can we do that in upstream OpenStack, during the Dalmatian cycle? Cheers, Thomas Goirand (zigo)

3 3

[Glance][PTG] Glance Dalmatian 2024.2 PTG Schedule
by Pranali Deore 01 Apr '24

01 Apr '24

Hello All, Dalmatian (2024.2) virtual PTG is going to start next week and we have created our PTG etherpad [1] and also added day wise topics along with timings we are going to discuss. Kindly let me know if you have any concerns with allotted time slots. Friday is reserved for any unplanned discussions. So please feel free to add your topics if you haven't added yet. As a reminder, these are the time slots for our discussion. Tuesday 9 APRIL 2024 1400 UTC to 1700 UTC Wednesday 10 APRIL 2024 1400 UTC to 1700 UTC Thursday 11 APRIL 2024 1400 UTC to 1700 UTC Friday 12 APRIL 2024 1400 UTC to 1700 UTC NOTE: At the moment we don't have any sessions scheduled on Friday, if there are any last moment request(s)/topic(s) we will discuss that on Friday else we will conclude our PTG on Thursday 11th APRIL. The meeting URL is mentioned in etherpad [1] and will be the same throughout the PTG. [1]: https://etherpad.opendev.org/p/apr2024-ptg-glance#L1 Hope to see you there!! Thanks & Regards, Pranali Deore

1 0