September 2023 - openstack-discuss

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