openstack- Deployment through kolla ansible
Asma Naz Shariq
asma.naz at techavenue.biz
Wed Sep 27 04:12:02 UTC 2023
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 at lists.openstack.org
<openstack-discuss-request at lists.openstack.org>
Sent: Tuesday, September 26, 2023 9:08 PM
To: openstack-discuss at lists.openstack.org
Subject: openstack-discuss Digest, Vol 59, Issue 97
Send openstack-discuss mailing list submissions to
openstack-discuss at 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 at lists.openstack.org
You can reach the person managing the list at
openstack-discuss-owner at 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 at gmail.com>
To: Dhanasekar Kandasamy <dhana.sys at gmail.com>
Cc: openstack-discuss at lists.openstack.org, skaplons at redhat.com
Subject: Re: [openstack][neutron] OpenStack deployment
Message-ID: <0695D533-7F6D-4B95-8148-E5A2336C8649 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.openstack.org/pipermail/openstack-discuss/attachments/2023092
6/a8696073/attachment-0001.htm>
------------------------------
Message: 2
Date: Tue, 26 Sep 2023 13:38:18 +0000
From: "Nikolla, Kristi" <knikolla at bu.edu>
To: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [tc][all] Please welcome Jay Faulkner as new Chair of
Technical Committee
Message-ID:
<BL0PR03MB4227BD4FB3C331EB22AEFEB2BEC3A at BL0PR03MB4227.namprd03.prod.outlook.
com>
Content-Type: text/plain; charset="us-ascii"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.openstack.org/pipermail/openstack-discuss/attachments/2023092
6/a22b2d42/attachment-0001.htm>
------------------------------
Message: 3
Date: Tue, 26 Sep 2023 17:43:05 +0200
From: Rodolfo Alonso Hernandez <ralonsoh at redhat.com>
To: "Nikolla, Kristi" <knikolla at bu.edu>
Cc: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [tc][all] Please welcome Jay Faulkner as new Chair of
Technical Committee
Message-ID:
<CAECr9X68em5moy2TUDkfYHFZWZC4z+2gbzrqWbqbhFpDDiBOtw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Congratulations Jay!
On Tue, Sep 26, 2023 at 3:39?PM Nikolla, Kristi <knikolla at bu.edu> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.openstack.org/pipermail/openstack-discuss/attachments/2023092
6/442f33d2/attachment-0001.htm>
------------------------------
Message: 4
Date: Tue, 26 Sep 2023 09:07:44 -0700
From: Ghanshyam Mann <gmann at ghanshyammann.com>
To: "Herve Beraud" <hberaud at redhat.com>, "suzhengwei"
<suzhengwei at inspur.com>
Cc: "openstack-discuss" <openstack-discuss at lists.openstack.org>
Subject: Re: [release][requirements][TC][oslo] how to manage
divergence between runtime and doc?
Message-ID:
<18ad23f1717.1112162185074.1090350270406337793 at ghanshyammann.com>
Content-Type: text/plain; charset="UTF-8"
Thanks for raising it.
It seems Sue volunteered to PTL for Masakari this month [1] so they should
be able to help here.
I am adding their email explicitly here in case they did not read the
openstack-discuss ML.
[1] https://review.opendev.org/c/openstack/election/+/892137
-gmann
---- On Tue, 26 Sep 2023 03:45:39 -0700 Herve Beraud wrote --- > Hello
TC, > Please can we have some feedback from the TC concerning the situation
described above and especially concerning the masakari issue with oslo.db:-
https://lists.openstack.org/pipermail/openstack-discuss/2023-September/03518
4.html-
https://review.opendev.org/q/project:openstack/masakari+topic:sqlalchemy-20
> It's too late to abandon masakari for the bobcat series, however, we
think that the tc does have authority to request core reviewer permission to
any openstack project and approve change, and hence unlock this situation.
> Le?jeu. 21 sept. 2023 ??16:44, Herve Beraud hberaud at redhat.com> a ?crit?:
>
>
> --
> Herv? BeraudSenior Software Engineer at Red Hatirc:
hberaudhttps://github.com/4383/ > > 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-constrain
ts.txt#L482
> [2] https://releases.openstack.org/bobcat/index.html#bobcat-oslo-db
> [3]
https://opendev.org/openstack/releases/src/branch/master/deliverables/antelo
pe/oslo.db.yaml#L22
> [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/03510
0.html
> [8]
https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.h
tml
> [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/115c3247b486c713176139422647144
108101ca3
> [13]
https://opendev.org/openstack/oslo.db/commit/4ee79141e601482fcde02f0cecfb561
ecb79e1b6
> [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-an
d-milestone-3
>
> --
> Herv? BeraudSenior Software Engineer at Red Hatirc:
hberaudhttps://github.com/4383/ > >
------------------------------
Subject: Digest Footer
_______________________________________________
openstack-discuss mailing list
openstack-discuss at lists.openstack.org
------------------------------
End of openstack-discuss Digest, Vol 59, Issue 97
*************************************************
More information about the openstack-discuss
mailing list