- openstack-discuss - lists.openstack.org

[kolla-ansible] Deploying an kolla-ansible all-in-one to test enforce_scope
by Kyle Burall 27 Sep '23

27 Sep '23

I'm trying to test enabling enforce_scope on a kolla-ansible deployment in prep for rolling it out to an actual deployment and I am having issues with services registering themselves. The playbook fails at registering nova services and the keytsone log says the nova user doesn't exist, as well as the service project and the admin role. I've added enforce_scope and enforce_new_defaults to global.conf, which causes the referenced error. I assume that I'm missing something in the configuration that is required beyond just setting those two oslo_policy options, but I haven't been able to find anything beyond these two settings. Can anyone let me know if there's something specific that I'm missing? Thanks! This email and its attachments, if any, may contain information that is proprietary, business-confidential, and/or legally protected. If you received this communication in error, please notify me by reply message and delete the email and any attachments without copying, distributing, or otherwise using.

1 0

[openstack][nova][cinder] how can we know instance disk usage
by Nguyễn Hữu Khôi 27 Sep '23

27 Sep '23

Hello guys. I am try to get instance disk usage but I cannot. I try to use virsh domblkinfo instance-00000df8 vda but it did not show exactly disk allocation How we get this metric.I used SAN and Ceph as backend storages. Thank you so much, . Nguyen Huu Khoi

1 0

[magnum] Weekly meeting today (27th Sep 2023) cancelled
by Michał Nasiadka 27 Sep '23

27 Sep '23

Hello, Since key members are absent - let’s cancel this weeks (27th Sep 2023) meeting. Best regards, Michal

1 0

RE: openstack- Deployment through kolla ansible
by Asma Naz Shariq 26 Sep '23

26 Sep '23

Hi all, I have deployed openstack through kolla ansible deployment tool and i want to know that how to add firewall as a service in openstack release 2023.1 (antelope) and how to add bgp router plugins in openstack release 2023.1? please anyone guide. -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Tuesday, September 26, 2023 9:08 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 59, Issue 97 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [openstack][neutron] OpenStack deployment (Satish Patel) 2. [tc][all] Please welcome Jay Faulkner as new Chair of Technical Committee (Nikolla, Kristi) 3. Re: [tc][all] Please welcome Jay Faulkner as new Chair of Technical Committee (Rodolfo Alonso Hernandez) 4. Re: [release][requirements][TC][oslo] how to manage divergence between runtime and doc? (Ghanshyam Mann) ---------------------------------------------------------------------- Message: 1 Date: Tue, 26 Sep 2023 08:06:47 -0400 From: Satish Patel <satish.txt(a)gmail.com> To: Dhanasekar Kandasamy <dhana.sys(a)gmail.com> Cc: openstack-discuss(a)lists.openstack.org, skaplons(a)redhat.com Subject: Re: [openstack][neutron] OpenStack deployment Message-ID: <0695D533-7F6D-4B95-8148-E5A2336C8649(a)gmail.com> Content-Type: text/plain; charset="utf-8" Hi, I would never deploy dedicated network node until I?m going to pumps gigs and gigs of traffic in/out. Anyway in DVR ( you can run network node function on each compute nodes) I would go with OVN deployment and skip network nodes. Just controller and compute. If I?m future you can easily add dedicated network node and distribute traffic. If you go with VLAN based provider then you really don?t need network node. Sent from my iPhone > On Sep 25, 2023, at 9:43 AM, Dhanasekar Kandasamy <dhana.sys(a)gmail.com> wrote: > > ? > Hi, > > I planning to deploy OpenStack for production zed release, OVS with > DVR when I went through the reference architectures I can see > 3 controller, 3 network and x compute nodes or > 3 controllers + network and x computes nodes I want to understand what > happens if I go with the below configuration OVS with DVR > 3 controller node > x compute + network nodes > For example I have 13 nodes, 3 controllers, 10 compute + network nodes > what is the advantage/disadvantage for this configuration > > Thanks & Regards, > Dhana

1 0

[tc] Technical Committee next weekly meeting Today on September 26, 2023
by Nikolla, Kristi 26 Sep '23

26 Sep '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held Today on Tuesday, 26 September 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 • No action items from Sept 19, 2023 meeting. • Gate health check • Leaderless projects • Call for volunteers for Vice-Chair • Open Discussion and Reviews • Register for the PTG • #link https://openinfra.dev/ptg/ • #link https://review.opendev.org/q/projects:openstack/governance+is:open Thank you, Kristi Nikolla

1 0

[release][requirements][TC][oslo] how to manage divergence between runtime and doc?
by Herve Beraud 26 Sep '23

26 Sep '23

We currently face a big issue. An issue which could have huge impacts on the whole Openstack and on our customers. By customers I mean all the users outside the upstream community, operators, distros maintainers, IT vendors, etc. Our problem is that, for a given series, Bobcat in our case, there is divergence between the versions that we announce as supported to our customers, and the versions really supported in our runtime. Let me describe the problem. The oslo.db's versions supported within Bobcat's runtime [1] doesn't reflect the reality of the versions really generated during Bobcat [2]. In Bobcat's upper-constraints, oslo.db 12.3.2 [1] is the supported version. This version corresponds in reality to the last version generated during 2023.1/antelope [3]. All the versions of oslo.db generated during Bobcat are for now ignored by our runtime. However all these generated versions are all listed in our technical documentation as supported by Bobcat. In fact, the problem is that these oslo.db versions are all stuck in their upper-constraints upgrade, because some cross-jobs failed and so the upper-constraints update can't be made. These cross-job are owned by different services (heat, manila, masakari, etc). We update our technical documentation each time we produce a new version of a deliverable, so before upgrading the upper-constraints. This is why the listed versions diverge from the versions really supported at runtime. We also face a similar issue with Castellan, but in the sake of clarity of description of this problem I'll focus on oslo.db's case during the rest of this thread. >From a quantitative point of view, we face this kind of problem, from a consecutive manner, since 2 series. It seems now that this becomes our daily life with each new series of openstack. . At this rate it is very likely that we will still be faced with this same problem during the next series. Indeed, during antelope, the same issue was thrown but only within one deliverable [4][5][6]. With Bobcat this scenario reappears again but now within two deliverables. The more the changes made in libraries are important, the more we will face this kind of issues again, and as everybody knows our libraries are all based on external libraries who could evolve toward new major releases with breaking changes. That was the case oslo.db where our goal was to migrate toward sqlalchemy 2.x. Leading to stuck upper-constraints. This problem could also impact all the downstream distros. Some distros already started facing issues [7] with oslo.db's case. We can't exclude that a similar issue will start to appear soon within all the Openstack deliverables listed in upper-constraints. Oslo's case is the first fruit. >From a quality point of view, we also face a real issue. As customers can establish their choices and their decisions on our technical documentation, a divergence between officially supported versions and runtime supported versions can have huge impacts for them. Imagine they decide to install a specific series led by imposed requirements requested by a government, that can be really problematic. By reading our technical documentation and our release notes, they can think that we fulfill those prerequisites. This kind of government requirement often arrives. It can be requested for a vendor who wants to be allowed to sell to a government, or to be allowed to respect some specific IT laws in a given country. This last point can completely undermine the quality of the work carried out upstream within the Openstack community. So, now, we have to find the root causes of this problem. In the current case, we would think that the root cause lives in the complexity of oslo.db migration, yet this is not the case. Even if this migration represents a major change in Openstack, it has been announced two year ago [8] - the equivalent of 4 series -, leaving a lot of time for every team to adopt the latest versions of oslo.db and sqlalchemy 2.x. Stephen Finucane and Mike Bayer have spent a lot of time on this topic. Stephen even contributed well beyond the oslo world, by proposing several patches to migrate services [9]. Unfortunately a lot of these patches remain yet unmerged and unreviewed [10], which has led us to this situation. This migration is therefore by no means the root cause of this problem. The root cause of this problem lurks in the volume of maintenance of services. Indeed the main cause of this issue is that some services are not able to follow the cadence, and therefore they slow down libraries' evolutions and maintenance. Hence, their requirements cross job reflect this fact [11]. This lack of activity is often due to the lack of maintainers. Fortunately Bobcat has been rescued by Stephen's recent fixes [12][13]. Stephen's elegant solution allowed us to solve failing cross jobs [14] and hence, allowed us to resync our technical documentation and our runtime. However, we can't ignore that the lack of maintainers is a growing trend within Openstack. As evidenced by the constant decrease in the number of contributors from series to series [15][16][17][18]. This phenomenon therefore risks becoming more and more amplified. So, we must provide a lasting response. A response more based on team process than on isolated human resources. A first solution could be to modify our workflow a little. We could update our technical documentation by triggering a job with the upper-constraints update rather than with a new release patch. Hence, the documentation and the runtime will be well aligned. However, we should notice that not all deliverables are listed in upper-constraints, hence this is a partial solution that won't work for our services. A second solution would be to monitor teams activity by monitoring the upper-constraints updates with failing cross-job. That would be a new task for the requirements team. The goal of this monitoring would be to inform the TC that some deliverables are not active enough. This monitoring would be to analyze, at defined milestones, which upper-constraints update remains blocked for a while, and then look at the cross-job failing to see if it is due to a lack of activity from the service side. For example by analyzing if patches, like those proposed by Stephen on services, remain unmerged. Then the TC would be informed. It would be a kind of signal addressed to the TC. Then the TC would be free to make a decision (abandoning this deliverable, removing cross-job, put-your-idea-here). The requirements team already provides such great job and expertise. Without them we wouldn't have solved the oslo.db and castellan case in time. However, I think we lack of aTC involvement a little bit earlier in the series to avoid fire fighter moments. The monitoring would officialize problems with deliverables sooners in the life cycle and would trigger a TC involvement. Here is the opportunity for us to act to better anticipate the growing phenomenon of lack of maintainers. Here is the opportunity for us to better anticipate our available human resources. Here is the opportunity for us to better handle this kind of incident in the future. Thus, we could integrate substantive actions in terms of human resources management into the life cycle of Openstack. It is time to manage this pain point, because in the long term, if nothing is done now, this problem will repeat itself again and again. Concerning the feasibility of this solution, the release team already created some similar monitoring. This monitoring is made during each series at specific milestones. The requirements team could trigger its monitoring at specific milestones targets, not too close to the series deadline. Hence we would be able to anticipate decisions. The requirements team could inspire from the release management process [19] to create their own monitoring. We already own almost the things we need to create a new process dedicated to this monitoring. Hence, this solution is feasible. The usefulness of this solution is obvious. Indeed, thus the TC would have better governance monitoring. A monitoring not based on people elected as TC members but based on process and so transmissible from a college to another. Therefore, three teams would then work together on the topic of decreasing activity inside teams. >From a global point of view, this will allow Openstack to more efficiently keep pace with the resources available from series to series. I would now like to special thank Stephen for his investment throughout these two years dedicated to the oslo.db migration. I would especially like to congratulate Stephen for the quality of the work carried out. Stephen helped us to solve the problem in an elegant manner. Without his expertise, delivering Bobcat would have been really painful. However, we should not forget that Stephen remains a human resource of Openstack and we should not forget that his expertise could go away from Openstack one day or one other. Solving this type of problem cannot only rest on the shoulders of one person. Let's take collective initiatives now and put in place safeguards. Thanks for your reading and thanks to all the people who helped with this topic and that I have not cited here. I think other solutions surely coexist and I'll be happy to discuss this topic with you. [1] https://opendev.org/openstack/requirements/src/branch/master/upper-constrai… [2] https://releases.openstack.org/bobcat/index.html#bobcat-oslo-db [3] https://opendev.org/openstack/releases/src/branch/master/deliverables/antel… [4] https://review.opendev.org/c/openstack/requirements/+/873390 [5] https://review.opendev.org/c/openstack/requirements/+/878130 [6] https://opendev.org/openstack/oslo.log/compare/5.1.0...5.2.0 [7] https://lists.openstack.org/pipermail/openstack-discuss/2023-September/0351… [8] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.… [9] https://review.opendev.org/q/topic:sqlalchemy-20 [10] https://review.opendev.org/q/topic:sqlalchemy-20+status:open [11] https://review.opendev.org/c/openstack/requirements/+/887261 [12] https://opendev.org/openstack/oslo.db/commit/115c3247b486c71317613942264714… [13] https://opendev.org/openstack/oslo.db/commit/4ee79141e601482fcde02f0cecfb56… [14] https://review.opendev.org/c/openstack/requirements/+/896053 [15] https://www.openstack.org/software/ussuri [16] https://www.openstack.org/software/victoria [17] https://www.openstack.org/software/xena [18] https://www.openstack.org/software/antelope/ [19] https://releases.openstack.org/reference/process.html#between-milestone-2-a… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

2 2

[tc][all] Please welcome Jay Faulkner as new Chair of Technical Committee
by Nikolla, Kristi 26 Sep '23

26 Sep '23

Hi all, Please join me in congratulating Jay Faulkner (JayF) as the new Chair of the OpenStack Technical Committee. Thank you for stepping up and thank you for your amazing contributions on the Technical Committee as a valued member and as my vice-chair for the past cycle. Kristi Nikolla

2 1

[openstack][neutron] OpenStack deployment
by Dhanasekar Kandasamy 26 Sep '23

26 Sep '23

Hi, I planning to deploy OpenStack for production zed release, OVS with DVR when I went through the reference architectures I can see - 3 controller, 3 network and x compute nodes or - 3 controllers + network and x computes nodes I want to understand what happens if I go with the below configuration OVS with DVR - 3 controller node - x compute + network nodes For example I have 13 nodes, 3 controllers, 10 compute + network nodes what is the advantage/disadvantage for this configuration Thanks & Regards, Dhana

2 1

[oslo][heat][requirements] RFE requested for oslo.messaging
by Herve Beraud 26 Sep '23

26 Sep '23

Hey Requirements Team, The previous bump of oslo.messaging (14.4.0) remains blocked [1] by a recent oslo.messaging change [2] that was blocked by heat's cross testing jobs. This issue is now fixed on the oslo.messaging side [3], and in the way to be released [4]. Hence a new requirements update will arrive soon on the requirements side. This new version should fix the heat compatibility issue, thus, this will allow us to resync upper-constraints [5] and listed releases [6] before bobcat's final release. [1] https://review.opendev.org/c/openstack/requirements/+/892919 [2] https://review.opendev.org/c/openstack/oslo.messaging/+/891096 [3] https://review.opendev.org/c/openstack/oslo.messaging/+/896422 [4] https://review.opendev.org/c/openstack/releases/+/896498 [5] https://opendev.org/openstack/requirements/src/branch/master/upper-constrai… [6] https://releases.openstack.org/bobcat/index.html#bobcat-oslo-messaging Thank you for considering this request. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[openstack-ansible][manila deployment] error: No valid host was found
by Danish Khan 25 Sep '23

25 Sep '23

Dear Team, I have deployed Manila in openstack-ansible and I have created share type and share network. But I am still unable to create a share in it. Below is the journalctl error from manila container : Sep 24 16:45:13 aio1-manila-container-5cce4ee7 manila-scheduler[69]: 2023-09-24 16:45:13.689 69 ERROR manila.scheduler.manager [req-13a8ec7b-2b66-452b-964b-f531b75b699b c0806f7a8b534149a72931b84f7d60af 61c6349cbba74db88d14d3b7348de585 - - -] Failed to schedule create_share: No valid host was found. Failed to find a weighted host, the last executed filter was AvailabilityZoneFilter.: manila.exception.NoValidHost: No valid host was found. Failed to find a weighted host, the last executed filter was AvailabilityZoneFilter. And below is the error of manila-share.service from controller node: Sep 24 16:44:24 aio1 manila-share[250518]: 2023-09-24 16:44:24.016 250518 CRITICAL manila [req-3c0e428b-226b-4bff-ade1-3d4ac5befb99 - - - - -] Unhandled error: manila.exception.ManilaException: Config opt 'driver_handles_share_servers' has improper value - 'None'. Please define it as boolean. Note: manila-share service is continueously giving this error even if there is no resources of manila(even in the setup). I am not sure where I am supposed to define driver_handles_share_servers defautl value if there is no share type. Thanks in advance. Regards, Danish

2 1

[neutron] Bug deputy report (week starting on September 18)
by Bernard Cafarelli 25 Sep '23

25 Sep '23

Hey neutrinos, time for a new bug deputy rotation again! Here are the bugs reported between 2023-09-18 and 2023-09-24 Quite a few bugs have patches in progress. For the rest, some failures on neutron-tempest-plugin-openvswitch tempest jobs in the first 2 bugs listed below, possibly a design question for https://bugs.launchpad.net/neutron/+bug/2036705 <https://bugs.launchpad.net/neutron/+bug/2036705> (different behaviour in ML2/OVN), one RBAC bug on tags in https://bugs.launchpad.net/neutron/+bug/2037002 and 2 other unassigned bugs https://bugs.launchpad.net/neutron/+bug/2037107 and https://bugs.launchpad.net/neutron/+bug/2036877 Critical * neutron-tempest-plugin-openvswitch-* jobs randomly failing in gate - https://bugs.launchpad.net/neutron/+bug/2037239 Just reported by haleyb - tests failing with "x is not active on any of the L3 agents" High * [tempest] Test "test_multicast_between_vms_on_same_network" radonmly failing - https://bugs.launchpad.net/neutron/+bug/2036603 Unassigned. Random recent failure in that test * Neutron tempest plugin zuul job definitions uses deprecated regex syntax - https://bugs.launchpad.net/neutron/+bug/2037034 Fix by ykarel: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/896188 * neutron-ovn-metadata-agent dies on broken namespace - https://bugs.launchpad.net/neutron/+bug/2037102 Not a common case but it can keep the agent down until fixed Patch by felix.huettner: https://review.opendev.org/c/openstack/neutron/+/896251 New * Reader can update object tag - https://bugs.launchpad.net/neutron/+bug/2037002 *_reader roles were not cooperating when I tried to reproduce this in devstack - needs another set of eyes Medium * Neutron fails to respawn radvd due to corrupt pid file - https://bugs.launchpad.net/neutron/+bug/2033980 When radvd crashes (it can happen like in cases described by users in LP), neutron does not respawn it properly - it works fine when we are restarting/killing it Patch by haleyb: https://review.opendev.org/c/openstack/neutron/+/895832 * [OVN] The API worker fails during "post_fork_initialize" call - https://bugs.launchpad.net/neutron/+bug/2036607 Enhancement to better handle restarts (as tested by tobiko). Patches by ralonsoh: https://review.opendev.org/c/openstack/neutron-lib/+/895940 https://review.opendev.org/c/openstack/neutron/+/895946 https://review.opendev.org/c/openstack/neutron/+/896009 * [ovn-octavia-provider] Fix issue when LRP has more than one address - https://bugs.launchpad.net/neutron/+bug/2036620 Fix by froyo - https://review.opendev.org/c/openstack/ovn-octavia-provider/+/895826 * A port that is disabled and bound is still ACTIVE with ML2/OVN - https://bugs.launchpad.net/neutron/+bug/2036705 Unassigned. Different behaviour compared to ML2/OVS (where status is down) * [pep8] Pylint error W0105 (pointless-string-statement) in random CI executions - https://bugs.launchpad.net/neutron/+bug/2036763 Random failure, fix by ralonsoh: https://review.opendev.org/c/openstack/neutron/+/895975 * radvd seems to crash when ipv4 addresses are supplied as nameservers to ipv6 subnets - https://bugs.launchpad.net/neutron/+bug/2036877 Unassigned. Follow-up enhancement to https://bugs.launchpad.net/neutron/+bug/2033980 to prevent adding IPv4 servers to radvd config * slow port creation with a large amount of networkrbacs - https://bugs.launchpad.net/neutron/+bug/2037107 Unassigned. We pushed an enhancement for similar slowness in https://bugs.launchpad.net/neutron/+bug/1918145 but not fixing this case. sqlalchemy/SQL experts welcome there Incomplete * subnet's gateway ip can be unset while attached to router - https://bugs.launchpad.net/neutron/+bug/2036423 Regards, -- Bernard Cafarelli

1 0

[kolla-ansible][keystone][skyline] Keystone use SSO for authentication
by Nguyễn Hữu Khôi 24 Sep '23

24 Sep '23

Hello guys. I want to share a lab to help newbies understand how setup Keystone and Skyline to use Google SSO for authentication, https://github.com/ngyenhuukhoi/openstack-note/blob/main/skyline%20with%20s… I will try to contribute what I can for newbies and community. Nguyen Huu Khoi

3 2

[aodh][mistral][solum][release][requirements] Feature freeze exception for wsme, sphinxcontrib-pecanwsme
by Stephen Finucane 22 Sep '23

22 Sep '23

o/ I'd like to request a feature freeze exception for the aforementioned packages to include fixes we recently merged: * WSME 0.12.1 includes two fixes to the Sphinx extension to fix compatibility with recent Sphinx versions. There are also additional fixes to address compatibility with Python 3.11 (by switching from nose to pytest, by replacing use of pkg_utils with importlib.metadata, and by replacing use of inspect.getargspec with inspect.getfullargspec). * sphinxcontrib-pecanwsme 0.11.0 includes a fix for Python 3.11 compatibility (replacing use of inspect.getargspec with inspect.getfullargspec), drops support for Python < 3.8, and removes the use of six. I've included a summary of the git logs below. I would argue that both version bumps are low-risk and address issues we're seeing in the gates of multiple projects. I would also argue that bumping these versions is a lower risk strategy than the alternative proposal, namely the reintroduction of a cap on the Sphinx version used to a version released nearly 18 months ago [2] (!!). Finally, I would argue that this would be the preferred approach by our packagers (zigo, are you there?). The change is available [3] and waiting for reviews. Cheers, Stephen PS: Why WSME 0.12.1 rather than 0.12.0, you ask? You can blame a typo [4] for that 🙈 [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-September/0351… [2] https://pypi.org/project/Sphinx/4.5.0/ [3] https://review.opendev.org/c/openstack/requirements/+/896195 [4] https://review.opendev.org/c/x/wsme/+/896153

2 1

[release] Release countdown for week R-1 Sept 25-29
by Herve Beraud 22 Sep '23

22 Sep '23

Development Focus ----------------- We are on the final mile of the 2023.2 Bobcat development cycle! Remember that the 2023.2 Bobcat final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. September 28, 2023 is the deadline for final 2023.2 Bobcat release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on October 4, 2023. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2024.1 Caracal development cycle, including discussing Forum and PTG sessions content, in preparation of the 2024.1 Caracal Virtual PTG (October 23-27, 2023). Actions ------- Watch for any translation patches coming through on the stable/2023.2 branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/2023.2 branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final 2023.2 Bobcat release: October 4, 2023 2024.1 Caracal Virtual PTG: October 23-27, 2023 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[Nova][Neutron] Help troubleshooting metadata service error 404 (Ussuri)
by Jérôme BECOT 22 Sep '23

22 Sep '23

Hello, I am operating several OpenStack Ussuri clouds and we lately have random troubles with the metadata service. We run all our networks as provider networks. The metadata service works fine for months some hosts can't get their metadata with a 404 error I restarted nova-api, neutron-dhcp-agent and neutron-metadata-agent on all controllers but we still experience 404 on random nodes: ssh 10.60.51.130 $ ip r s ... 169.254.169.254 via 10.60.51.121 dev eth0 $ curl -s http://169.254.169.254 <html> <head> <title>404 Not Found</title> </head> <body> <h1>404 Not Found</h1> The resource could not be found.<br /><br /> </body> </html> ssh 10.60.51.131 $ ip r s ... 169.254.169.254 via 10.60.51.121 dev eth0 $ curl -s http://169.254.169.254 {"uuid": "ee6e8dea-796b-4a56-bb1e-1c38f4ac9030", "meta": {"Created By": "terraform"}...} $ grep "10.60.51.131" /var/log/neutron/neutron-metadata-agent.log 2023-09-22 12:41:10.687 21954 INFO eventlet.wsgi.server [-] 10.60.51.131,<local> "GET /openstack/latest/meta_data.json HTTP/1.1" status: 200 len: 2729 time: 0.3817778 $ grep "10.60.51.130" /var/log/neutron/neutron-metadata-agent.log $ grep "10.60.51.130" /var/log/nova/nova-api.log # on all controllers $ grep "10.60.51.131" /var/log/nova/nova-api.log # on all controllers 2023-09-22 12:41:10.682 57433 INFO nova.metadata.wsgi.server [req-1d222a75-ccb4-49bc-8b17-2e2e81dc5f9b - - - - -] 10.60.51.131,1.2.3.4 "GET /openstack/latest/meta_data.json HTTP/1.1" status: 200 len: 2710 time: 0.2587621 Can you help me to troubleshoot this behaviour for some hosts ? Regards -- *Jérôme B*<https://www.deveryware.com>

2 5

Problem with Barbican
by Derek O keeffe 22 Sep '23

22 Sep '23

Hi all, Hopefully someone may be able to give me some info/advice on this one. I've been asking in the IRC chat but unfortunately we couldn't get to the bottom of it, I'm hoping someone here may not be in the chat but able to help :) So I have an Openstack AIO that I'm trying to test Barbican on with a Thales Luna HSM. I get through the instructions to the point where I successfully create the HMAK and MKEK keys. After this I try the following commands: openstack secret store --name mysecret1 --payload testPayload openstack volume create --size 1 --type LUKS 'encrypted volume' Both of those fail and the logs from the Barbican container are here: Paste #bU1E0joDdf4eWiV8wjlj | LodgeIt! | | | | Paste #bU1E0joDdf4eWiV8wjlj | LodgeIt! | | | I have made sure that "library_path: /opt/barbican/libs/libCryptoki2.so in Barbican.conf actually exists so I have no idea really where to look after this, I can't see any info as to where Barbican is trying to find the crypto plugin or maybe do I need to install something else manually?? Anyway I hope someone might have some useful info or advice to help and thanks all for reading. Regards,Derek

2 1

[neutron] Thanks for the Bobcat release (and now let's continue working in Caracal)
by Rodolfo Alonso Hernandez 22 Sep '23

22 Sep '23

Hello Neutrinos: Before stepping down as Neutron PTL, I would like to thank you for your commitment and work done during the last two releases. Let's keep Neutron, the stadium projects and OpenStack in general healthy and growing every day. We are now in the RC phase and we should be focused on delivering the best possible code for Bobcat cycle. So far I think we are going to deliver a good quality release. And in advance for the next cycle, let me bring here the hot topics we have right now in gerrit. I would ask you, as I've done during the last year, to spend some time reviewing them in order to continue the development of these features. The sooner we merge them in the Caracal cycle, the better we'll test it during the release development period. Please remember this list is just a brief summary of the most relevant features under review. ** Specs ** https://review.opendev.org/c/openstack/neutron-specs/+/891204: Add spec for partial support for OVN Interconnect RFE ** RFEs and important bugs ** https://review.opendev.org/q/topic:neutron_ovn_l3_scheduler: a series of patches related to LP#2023993, that will improve the OVN L3 scheduler. https://review.opendev.org/c/openstack/neutron/+/894026: support for IPv6 in the OVN metadata, closing a present gap between ML2/OVS and ML2/OVN. https://review.opendev.org/c/openstack/neutron/+/882832: provide a new parameter to define the port HW offload capability, instead of writing directly on the port binding profile. https://review.opendev.org/q/topic:distributed_metadata_data_path: a series of patches for ML2/OVS, to provide distributed metadata capabilities. https://review.opendev.org/q/topic:2023-aa-l3-gw-multihoming: a series of patches to provide to ML2/OVN multihoming (active-active) L3 GW capabilities. Regards.

1 0

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 22 Sep '23

22 Sep '23

Hello Neutrinos: Due to the lack of agenda [1], today's meeting is cancelled. Have a nice weekend. [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

Requirements FFE to return Sphinx to known working version
by Erno Kuvaja 21 Sep '23

21 Sep '23

Hi all, I'm writing to request FFE for https://review.opendev.org/c/openstack/requirements/+/896018 Revert "Bump Sphinx to the latest version" as it broke the gate of at least following projects: Aodh https://zuul.opendev.org/t/openstack/build/5df111c602944396bf6e334e1bec4e42 Solum https://zuul.opendev.org/t/openstack/build/e4b170cc25f2428caadce8870d27c62e Mistral https://zuul.opendev.org/t/openstack/build/a3e00a6312cf46059fa81c56fe9b5e11 Stephen kindly provided monkeypathing for Aodh as alternative https://review.opendev.org/c/openstack/aodh/+/896125 With kind regards that we shouldn't revert this breaking patch due to it being breaking via wsme dependency that is apparently not really maintained anymore. I'd be easily agreeing with that if Aodh was the only project suffering the breakage or using it at all, but the lib is in use for about dozen openstack projects and this dependency bump broke the gates for three of them. Other alternative for this is that wsme would get released (the fix is merged already) and we would bump that in the upper constraints. I would personally prefer any other option than needing to monkeypatch/vendor the wsme code in the projects long enough that we can find a solution to remove it as dependency across. Thanks for looking into this, Erno "jokke" Kuvaja

2 1

[ironic] [ptl] Announcement of non-candidacy for D / 2024.2
by Jay Faulkner 21 Sep '23

21 Sep '23

Hi all, I was just re-elected (thank you!) for my third team as Ironic PTL. By the time the D series starts, it'll be 18 months serving as PTL of the Ironic team. I believe it may cause harm to our project to have the PTL position stay on one individual for too long. For that reason, I'm announcing my non-candidacy for the next PTL election, for the "D" cycle, 2024.2. Ironic contributors who have an interest in being PTL, please reach out to me -- I'd be happy to work with you to ensure there is a good transition. Thanks, Jay Faulkner Ironic PTL

1 0

[all][elections][tc] Technical Committee Election Results
by Tony Breeds 21 Sep '23

21 Sep '23

Please join me in congratulating the 4 newly elected members of the Technical Committe (TC). Dan Smith (dansmith) Jens Harbott (frickler) Ghanshyam Mann (gmann) Jay Faulkner (JayF) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_36ebf2eba022aded Election process details and results are also available here: https://governance.openstack.org/election/ 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. Yours Tony.

3 2

Cyborg nova reports mdev-capable resource is not available
by Karl Kloppenborg 21 Sep '23

21 Sep '23

Hi Cyborg Team! Karl from Helm Team. When creating a VM with the correct flavor, the mdev gets created by cyborg agent and I can see it in the nodedev-list --cap mdev. However Nova then fails with: nova.virt.libvirt.driver [<removed>- - default default] Searching for available mdevs... _get_existing_mdevs_not_assigned /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driver.py :8357 2023-09-21 14:34:47.808 1901814 INFO nova.virt.libvirt.driver [<removed> - - default default] Available mdevs at: set(). 2023-09-21 14:34:47.809 1901814 DEBUG nova.virt.libvirt.driver [<removed> - - default default] No available mdevs where found. Creating an new one... _allocate_mdevs /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driv er.py:8496 2023-09-21 14:34:47.809 1901814 DEBUG nova.virt.libvirt.driver [<removed> - - default default] Attempting to create new mdev... _create_new_mediated_device /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driver.py:8385 2023-09-21 14:34:48.455 1901814 INFO nova.virt.libvirt.driver [<removed> - - default default] Failed to create mdev. No free space found among the following devices: ['pci_0000_4b_03_1', … <truncated list>]. 2023-09-21 14:34:48.456 1901814 ERROR nova.compute.manager [<removed> - - default default] [instance: 2026e2a2-b17a-43ab-adcb-62a907f58b51] Instance failed to spawn: nova.exception.ComputeResourcesUnavailable: Insufficient compute resources: mdev-capable resource is not available. Once this happened, ARQ removes the mdev and cleans up. I’ve got Cyborg 2023.2 running and have a device profile like so: karl@Karls-Air ~ % openstack accelerator device profile show e2b07e11-fe69-4f33-83fc-0f9e38adb7ae +-------------+---------------------------------------------------------------------------+ | Field | Value | +-------------+---------------------------------------------------------------------------+ | created_at | 2023-09-21 13:30:05+00:00 | | updated_at | None | | uuid | e2b07e11-fe69-4f33-83fc-0f9e38adb7ae | | name | VGPU_A40-Q48 | | groups | [{'resources:VGPU': '1', 'trait:CUSTOM_NVIDIA_2235_A40_48Q': 'required'}] | | description | None | +-------------+---------------------------------------------------------------------------+ karl@Karls-Air ~ % I can see the allocation candidate: karl@Karls-Air ~ % openstack allocation candidate list --resource VGPU=1 | grep A40 | 41 | VGPU=1 | 229bf15f-5689-3d2c-b37b-5c8439ea6a71 | VGPU=0/1 | OWNER_CYBORG,CUSTOM_NVIDIA_2235_A40_48Q | karl@Karls-Air ~ % Am I missing something critical here? Because I cannot seem to figure this out… have I got a PCI address wrong, or something? Any help from the Cyborg or Nova teams would be fantastic. Thanks, Karl.

1 0

[octavia] state of taskflow jobboards
by Maximilian Stinsky 21 Sep '23

21 Sep '23

Greetings, I would be interested in the state of the taskflow jobboard feature in octavia. [1] states it still is an experimental feature, but in the config section [2] it is not marked as such. If I look into the code I see that the feature is implemented since the U release. So my question would be is the taskflow jobboard feature still in an experimental state or is it considered production ready? If its still experimental is there any ETA when its expected to be production ready? Thanks in advance Maximilian [1] https://docs.openstack.org/octavia/latest/install/install-amphorav2.html [2] https://docs.openstack.org/octavia/latest/configuration/configref.html#task…

2 1

[ptls][Bobcat] OpenInfra Live: OpenStack Bobcat
by Kristin Barrientos 21 Sep '23

21 Sep '23

Hi everyone, As we get closer to the OpenStack release, I wanted to reach out to see if any PTL’s were interested in providing their Bobcat cycle highlights in an OpenInfra Live[1] episode on Thursday, October 5 at 1400 UTC. Ideally, we would get 4-6 projects represented. Previous examples of OpenStack release episodes can be found here[2]and here[3]. Please let me know if you’re interested by Monday, September 25 and I can provide the next steps. If you would like to provide a project update but that time doesn’t work for you, please share a recording with me and I can get it added to the project navigator. Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation [1] openinfra.dev/live [2] https://www.youtube.com/watch?v=MSbB3L9_MeY [3] https://www.youtube.com/watch?v=YdLTUTyJ1eU Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation

6 5

[all] [diversity] Call for Outreachy mentors & projects
by Dmitry Tantsur 21 Sep '23

21 Sep '23

Hi teams, Your humble Outreachy coordinators would like to invite you to submit projects for the winter 23/24 cohort! Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the technical industry where they are living. See https://www.outreachy.org/ for more details. The deadline for submission is Sep 29th, but please don't wait for the last moment since we need time to review your submissions and suggest potential improvements. Follow https://www.outreachy.org/communities/cfp/openstack/ or reach out to Mahati or myself if you have any questions. NOTE: this is not a call for interns yet. We will notify you separately. Thank you and good luck! Dmitry OpenStack community coordinator in Outreachy P.S. The Metal3 community, adjacent to Ironic, is also looking for projects and mentors: https://www.outreachy.org/communities/cfp/metal3/ Reach out to me if you're interested.

1 0