- openstack-discuss - lists.openstack.org

[largescale-sig] Next meeting: October 4, 15utc
by Thierry Carrez 02 Oct '23

02 Oct '23

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 15UTC, our EU+US-friendly time. Kristin will be chairing. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231004T15 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 0

[neutron] Bug deputy report (week starting on September 25)
by Lajos Katona 02 Oct '23

02 Oct '23

Hi, I was the bug deputy for Neutron last week, please see my summary of last week's bugs. *High* * Description Failed to invoke the API interface to obtain the address group list (https://bugs.launchpad.net/neutron/+bug/2037596 ) - In Progress * [OVN] ``PortBindingChassisEvent`` event is not executing the conditions check (https://bugs.launchpad.net/neutron/+bug/2037717) - In Progress * No possibility to delete ECMP routes ( https://bugs.launchpad.net/ovsdbapp/+bug/2037536 ) - In Progress, OVSDBAPP * Impossible to add a static route if learned route exists ( https://bugs.launchpad.net/ovsdbapp/+bug/2037573 ) - In progress, OVSDBAPP * Impossible to specify a routing table ( https://bugs.launchpad.net/ovsdbapp/+bug/2037652 ) - In progresss OVSDBAPP *Medium* * Do not depend on l3-agent for vpn failover ( https://bugs.launchpad.net/neutron/+bug/1999761) - In Progress / VPNaaS * unit tests don't work for 'hardware_vtep' ( https://bugs.launchpad.net/ovsdbapp/+bug/2037568 ) - In Progress, OVSDBAPP *Low hanging fruit / Incomplete* * BGP floating IPs over l2 segmented network in Neutron ( https://bugs.launchpad.net/neutron/+bug/2037263 ) - Doc fix. * OVSDB transaction returned TRY_AGAIN, retrying do_commit ( https://bugs.launchpad.net/neutron/+bug/2037500 ) - I can't reproduce it, the original bug is for Victoria. *RFE* * [OVN] Allow scheduling external ports on non-gateway nodes ( https://open.spotify.com/playlist/2nI2TA9KrHvlcrZWH5xPbz ) RFE approved, discussed on Friday's Drivers Meeting. Regards Lajos Katona

1 0

[charms] Feature freeze and release date for 2023.2 'bobcat' charms
by Alex Kavanagh 02 Oct '23

02 Oct '23

Hi All The OpenStack 2023.2 feature freeze is happening this Friday, 1st April. The "23.10" charms release set of the charms is to support OpenStack 2023.2 ‘bobcat’ which is releasing this week. OpenStack charms will support 2023.2 ‘bobcat’ on Ubuntu 22.04 (Jammy) and the upcoming Ubuntu 23.10 (Mantic). The charms comprise of OpenStack, Ceph, OVN and various support charms. We anticipate the release of the charms to the 2023.2/stable channel for the OpenStack charms during the w/b 23rd October, with the target release date of Wednesday 25th October. Please reach out to us on #openstack-charms if you require any further information. Thanks Alex.-- Alex Kavanagh OpenStack Engineering - Canonical Ltd

1 0

Wsgi in openstack
by Gk Gk 30 Sep '23

30 Sep '23

Hi All, I am new to python coding and trying to understand how wsgi is implemented in nova or glance api servers. What would be the best way to understand the design here ? Are there any useful documents available over the internet to understand these ? I understand the WSGI standard. I can't figure out where the start_response functions are coded in nova-api wsgi implementation. Any useful tips are highly appreciated. Thanks so much for your time. Thanks Y.G

3 3

[release] Release countdown for week R+0, Oct 02-06
by Elõd Illés 29 Sep '23

29 Sep '23

Development Focus ----------------- We will be releasing the coordinated OpenStack 2023.2 Bobcat release next week, on Wednesday, October 4th, 2023. Thanks to everyone involved in the 2023.2 Bobcat cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: http://ptg.openstack.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 4th, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final 2023.2 Bobcat release: October 4th, 2023 2024.1 Caracal Virtual PTG: October 23-27, 2023 Előd Illés irc: elodilles @ #openstack-release

1 0

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

29 Sep '23

Hello neutrinos: Please remember today we have the Neutron drivers meeting. This is the agenda: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers There are two topics: * [fwaas][rfe] support list type of port_range for firewall rule (I can't find this in the meeting logs) * [OVN] Allow scheduling external ports on non-gateway nodes See you in 2,5 hours!

1 0

[all][debian] First VM running under Bobcat pings: Debian Bobcat repository is ready!
by Thomas Goirand 29 Sep '23

29 Sep '23

Hi, As on each release, my first test is to pop a new OpenStack cluster on my visualized environment (a single machine running 38 VMs with nested virt). Today, my first VM running under Bobcat was ACTIVE and pinged. All of this is available the usual way, especially with extrepo if you want to use the unofficial Bookworm backport: apt-get install extrepo extrepo enable openstack_bobcat apt-get update The following days, I'll be uploading all of this form Debian Experimental to Unstable, trying to add as many SQLAlchemy 2.x support as I can, since the package needs to be uploaded to Unstable soon. There's also a few packages that I didn't have time to finish yet (like the last version of Horizon that has many unit test failures that I didn't have time to look on...). Thanks to everyone that contributed to Bobcat, or that was involved in this release, Cheers, Thomas Goirand (zigo)

2 1

Masakari Issue
by Karera Tony 29 Sep '23

29 Sep '23

Hello Team,, I have a cluster of 4 Compute nodes but when shutdown the VMs so that I can upgrade the kernel for the Hosts, The compute nodes in instance-ha and stuck in Maintenance mode. When I try to change them, I get the error below. Error: Failed to update host. Details ConflictException: 409: Client Error for url: http://10.10.13.31:15868/v1/segments/8d042245-5610-4b84-b611-b633f8f8367c/h…, Host 066c5654-dd1a-4fa9-a664-dad10b89e202 can't be updated as it is in-use to process notifications Regards Tony Karera

1 0

Masakari Issue
by Karera Tony 28 Sep '23

28 Sep '23

Hell oTeam, I have an openstack Wallaby Environment deployed using kolla-ansible. So, I shutdown all the VMs on the compute nodes becauseI wanted to upgrade the nodes kernel. After I rebooted them and all was fine apart from the fact that all the hosts in instance-ha segment are in maitenance mode. When I try to turn to false. I get the error below. *Error: *Failed to update host. Details <http://10.10.13.31/masakaridashboard/hosts/#message_details> ConflictException: 409: Client Error for url: http://x.x.x.x:15868/v1/segments/8d042245-5610-4b84-b611-b633f8f8367c/hosts…, Host 066c5654-dd1a-4fa9-a664-dad10b89e202 can't be updated as it is in-use to process notifications. Regards Tony Karera

1 0

[Glance] Weekly Meeting Cancelled for Today
by Pranali Deore 27 Sep '23

27 Sep '23

Hello Everyone, Cancelling today's weekly meeting, since there is nothing much on agenda for the week & few team members are also not around. See you next week ! Thanks & Regards, Pranali Deore

1 0

[all][tc] python 3.11 testing plan
by Ghanshyam Mann 27 Sep '23

27 Sep '23

Hi All, Some of you are part of discussion for python 3.11 testing but If you are not aware of it, below is the plan for python 3.11 testing in OpenStack. Non voting in 2023.2 ------------------------- You might have seen that python 3.11 job is now running as non voting in all projects[1]. Idea is to run it as non voting for this (2023.2) cycle which will give projects to fix the issue and make it green. As it is running on debian (frickler mentioned the reason of running it in debian in gerrit[2]), it need some changes in bindep.txt file to pass. Here is the example of fix[3] which you can do in your project also. Voting in 2024.1 -------------------- In next cycle (2024.1), I am proposing to make py3.11 testing mandatory [4] and voting (automatically via common python job template). You need to fix the failure in this cycle otherwise it will block the gate once the next cycle development start (basically once 891238 is merged). [1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891227/5 [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891146/1 [3] https://review.opendev.org/c/openstack/nova/+/891256 [4] https://review.opendev.org/c/openstack/governance/+/891225 [5] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891238 -gmann

12 27

[kolla-ansible][neutron] Kolla-ansible deployment where not all network nodes have access to the same external networks
by Moonpiedumplings TheSecond 27 Sep '23

27 Sep '23

I'm currently prototyping for what will be a two node openstack install via kolla-ansible, with one part on a public vps as a network node, and another on my home server as the main compute/controller node, and an allinone node. I want to use the VPS to give virtual machines public ipv6 addresses. However, the VPS only has one ipv4 address (and I am not willing to buy more). I'm thinking the simplest way to have both ipv4 and ipv6 connectivity is just to have my "home" node be a network node as well, and then just virtual machines a ipv6 floating ip, an access to a normal, internal ipv4 subnet. However, I can't get networking working properly, as I don't know how to force openstack to create a network on a specific node. I have it halfway working, I can create a network on the equivalent of the main node in my prototypes, but not on the "vps" node. I can create a network, but not create a virtual machine on that network, or give a virtual machine a floating ip from that network. In my blog, I have documented what I've tried, but it's somewhat disorganized, as I've documented my entire process, not just my networking troubles: https://moonpiedumplings.github.io/projects/build-server-2/#asking-for-help Thanks in advance for any help you have to offer,

1 0

Cinder Bug Report 2023-09-27
by Jon Bernard 27 Sep '23

27 Sep '23

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> Undecided - cinder reimage failure leaves the volume in downloading state <https://bugs.launchpad.net/cinder/+bug/2036994> - Status: In Progress - Backup using Swift driver fails when TLS is enabled on internal network <https://bugs.launchpad.net/cinder/+bug/2037113> - Status: New Thanks, -- Jon

1 0

[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