From mrunge at matthias-runge.de  Fri Sep  1 06:42:18 2023
From: mrunge at matthias-runge.de (Matthias Runge)
Date: Fri, 1 Sep 2023 08:42:18 +0200
Subject: [Telemetry] Adding Erno Kuvaja (jokke_) to telemetry cores
Message-ID: <05a688fe-b1ba-568d-3eed-888e92ea5fa1@matthias-runge.de>

Hi there,

a bit premature, but in-line with[1] I've added Erno to telemetry cores.

Erno is not a stranger in the OpenStack world and has been deeply 
involved in glance for quite a while. Thank you Erno for stepping up and 
for helping with Telemetry!

Matthias


[1] https://governance.openstack.org/election/#ptl-candidates
-- 
Matthias Runge <mrunge at matthias-runge.de>


From mrunge at matthias-runge.de  Fri Sep  1 06:48:24 2023
From: mrunge at matthias-runge.de (Matthias Runge)
Date: Fri, 1 Sep 2023 08:48:24 +0200
Subject: [all] osprofiler requirements on opentelemetry: is this
 reasonable?
In-Reply-To: <71d1f143-c108-a1be-216b-fa7d1a4adf03@debian.org>
References: <71d1f143-c108-a1be-216b-fa7d1a4adf03@debian.org>
Message-ID: <bc26cc83-541a-a56c-8138-ce5d5631a088@matthias-runge.de>

On 30/08/2023 11:11, Thomas Goirand wrote:
> Hi,
> 
> I just saw that the last version of osprofiler requires 
> opentelemetry-exporter-otlp and opentelemetry-sdk. Since osprofiler is 
> used in almost all projects, and that opentelemetry is really HUGE, I 
> wonder if this is all reasonable. This forces downstream distros to do a 
> lot of packaging only for that. Is this avoidable?
> 
> I started doing the packaging, and then stopped to write this message, 
> seeing how much work that would represent.

Hi zigo,

from what I have seen here (and you may remember talking about this when 
we met at the OpenInfra Summit this year), the change makes sense to me.

Quickly looking at [1], there may be the possibility to make it optional 
though, and that would certainly make sense for the other drivers too.

Matthias


[1] 
https://github.com/openstack/osprofiler/commit/908e7402320eb067db45aa9700d54d31c259f3ca
-- 
Matthias Runge <mrunge at matthias-runge.de>



From noonedeadpunk at gmail.com  Fri Sep  1 07:11:15 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Fri, 1 Sep 2023 09:11:15 +0200
Subject: [all] osprofiler requirements on opentelemetry: is this
 reasonable?
In-Reply-To: <bc26cc83-541a-a56c-8138-ce5d5631a088@matthias-runge.de>
References: <71d1f143-c108-a1be-216b-fa7d1a4adf03@debian.org>
 <bc26cc83-541a-a56c-8138-ce5d5631a088@matthias-runge.de>
Message-ID: <CAPd_6At=_31Ghz_YoMqW__zp66XoVQ6FQ30v4kWAsRS=MX7ntA@mail.gmail.com>

What is extremely weird for me, is that osprofiler is not I requirements at
all - only in test-requirements, which should mean that it should not be
required anywhere except for package testing? Though I see from code, that
osprofiler will just fail with ImportError if opentelemetry is absent,
which IMO is quite wrong from the beginning.

And indeed that would make sense to me to use extras_require on setup.cfg
to install only drivers that are needed, not * for each service.

Though I am not sure who is motivated enough to invest time into that
refactoring...

On Fri, Sep 1, 2023, 08:54 Matthias Runge <mrunge at matthias-runge.de> wrote:

> On 30/08/2023 11:11, Thomas Goirand wrote:
> > Hi,
> >
> > I just saw that the last version of osprofiler requires
> > opentelemetry-exporter-otlp and opentelemetry-sdk. Since osprofiler is
> > used in almost all projects, and that opentelemetry is really HUGE, I
> > wonder if this is all reasonable. This forces downstream distros to do a
> > lot of packaging only for that. Is this avoidable?
> >
> > I started doing the packaging, and then stopped to write this message,
> > seeing how much work that would represent.
>
> Hi zigo,
>
> from what I have seen here (and you may remember talking about this when
> we met at the OpenInfra Summit this year), the change makes sense to me.
>
> Quickly looking at [1], there may be the possibility to make it optional
> though, and that would certainly make sense for the other drivers too.
>
> Matthias
>
>
> [1]
>
> https://github.com/openstack/osprofiler/commit/908e7402320eb067db45aa9700d54d31c259f3ca
> --
> Matthias Runge <mrunge at matthias-runge.de>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/ef23bb76/attachment.htm>

From noonedeadpunk at gmail.com  Fri Sep  1 07:13:08 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Fri, 1 Sep 2023 09:13:08 +0200
Subject: [all] osprofiler requirements on opentelemetry: is this
 reasonable?
In-Reply-To: <CAPd_6At=_31Ghz_YoMqW__zp66XoVQ6FQ30v4kWAsRS=MX7ntA@mail.gmail.com>
References: <71d1f143-c108-a1be-216b-fa7d1a4adf03@debian.org>
 <bc26cc83-541a-a56c-8138-ce5d5631a088@matthias-runge.de>
 <CAPd_6At=_31Ghz_YoMqW__zp66XoVQ6FQ30v4kWAsRS=MX7ntA@mail.gmail.com>
Message-ID: <CAPd_6AvQ1_9FL2HYJ01XBZF-Gtnd6+5aCY+sxNg02bMRgarR3A@mail.gmail.com>

> osprofiler is not I requirements at all
I meant to say, is that opentelemetry is not in requirements of osprofiler

On Fri, Sep 1, 2023, 09:11 Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
wrote:

> What is extremely weird for me, is that osprofiler is not I requirements
> at all - only in test-requirements, which should mean that it should not be
> required anywhere except for package testing? Though I see from code, that
> osprofiler will just fail with ImportError if opentelemetry is absent,
> which IMO is quite wrong from the beginning.
>
> And indeed that would make sense to me to use extras_require on setup.cfg
> to install only drivers that are needed, not * for each service.
>
> Though I am not sure who is motivated enough to invest time into that
> refactoring...
>
> On Fri, Sep 1, 2023, 08:54 Matthias Runge <mrunge at matthias-runge.de>
> wrote:
>
>> On 30/08/2023 11:11, Thomas Goirand wrote:
>> > Hi,
>> >
>> > I just saw that the last version of osprofiler requires
>> > opentelemetry-exporter-otlp and opentelemetry-sdk. Since osprofiler is
>> > used in almost all projects, and that opentelemetry is really HUGE, I
>> > wonder if this is all reasonable. This forces downstream distros to do
>> a
>> > lot of packaging only for that. Is this avoidable?
>> >
>> > I started doing the packaging, and then stopped to write this message,
>> > seeing how much work that would represent.
>>
>> Hi zigo,
>>
>> from what I have seen here (and you may remember talking about this when
>> we met at the OpenInfra Summit this year), the change makes sense to me.
>>
>> Quickly looking at [1], there may be the possibility to make it optional
>> though, and that would certainly make sense for the other drivers too.
>>
>> Matthias
>>
>>
>> [1]
>>
>> https://github.com/openstack/osprofiler/commit/908e7402320eb067db45aa9700d54d31c259f3ca
>> --
>> Matthias Runge <mrunge at matthias-runge.de>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/3e74075e/attachment.htm>

From tonykarera at gmail.com  Fri Sep  1 09:13:03 2023
From: tonykarera at gmail.com (Karera Tony)
Date: Fri, 1 Sep 2023 11:13:03 +0200
Subject: Live migration error
Message-ID: <CA+69TL2=+mO-kk8AGgPrER2tm9rtA8UVO-_D1Wo82uHJB6D0jw@mail.gmail.com>

Hello Team,

I am trying to migrate instances from one host to another but I am getting
this error.

*Error: *Failed to live migrate instance to host "compute1". Details
<http://10.10.13.31/admin/instances/#message_details>
Migration pre-check error: Unacceptable CPU info: CPU doesn't have
compatibility. 0 Refer to
http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult (HTTP
400) (Request-ID: req-9dfdfe2e-70fa-481a-bd3d-c2c76a6e93da)

Any idea on how to fix this?

Regards

Tony Karera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/181597eb/attachment.htm>

From Danny.Webb at thehutgroup.com  Fri Sep  1 10:37:22 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Fri, 1 Sep 2023 10:37:22 +0000
Subject: Live migration error
In-Reply-To: <CA+69TL2=+mO-kk8AGgPrER2tm9rtA8UVO-_D1Wo82uHJB6D0jw@mail.gmail.com>
References: <CA+69TL2=+mO-kk8AGgPrER2tm9rtA8UVO-_D1Wo82uHJB6D0jw@mail.gmail.com>
Message-ID: <LO2P265MB57732DE42D150BA2CF76F5F49AE4A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

It means that you have CPUs with incompatible flags or you've got differing kernel versions that expose different flags or you've got differing libvirt versions that expose different flags.  You either need to use a lowest common denominator cpu_model or do a cold migration.
________________________________
From: Karera Tony <tonykarera at gmail.com>
Sent: 01 September 2023 10:13
To: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Live migration error


CAUTION: This email originates from outside THG

________________________________
Hello Team,

I am trying to migrate instances from one host to another but I am getting this error.


Error: Failed to live migrate instance to host "compute1". Details<http://10.10.13.31/admin/instances/#message_details>

Migration pre-check error: Unacceptable CPU info: CPU doesn't have compatibility. 0 Refer to http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult<http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult> (HTTP 400) (Request-ID: req-9dfdfe2e-70fa-481a-bd3d-c2c76a6e93da)

Any idea on how to fix this?

Regards

Tony Karera


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/83e99a2a/attachment-0001.htm>

From rdhasman at redhat.com  Fri Sep  1 10:46:13 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Fri, 1 Sep 2023 16:16:13 +0530
Subject: [cinder] Cinder Midcycle - 2 (R-6) for 2023.2 (Bobcat) Summary
Message-ID: <CAARK8KQEh0rPNv7htX2Etx+Ai0sFE7tUvSBtNem2DbFCV0Sy0g@mail.gmail.com>

Hello Argonauts,

The summary for mid cycle -2 (R-6) held on 23rd August, 2023 from 1400 to
1600 UTC is available at the wiki page[1].
Please go through the etherpad and the recording for the entire discussion.

[1] https://wiki.openstack.org/wiki/CinderBobcatMidCycleSummary

Thanks
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/b5407e37/attachment.htm>

From ralonsoh at redhat.com  Fri Sep  1 10:50:07 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 1 Sep 2023 12:50:07 +0200
Subject: [neutron] Neutron drivers meeting cancelled
Message-ID: <CAECr9X5VFuYXtmJ1exwt6V+jmiKwFAhy5rN-TDq-JfwCt9iv9A@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/ab9aaecf/attachment.htm>

From rdhasman at redhat.com  Fri Sep  1 11:47:16 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Fri, 1 Sep 2023 17:17:16 +0530
Subject: [cinder][FFE] Granting FFE to features (8th September)
Message-ID: <CAARK8KRPUfQU5WdEoN81yNvB8HBO2sq9UBLhCCFXsGyOiUjdKw@mail.gmail.com>

Hi All,

We had 6 feature requests during the 2023.2 (Bobcat) development cycle[1].
Few of the features had other patch dependencies amounting to significantly
more patches.
With limited review bandwidth, we were not able to review all the features
on time, hence I would like to grant FFE to the following listed features.

The reason so many changes are granted FFE are due to the following reasons:
* It has gone through iterations of updates and most of them has +2s so it
should just require another core to merge
* The response time for addressing review comments is fast which is a good
thing
* The changes are driver specific and isolated to a particular driver that
have been tested by the vendor team and third party CI

1. Fujitsu Driver: Add QoS support
Patch: https://review.opendev.org/c/openstack/cinder/+/847730

2. NetApp ONTAP: Added support to Active/Active mode in NFS driver
Patch: https://review.opendev.org/c/openstack/cinder/+/886869
Dependent patches:
https://review.opendev.org/c/openstack/cinder/+/798384
https://review.opendev.org/c/openstack/cinder/+/889826

3. [NetApp] LUN space-allocation support for iSCSI
Patch: https://review.opendev.org/c/openstack/cinder/+/893106

4. [Pure Storage] Replication-Enabled and Snapshot Consistency Groups
Patch: https://review.opendev.org/c/openstack/cinder/+/891234

5. [HPE XP] Support HA and data deduplication
Patch: https://review.opendev.org/c/openstack/cinder/+/892608
Dependent patches:
https://review.opendev.org/c/openstack/cinder/+/885986
https://review.opendev.org/c/openstack/cinder/+/879830
https://review.opendev.org/c/openstack/cinder/+/877672
https://review.opendev.org/c/openstack/cinder/+/891937

[1] https://etherpad.opendev.org/p/cinder-2023.2-bobcat-features

The deadline after FFE is going to be 8th September, 2023 but we will try
to get the changes reviewed and merged at the earliest. Let me know if
there are any queries or concerns.

Thanks
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/c212694b/attachment.htm>

From tonykarera at gmail.com  Fri Sep  1 12:56:32 2023
From: tonykarera at gmail.com (Karera Tony)
Date: Fri, 1 Sep 2023 14:56:32 +0200
Subject: Live migration error
In-Reply-To: <LO2P265MB57732DE42D150BA2CF76F5F49AE4A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
References: <CA+69TL2=+mO-kk8AGgPrER2tm9rtA8UVO-_D1Wo82uHJB6D0jw@mail.gmail.com>
 <LO2P265MB57732DE42D150BA2CF76F5F49AE4A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <CA+69TL142aYHGHJNYKMAUf2SM+nF-9epUyrDOUfiOLyCdKP30Q@mail.gmail.com>

Hello Danny,

Thanks for the feedback.

use a lowest common denominator cpu_model : Does this mean changing the
servers ?

Regards

Tony Karera




On Fri, Sep 1, 2023 at 12:37?PM Danny Webb <Danny.Webb at thehutgroup.com>
wrote:

> It means that you have CPUs with incompatible flags or you've got
> differing kernel versions that expose different flags or you've got
> differing libvirt versions that expose different flags.  You either need to
> use a lowest common denominator cpu_model or do a cold migration.
> ------------------------------
> *From:* Karera Tony <tonykarera at gmail.com>
> *Sent:* 01 September 2023 10:13
> *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
> *Subject:* Live migration error
>
>
> * CAUTION: This email originates from outside THG *
> ------------------------------
> Hello Team,
>
> I am trying to migrate instances from one host to another but I am getting
> this error.
>
> *Error: *Failed to live migrate instance to host "compute1". Details
> <http://10.10.13.31/admin/instances/#message_details>
> Migration pre-check error: Unacceptable CPU info: CPU doesn't have
> compatibility. 0 Refer to
> http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult
> (HTTP 400) (Request-ID: req-9dfdfe2e-70fa-481a-bd3d-c2c76a6e93da)
>
> Any idea on how to fix this?
>
> Regards
>
> Tony Karera
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/9e3df264/attachment.htm>

From christian.rohmann at inovex.de  Fri Sep  1 13:23:36 2023
From: christian.rohmann at inovex.de (Christian Rohmann)
Date: Fri, 1 Sep 2023 15:23:36 +0200
Subject: [SDK][CLI][API][OpenAPI] Machine readable OpenStack API spec -
 time to do a next step?
In-Reply-To: <30B316F0-81E3-417A-9A2C-87A31472D78C@gmail.com>
References: <30B316F0-81E3-417A-9A2C-87A31472D78C@gmail.com>
Message-ID: <949236db-e35f-4fae-8570-3dd331c7c0c7@inovex.de>

On 31.08.23 16:39, Artem Goncharov wrote:
> Once we have specs for the commands code generators can be updated to 
> consume this data and produce much better code. BTW, I have now also a 
> prototype of the new CLI written with Rust and this is a hypersonic 
> bullet compared to the current OSC. But please do not push me more on 
> that, it is still in a very early stages and depends heavily on the 
> available specs. I can only say that it is now designed in the way 
> that every API call can have a thin CLI coverage just by providing a 
> spec, when additional logic is desired - surely will require human 
> implementation.
> Code generators in the pipe: OSC, AnsibleModules, RustSDK 
> (sync/async), RustCLI. Next thing that are on the radar: gopher cloud, 
> terraform modules, async python sdk, JS SDK(?)
>
> If all of that gets executed properly and with some community traction 
> we can all have following things covered:
>
> - improve standardisation of OpenStack internals and externals: glance 
> and nova (at least those 2) are already using jsonschema internally in 
> different areas to describe requests/responses. Why not to make this 
> standard reaching the service consumers?
> - getting rid of api-ref work by updating our sphinx machinery to 
> consume our customised specs and produce nice docs matching the reality
> - sharing specs between teams to improve interface (not like currently 
> we need to read the api-ref with tons of bugs plus source code to 
> understand how to cover new feature in service X). Maybe even a 
> central repo with the specs per release.
> - there are plenty of code generators and server bindings for OpenAPI 
> specs so that we can potentially align frameworks used by different 
> teams to maintain less
> - less work for all of us who needs services talking to each other 
> (not immediately right now, but once the code is switched on consuming 
> specs)
> - request verification already on the client side not waiting for the 
> response
> - finally show something to customers often annoying asking ?where are 
> your openapi specs? (no offence here ;-))?
>
> I know it is a long message. But I am pretty excited with the progress 
> and would like to hear community opinions. For the more detailed 
> discussion consider this as a pre-announcement of the topic for PTG in 
> sdk/cli slots.


You have every reason to be excited - this sounds simply awesome!

I am a huge fan of OpenStackSDK and Gophercloud and the progress of 
aligning the contact surface to OpenStack APIs. Moving away from all the 
individual clients and different usage patterns ...
But your new goals bring things to a whole new level! This is how a 
modern API landscape should look like! Validated and standardized 
schemas + code auto-generation for all sorts of API clients!


Let's go!


Christian




From smooney at redhat.com  Fri Sep  1 13:41:53 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Fri, 01 Sep 2023 14:41:53 +0100
Subject: [SDK][CLI][API][OpenAPI] Machine readable OpenStack API spec -
 time to do a next step?
In-Reply-To: <971BC87A-5D2F-41E2-88CE-2F91E009D8DB@gmail.com>
References: <30B316F0-81E3-417A-9A2C-87A31472D78C@gmail.com>
 <CAHmFs2U+4dPDfCzxiN14+1WOdE+q2yiBHN2D_9P-0s1BiYPAxg@mail.gmail.com>
 <971BC87A-5D2F-41E2-88CE-2F91E009D8DB@gmail.com>
Message-ID: <0e1f14eb7aa0a8a24a9cc3e95bc352e6c1b9f1f9.camel@redhat.com>

On Thu, 2023-08-31 at 18:36 +0200, Artem Goncharov wrote:
> > 
> > Just an fyi we have jsonschema schmas stored in python dicts for every
> > api in nova
> > https://github.com/openstack/nova/blob/4490c8bc8461a56a96cdaa08020c9e25ebe8f087/nova/api/openstack/compute/schemas/migrate_server.py#L38-L74
> > 
> > we use them in our api tests with eh API scamples which are use both
> > as test and to generate docs
> > https://github.com/openstack/nova/tree/master/doc/api_samples/server-migrations
> > 
> > every time we make an api change we add an api sample and add a secma
> > for that micorversion.
> > 
> > These schemas are also use in the api to validate the requests
> > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrate_server.py#L84-L90
> > 
> > so a lot of the data (boht on the spec? side an confromance side)
> > exits but not in a form that is directly? usabel to export openapi
> > formated documents.
> 
> 
> Thanks Sean, I know that and because of that I mentioned that nova is already using jsonschema. That is more or less
> exactly the point that I want to have a discussion on making this standard by the projects and do this generally with
> the openapi spec instead of bunch of unconnected schemas so that our own lives become hopefully easier.
ya i wanted to highlight that for you and others to see how they can and are currently used.
if we were to standatise this acroos services what i would want to see is the exesitign schemas ported to openapi schema
files which we would then import and uses for our validation.

that is a non trivaial amount of work but a the end of the process we woudl have a set of schma files that could be used
to generate client.

we coudld also add a midelware to oslo mideelware that would optionally be able to enumarate the schemas and server them
form the rest api if loaded.

im not against proting to a well know standard provided we do not loose any fo the test coverage we or validation
capablities we have today as a result.

in nova the schmas benifit us today by narrowing the domain of check we need to preform in the python code directly
i.e. we know if you get to the live_migrate handeler in the nova api that the body is syntacticaly valid
due to the schema vlaidation and that you have permissiosn to perform the operators due to the keystoen auth and policy
checks that have already been done.

that means we only need to validate the semantic i.e. does the instance you asked us to migrate exist? is it in a
migratble state ectra. the schemas get rid of a lot of boilerplate in that regard so i think it would be useful for
other too. and if other project were to add schmea validation today it would make sense ot align to a standard rather
then inventing there own or copyting hte nova code. the nova code works but its kindof our own thign even if it is
jasonschma based so it requires more knowledge to extend and uses then following a standard.

> 



From smooney at redhat.com  Fri Sep  1 14:05:34 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Fri, 01 Sep 2023 15:05:34 +0100
Subject: Live migration error
In-Reply-To: <CA+69TL142aYHGHJNYKMAUf2SM+nF-9epUyrDOUfiOLyCdKP30Q@mail.gmail.com>
References: <CA+69TL2=+mO-kk8AGgPrER2tm9rtA8UVO-_D1Wo82uHJB6D0jw@mail.gmail.com>
 <LO2P265MB57732DE42D150BA2CF76F5F49AE4A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CA+69TL142aYHGHJNYKMAUf2SM+nF-9epUyrDOUfiOLyCdKP30Q@mail.gmail.com>
Message-ID: <b8a8fed1837f867ccd173eea607de91ed139b05a.camel@redhat.com>

On Fri, 2023-09-01 at 14:56 +0200, Karera Tony wrote:
> Hello Danny,
> 
> Thanks for the feedback.
> 
> use a lowest common denominator cpu_model : Does this mean changing the
> servers ?

it means tha tif you have a mix of cpus in the deployment you shoudl hardcod
to the older of the diffent cpu models i.e skylake or whatever it may be in your case.

https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cpu_models

[libvirt]
cpu_mode=custom
cpu_models=skylake

in more recent release we replaced the older cpu_model with cpu_models with is a comma sperated
list of models in prefernce order. i.e. nova will use the first cpu_modle in the list that work
on the current host. not that while this give extra flexiblity it vs just using the oldest cpu model
it does limit the set of hosts you can migrate too but means you can have better perfromance so its
a tradeoff. performance vs portablity.

the error you mentioned can also be caused by micorocode updates.
intel remove TSX and MPX i beilve in the last 2 years form come of there cpus
that breaks live migration if a vm was create with access to that cpu instruction

the only way to resolve that is to cold migrate the guest.
i.e. if a vm is currently booted with cpu_model X it cannot be modifed while the guest is running
so you either need to update the config option and reboot all the vms or more particlaly update the config
and then cold migrate them which will allow you to move the instnace(your orginal goal) while allowing
the new cpu model to take effect.

novas default for the cpu model when not set is with our default cpu_mode is host_model
meaning whatever model best matches the current hosts cpu.

that is the correct default in general but if you have mixed cpu generatiosn in your cloud its not ideal.

hopefuly that helps

> 
> Regards
> 
> Tony Karera
> 
> 
> 
> 
> On Fri, Sep 1, 2023 at 12:37?PM Danny Webb <Danny.Webb at thehutgroup.com>
> wrote:
> 
> > It means that you have CPUs with incompatible flags or you've got
> > differing kernel versions that expose different flags or you've got
> > differing libvirt versions that expose different flags.? You either need to
> > use a lowest common denominator cpu_model or do a cold migration.
> > ------------------------------
> > *From:* Karera Tony <tonykarera at gmail.com>
> > *Sent:* 01 September 2023 10:13
> > *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
> > *Subject:* Live migration error
> > 
> > 
> > * CAUTION: This email originates from outside THG *
> > ------------------------------
> > Hello Team,
> > 
> > I am trying to migrate instances from one host to another but I am getting
> > this error.
> > 
> > *Error: *Failed to live migrate instance to host "compute1". Details
> > <http://10.10.13.31/admin/instances/#message_details>
> > Migration pre-check error: Unacceptable CPU info: CPU doesn't have
> > compatibility. 0 Refer to
> > http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult
> > (HTTP 400) (Request-ID: req-9dfdfe2e-70fa-481a-bd3d-c2c76a6e93da)
> > 
> > Any idea on how to fix this?
> > 
> > Regards
> > 
> > Tony Karera
> > 
> > 
> > 



From elod.illes at est.tech  Fri Sep  1 15:30:37 2023
From: elod.illes at est.tech (=?utf-8?B?RWzDtWQgSWxsw6lz?=)
Date: Fri, 1 Sep 2023 15:30:37 +0000
Subject: [release] Release countdown for week R-4, Sep 04-08
Message-ID: <VI1P18901MB07519FFC92B4A93090D62541FFE4A@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>

Development Focus
-----------------

We just passed feature freeze! Until release branches are cut, you
should stop accepting featureful changes to deliverables following the
cycle-with-rc release model, or to libraries. Exceptions should be
discussed on separate threads on the mailing-list, and feature freeze
exceptions approved by the team's PTL.

Focus should be on finding and fixing release-critical bugs, so that
release candidates and final versions of the 2023.2 Bobcat deliverables
can be proposed, well ahead of the final 2023.2 Bobcat release date.

General Information
-------------------

We are still finishing up processing a few release requests, but the
2023.2 Bobcat release requirements are now frozen. If new library releases
are needed to fix release-critical bugs in 2023.2 Bobcat, you must request
a Requirements Freeze Exception (RFE) from the requirements team before we
can do a new release to avoid having something released in 2023.2 Bobcat
that is not actually usable. This is done by posting to the
openstack-discuss mailing list with a subject line similar to:

        [$PROJECT][requirements] RFE requested for $PROJECT_LIB

Include justification/reasoning for why a RFE is needed for this lib.
If/when the requirements team OKs the post-freeze update, we can then
process a new release.

A soft String freeze is now in effect, in order to let the I18N team do the
translation work in good conditions. In Horizon and the various dashboard
plugins, you should stop accepting changes that modify user-visible
strings. Exceptions should be discussed on the mailing-list. By
September 28th, 2023 this will become a hard string freeze, with no changes
in user-visible strings allowed.

Actions
-------

stable/2023.2 branches should be created soon for all not-already-branched
libraries. You should expect 2-3 changes to be proposed for each: a
.gitreview update, a reno update (skipped for projects not using reno),
and a tox.ini constraints URL update. Please review those in priority
so that the branch can be functional ASAP.

The Prelude section of reno release notes is rendered as the top level
overview for the release. Any important overall messaging for 2023.2 Bobcat
changes should be added there to make sure the consumers of your release
notes see them.


Upcoming Deadlines & Dates
--------------------------

RC1 deadline: September 14th, 2023 (R-3 week)
Final RC deadline: September 28th, 2023 (R-1 week)
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/752de17f/attachment-0001.htm>

From artem.goncharov at gmail.com  Fri Sep  1 17:14:12 2023
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Fri, 1 Sep 2023 19:14:12 +0200
Subject: [SDK][CLI][API][OpenAPI] Machine readable OpenStack API spec -
 time to do a next step?
In-Reply-To: <0e1f14eb7aa0a8a24a9cc3e95bc352e6c1b9f1f9.camel@redhat.com>
References: <30B316F0-81E3-417A-9A2C-87A31472D78C@gmail.com>
 <CAHmFs2U+4dPDfCzxiN14+1WOdE+q2yiBHN2D_9P-0s1BiYPAxg@mail.gmail.com>
 <971BC87A-5D2F-41E2-88CE-2F91E009D8DB@gmail.com>
 <0e1f14eb7aa0a8a24a9cc3e95bc352e6c1b9f1f9.camel@redhat.com>
Message-ID: <CAMdUkEbjwZ-nWcZXb+HzUFZT6nrjk7PbGxDrTVz3M_51UfMteA@mail.gmail.com>

On Fri, Sep 1, 2023, 15:42 <smooney at redhat.com> wrote:

> On Thu, 2023-08-31 at 18:36 +0200, Artem Goncharov wrote:
> > >
> > > Just an fyi we have jsonschema schmas stored in python dicts for every
> > > api in nova
> > >
> https://github.com/openstack/nova/blob/4490c8bc8461a56a96cdaa08020c9e25ebe8f087/nova/api/openstack/compute/schemas/migrate_server.py#L38-L74
> > >
> > > we use them in our api tests with eh API scamples which are use both
> > > as test and to generate docs
> > >
> https://github.com/openstack/nova/tree/master/doc/api_samples/server-migrations
> > >
> > > every time we make an api change we add an api sample and add a secma
> > > for that micorversion.
> > >
> > > These schemas are also use in the api to validate the requests
> > >
> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrate_server.py#L84-L90
> > >
> > > so a lot of the data (boht on the spec  side an confromance side)
> > > exits but not in a form that is directly  usabel to export openapi
> > > formated documents.
> >
> >
> > Thanks Sean, I know that and because of that I mentioned that nova is
> already using jsonschema. That is more or less
> > exactly the point that I want to have a discussion on making this
> standard by the projects and do this generally with
> > the openapi spec instead of bunch of unconnected schemas so that our own
> lives become hopefully easier.
> ya i wanted to highlight that for you and others to see how they can and
> are currently used.
> if we were to standatise this acroos services what i would want to see is
> the exesitign schemas ported to openapi schema
> files which we would then import and uses for our validation.
>

Actually I have done in my poc nearly that: taken schema (as example, not
literally) from nova code and integrated it into the spec. Surely it would
be possible as you suggested to take schemas from the current code and
construct them into the spec while we learn on how to have our middleware
to locate them from the overall spec.

Generally openapi helps us (from 3.1) not to loose info, but vice versa
extend and combine schemas into a full description of the operation how
consumer is supposed to use it (what is the url, what are the parameters,
what is the response(s)) with descriptions for each of those elements that
are used for rendering docs and helpstrings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/201bda94/attachment.htm>

From jahns.jay at heb.com  Fri Sep  1 18:59:02 2023
From: jahns.jay at heb.com (Jahns, Jay)
Date: Fri, 1 Sep 2023 18:59:02 +0000
Subject: [cinder] Map Availability Zone to Volume Type
Message-ID: <SN6PR04MB39824478449E0EC18A0D08E4F8E4A@SN6PR04MB3982.namprd04.prod.outlook.com>

Hi,

We have a multi-AZ environment where we launch instances with bootable volumes. When we specify AZ, we need to have a specific volume type in that AZ selected to launch to. Right now, the __DEFAULT__ volume type is used.

Normally, that would work, since there is 1 backend in each AZ; however, we need to be able to use the key/value RESKEY:availability_zones to pin a volume type to an AZ, so we can use specific key/values in creating the volume.

It is 2 separate backends in the environment.

I see this bug:
https://bugs.launchpad.net/cinder/+bug/1999706

And this change:
https://review.opendev.org/c/openstack/cinder/+/868539

Is there anything we can do to help expedite adding this functionality? It seems that it was supposed to already be in.

Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230901/b5cc608f/attachment.htm>

From roger.riverac at gmail.com  Sat Sep  2 15:42:45 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Sat, 2 Sep 2023 11:42:45 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
Message-ID: <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>

Hello,

We have deployed an openstack-ansible cluster to test it on_metal with OVN
and defined *dedicated gateway hosts* connecting to the external network
with the *network-gateway_hosts* host group. Unfortunately, we are not able
to connect to the external/provider networks. It seems that traffic wants
to reach external networks via the hypervisor nodes and not the gateway
hosts.

Any suggestions on changes needed to our configuration will be highly
appreciated.

Environment:
-Openstack Antelope
-Ubuntu 22 on all hosts
-3 infra hosts - 1xNIC (ens1)
-2 compute hosts - 1xNIC (ens1)
-2 gateway hosts - 2xNIC (ens1 internal, ens2 external)
-No linux bridges are created.

The gateway hosts are the only ones physically connected to the external
network via physical interface ens2. Therefore, we need all external
provider network traffic to traverse via these gateway hosts.

Tenant networks work fine and VMs can talk to each other. However, when a
VM is spawned with a floating IP to the external network, they are unable
to reach the outside network.

Relevant content from openstack-ansible configuration files:


=.=.=.=.=.=.=.=
openstack_user_config.yml
=.=.=.=.=.=.=.=
```
...
provider_networks:
    - network:
        container_bridge: "br-mgmt"
        container_type: "veth"
        container_interface: "ens1"
        ip_from_q: "management"
        type: "raw"
        group_binds:
          - all_containers
          - hosts
        is_management_address: true
    - network:
        container_bridge: "br-vxlan"
        container_type: "veth"
        container_interface: "ens1"
        ip_from_q: "tunnel"
        #type: "vxlan"
        type: "geneve"
        range: "1:1000"
        net_name: "geneve"
        group_binds:
          - neutron_ovn_controller
    - network:
        container_bridge: "br-flat"
        container_type: "veth"
        container_interface: "ens1"
        type: "flat"
        net_name: "flat"
        group_binds:
          - neutron_ovn_controller
    - network:
        container_bridge: "br-vlan"
        container_type: "veth"
        container_interface: "ens1"
        type: "vlan"
        range: "101:300,401:500"
        net_name: "vlan"
        group_binds:
          - neutron_ovn_controller
    - network:
        container_bridge: "br-storage"
        container_type: "veth"
        container_interface: "ens1"
        ip_from_q: "storage"
        type: "raw"
        group_binds:
          - glance_api
          - cinder_api
          - cinder_volume
          - nova_compute

...

compute-infra_hosts:
  inf1:
    ip: 172.16.0.1
  inf2:
    ip: 172.16.0.2
  inf3:
    ip: 172.16.0.3

compute_hosts:
  cmp4:
    ip: 172.16.0.21
  cmp3:
    ip: 172.16.0.22

network_hosts:
  inf1:
    ip: 172.16.0.1
  inf2:
    ip: 172.16.0.2
  inf3:
    ip: 172.16.0.3

network-gateway_hosts:
  net1:
    ip: 172.16.0.31
  net2:
    ip: 172.16.0.32

```


=.=.=.=.=.=.=.=
user_variables.yml
=.=.=.=.=.=.=.=
```
---
debug: false
install_method: source
rabbitmq_use_ssl: False
haproxy_use_keepalived: False
...
neutron_plugin_type: ml2.ovn
neutron_plugin_base:
  - neutron.services.ovn_l3.plugin.OVNL3RouterPlugin

neutron_ml2_drivers_type: geneve,vlan,flat
neutron_ml2_conf_ini_overrides:
  ml2:
    tenant_network_types: geneve

...
```

=.=.=.=.=.=.=.=
env.d/neutron.yml
=.=.=.=.=.=.=.=
```
component_skel:
  neutron_ovn_controller:
    belongs_to:
      - neutron_all
  neutron_ovn_northd:
    belongs_to:
      - neutron_all

container_skel:
  neutron_agents_container:
    contains: {}
  properties:
    is_metal: true
  neutron_ovn_northd_container:
    belongs_to:
      - network_containers
    contains:
      - neutron_ovn_northd

```

=.=.=.=.=.=.=.=
env.d/nova.yml
=.=.=.=.=.=.=.=
```
component_skel:
  nova_compute_container:
    belongs_to:
      - compute_containers
      - kvm-compute_containers
      - lxd-compute_containers
      - qemu-compute_containers
    contains:
      - neutron_ovn_controller
      - nova_compute
    properties:
      is_metal: true
```

=.=.=.=.=.=.=.=
group_vars/network_hosts
=.=.=.=.=.=.=.=
```
openstack_host_specific_kernel_modules:
  - name: "openvswitch"
    pattern: "CONFIG_OPENVSWITCH"
```

The nodes layout is like this:

 [image: image.png]


Any guidance on what we have wrong or how to improve this configuration
will be appreciated. We need to make external traffic for VMs to go out via
the gateway nodes and not the compute/hypervisor nodes.

Thank you.

Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230902/57af7c56/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 16574 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230902/57af7c56/attachment-0001.png>

From noonedeadpunk at gmail.com  Sat Sep  2 16:08:23 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Sat, 2 Sep 2023 18:08:23 +0200
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
Message-ID: <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>

Hi,

I think this is known issue which should be fixed with the following patch:
https://review.opendev.org/c/openstack/openstack-ansible/+/892540

In the meanwhile you should be able to workaround the issue by creating
/etc/openstack_deploy/env.d/nova.yml file with following content:

nova_compute_container:
    belongs_to:
      - compute_containers
      - kvm-compute_containers
      - qemu-compute_containers
    contains:
      - neutron_sriov_nic_agent
      - neutron_ovn_controller
      - nova_compute
    properties:
      is_metal: true

You might also need to remove computes from the inventory using
/opt/openstack-ansible/scripts/inventory-manage.py -r cmp03

They will be re-added next time running openstack-ansible or
dynamic-inventory.py. Removing them is needed to ensure that they're not
part of ovn-gateway related group.
You might also need to stop ovn-gateway service on these computes manually,
but I'm not sure 100% about that.

On Sat, Sep 2, 2023, 17:47 Roger Rivera <roger.riverac at gmail.com> wrote:

> Hello,
>
> We have deployed an openstack-ansible cluster to test it on_metal with
> OVN and defined *dedicated gateway hosts* connecting to the external
> network with the *network-gateway_hosts* host group. Unfortunately, we
> are not able to connect to the external/provider networks. It seems that
> traffic wants to reach external networks via the hypervisor nodes and not
> the gateway hosts.
>
> Any suggestions on changes needed to our configuration will be highly
> appreciated.
>
> Environment:
> -Openstack Antelope
> -Ubuntu 22 on all hosts
> -3 infra hosts - 1xNIC (ens1)
> -2 compute hosts - 1xNIC (ens1)
> -2 gateway hosts - 2xNIC (ens1 internal, ens2 external)
> -No linux bridges are created.
>
> The gateway hosts are the only ones physically connected to the external
> network via physical interface ens2. Therefore, we need all external
> provider network traffic to traverse via these gateway hosts.
>
> Tenant networks work fine and VMs can talk to each other. However, when a
> VM is spawned with a floating IP to the external network, they are unable
> to reach the outside network.
>
> Relevant content from openstack-ansible configuration files:
>
>
> =.=.=.=.=.=.=.=
> openstack_user_config.yml
> =.=.=.=.=.=.=.=
> ```
> ...
> provider_networks:
>     - network:
>         container_bridge: "br-mgmt"
>         container_type: "veth"
>         container_interface: "ens1"
>         ip_from_q: "management"
>         type: "raw"
>         group_binds:
>           - all_containers
>           - hosts
>         is_management_address: true
>     - network:
>         container_bridge: "br-vxlan"
>         container_type: "veth"
>         container_interface: "ens1"
>         ip_from_q: "tunnel"
>         #type: "vxlan"
>         type: "geneve"
>         range: "1:1000"
>         net_name: "geneve"
>         group_binds:
>           - neutron_ovn_controller
>     - network:
>         container_bridge: "br-flat"
>         container_type: "veth"
>         container_interface: "ens1"
>         type: "flat"
>         net_name: "flat"
>         group_binds:
>           - neutron_ovn_controller
>     - network:
>         container_bridge: "br-vlan"
>         container_type: "veth"
>         container_interface: "ens1"
>         type: "vlan"
>         range: "101:300,401:500"
>         net_name: "vlan"
>         group_binds:
>           - neutron_ovn_controller
>     - network:
>         container_bridge: "br-storage"
>         container_type: "veth"
>         container_interface: "ens1"
>         ip_from_q: "storage"
>         type: "raw"
>         group_binds:
>           - glance_api
>           - cinder_api
>           - cinder_volume
>           - nova_compute
>
> ...
>
> compute-infra_hosts:
>   inf1:
>     ip: 172.16.0.1
>   inf2:
>     ip: 172.16.0.2
>   inf3:
>     ip: 172.16.0.3
>
> compute_hosts:
>   cmp4:
>     ip: 172.16.0.21
>   cmp3:
>     ip: 172.16.0.22
>
> network_hosts:
>   inf1:
>     ip: 172.16.0.1
>   inf2:
>     ip: 172.16.0.2
>   inf3:
>     ip: 172.16.0.3
>
> network-gateway_hosts:
>   net1:
>     ip: 172.16.0.31
>   net2:
>     ip: 172.16.0.32
>
> ```
>
>
> =.=.=.=.=.=.=.=
> user_variables.yml
> =.=.=.=.=.=.=.=
> ```
> ---
> debug: false
> install_method: source
> rabbitmq_use_ssl: False
> haproxy_use_keepalived: False
> ...
> neutron_plugin_type: ml2.ovn
> neutron_plugin_base:
>   - neutron.services.ovn_l3.plugin.OVNL3RouterPlugin
>
> neutron_ml2_drivers_type: geneve,vlan,flat
> neutron_ml2_conf_ini_overrides:
>   ml2:
>     tenant_network_types: geneve
>
> ...
> ```
>
> =.=.=.=.=.=.=.=
> env.d/neutron.yml
> =.=.=.=.=.=.=.=
> ```
> component_skel:
>   neutron_ovn_controller:
>     belongs_to:
>       - neutron_all
>   neutron_ovn_northd:
>     belongs_to:
>       - neutron_all
>
> container_skel:
>   neutron_agents_container:
>     contains: {}
>   properties:
>     is_metal: true
>   neutron_ovn_northd_container:
>     belongs_to:
>       - network_containers
>     contains:
>       - neutron_ovn_northd
>
> ```
>
> =.=.=.=.=.=.=.=
> env.d/nova.yml
> =.=.=.=.=.=.=.=
> ```
> component_skel:
>   nova_compute_container:
>     belongs_to:
>       - compute_containers
>       - kvm-compute_containers
>       - lxd-compute_containers
>       - qemu-compute_containers
>     contains:
>       - neutron_ovn_controller
>       - nova_compute
>     properties:
>       is_metal: true
> ```
>
> =.=.=.=.=.=.=.=
> group_vars/network_hosts
> =.=.=.=.=.=.=.=
> ```
> openstack_host_specific_kernel_modules:
>   - name: "openvswitch"
>     pattern: "CONFIG_OPENVSWITCH"
> ```
>
> The nodes layout is like this:
>
>  [image: image.png]
>
>
> Any guidance on what we have wrong or how to improve this configuration
> will be appreciated. We need to make external traffic for VMs to go out via
> the gateway nodes and not the compute/hypervisor nodes.
>
> Thank you.
>
> Roger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230902/cbdcfe1a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 16574 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230902/cbdcfe1a/attachment-0001.png>

From egarciar at redhat.com  Sun Sep  3 23:26:47 2023
From: egarciar at redhat.com (Elvira Garcia Ruiz)
Date: Mon, 4 Sep 2023 01:26:47 +0200
Subject: [neutron] Bug Deputy Report August 28 - September 3
Message-ID: <CALvQLqfC=QmSTvrhjUTkJmBke3eNi_w7jym7hXJJ8Vw2JnQFyw@mail.gmail.com>

Hi! I was the bug deputy last week. Find the summary below:

High
------
- https://bugs.launchpad.net/neutron/+bug/2033508 -  [HA]
"neutron-dynamic-routing" HA unittest failing
Unassigned

- https://bugs.launchpad.net/neutron/+bug/2033493 - [ndr] Unit tests
failing due to a missing patch, still unreleased, in Neutron
Fix proposed: https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/893189
Assigned to Rodolfo Alonso Hernandez

- https://bugs.launchpad.net/neutron/+bug/2033305 -  OVN metadata
agent keeps restarting
Assigned to Miro Tomaska
Fix proposed: https://review.opendev.org/c/openstack/neutron/+/890986

- https://bugs.launchpad.net/neutron/+bug/2033556 -  Documentation for
DNS integration is incomplete
Assigned to Dr. Jens Harbott

- https://bugs.launchpad.net/neutron/+bug/2033887 -  [OVN][Trunk] The
cold migration process is broken since patch 882581
Assigned to Rodolfo
Fix proposed: https://review.opendev.org/c/openstack/neutron/+/893447
+ backports

- https://bugs.launchpad.net/neutron/+bug/2033752 -
test_reboot_server_hard fails with AssertionError: time.struct_time()
not greater than time.struct_time()
This is affecting us but the failure is on Nova.
Yatin will monitor this.

- https://bugs.launchpad.net/neutron/+bug/2033932 -  Add support for
OVN MAC_Binding aging
Fix proposed: https://review.opendev.org/c/openstack/neutron/+/893575
Assigned to Terry

Medium
----------
- https://bugs.launchpad.net/neutron/+bug/2033281 -  [OVN]
ovn_hash_ring table cleanup
In progress. Fix merged on master:
https://review.opendev.org/c/openstack/neutron/+/893030
Assigned to Lucas

Low
------
- https://bugs.launchpad.net/neutron/+bug/2033651 -  [fullstack]
Reduce the CI job time
Unassigned

Incomplete
---------------
- https://bugs.launchpad.net/neutron/+bug/2033293 -  dns integration
saying plugin does not match requirements
Unassigned
Left a comment since I think this might not be a bug. Also contacted
mlavalle to get more information.

Undecided
---------------
https://bugs.launchpad.net/neutron/+bug/2033683 -
openvswitch.agent.ovs_neutron_agent fails to Cmd: ['iptables-restore',
'-n']
I?m not very sure about how to confirm this one.
Unassigned

Kind regards,
Elvira



From hberaud at redhat.com  Mon Sep  4 09:07:25 2023
From: hberaud at redhat.com (Herve Beraud)
Date: Mon, 4 Sep 2023 11:07:25 +0200
Subject: [PTL][release] 2023.2 Bobcat Cycle Highlights
Message-ID: <CAFDq9gVPFBpyB1s87k5Ff6_RsCXPZGjNkv6Ke7=dLVnZpx9Xhw@mail.gmail.com>

Hi,

This is a reminder that Cycle highlights need to be added to deliverable
yamls so that they can be included in release marketing preparations. (See
the details about how to add them at the project team guide [1])

Note that the deadline was the Feature Freeze date in previous cycles,
but due to requests of PTLs it was decided to postpone one week in the
future (to R-4 week). This is better for PTLs as they are usually very
busy around Feature Freeze, on the other hand gives less time to
marketing team to process the highlights.

[1] https://docs.openstack.org/project-team-guide/release-management.html#
cycle-highlights

Thanks,

-- 
Herv? Beraud
Senior Software Engineer at Red Hat
irc: hberaud
https://github.com/4383/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230904/9782f044/attachment.htm>

From thierry at openstack.org  Mon Sep  4 10:28:21 2023
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 4 Sep 2023 12:28:21 +0200
Subject: [largescale-sig] Next meeting: Sept 6, 15utc
Message-ID: <94831ce5-03e2-b08c-0c78-4b000be7a681@openstack.org>

Hi everyone,

The Large Scale SIG is back after the northern hemisphere summer break 
and will be meeting this Wednesday in #openstack-operators on OFTC IRC, 
at 15UTC, our EU+US-friendly time. I will be chairing.

You can doublecheck how that UTC time translates locally at:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230906T15

Feel free to add topics to the agenda:
https://etherpad.opendev.org/p/large-scale-sig-meeting

Regards,

-- 
Thierry Carrez


From tonykarera at gmail.com  Mon Sep  4 10:59:59 2023
From: tonykarera at gmail.com (Karera Tony)
Date: Mon, 4 Sep 2023 12:59:59 +0200
Subject: Live migration error
In-Reply-To: <b8a8fed1837f867ccd173eea607de91ed139b05a.camel@redhat.com>
References: <CA+69TL2=+mO-kk8AGgPrER2tm9rtA8UVO-_D1Wo82uHJB6D0jw@mail.gmail.com>
 <LO2P265MB57732DE42D150BA2CF76F5F49AE4A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CA+69TL142aYHGHJNYKMAUf2SM+nF-9epUyrDOUfiOLyCdKP30Q@mail.gmail.com>
 <b8a8fed1837f867ccd173eea607de91ed139b05a.camel@redhat.com>
Message-ID: <CA+69TL2ZqN-ErtQD1JHkQBAjeA_-DHo0OU8sXmm2s+btxQApEA@mail.gmail.com>

Hello Danny,

I am actually using Broadwell-noTSX-IBRS on all the servers but I have seen
that some flags are not there in the older servers.

The flags below to be specific.

hwp hwp_act_window hwp_pkg_req

Regards

Tony Karera




On Fri, Sep 1, 2023 at 4:05?PM <smooney at redhat.com> wrote:

> On Fri, 2023-09-01 at 14:56 +0200, Karera Tony wrote:
> > Hello Danny,
> >
> > Thanks for the feedback.
> >
> > use a lowest common denominator cpu_model : Does this mean changing the
> > servers ?
>
> it means tha tif you have a mix of cpus in the deployment you shoudl
> hardcod
> to the older of the diffent cpu models i.e skylake or whatever it may be
> in your case.
>
>
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cpu_models
>
> [libvirt]
> cpu_mode=custom
> cpu_models=skylake
>
> in more recent release we replaced the older cpu_model with cpu_models
> with is a comma sperated
> list of models in prefernce order. i.e. nova will use the first cpu_modle
> in the list that work
> on the current host. not that while this give extra flexiblity it vs just
> using the oldest cpu model
> it does limit the set of hosts you can migrate too but means you can have
> better perfromance so its
> a tradeoff. performance vs portablity.
>
> the error you mentioned can also be caused by micorocode updates.
> intel remove TSX and MPX i beilve in the last 2 years form come of there
> cpus
> that breaks live migration if a vm was create with access to that cpu
> instruction
>
> the only way to resolve that is to cold migrate the guest.
> i.e. if a vm is currently booted with cpu_model X it cannot be modifed
> while the guest is running
> so you either need to update the config option and reboot all the vms or
> more particlaly update the config
> and then cold migrate them which will allow you to move the instnace(your
> orginal goal) while allowing
> the new cpu model to take effect.
>
> novas default for the cpu model when not set is with our default cpu_mode
> is host_model
> meaning whatever model best matches the current hosts cpu.
>
> that is the correct default in general but if you have mixed cpu
> generatiosn in your cloud its not ideal.
>
> hopefuly that helps
>
> >
> > Regards
> >
> > Tony Karera
> >
> >
> >
> >
> > On Fri, Sep 1, 2023 at 12:37?PM Danny Webb <Danny.Webb at thehutgroup.com>
> > wrote:
> >
> > > It means that you have CPUs with incompatible flags or you've got
> > > differing kernel versions that expose different flags or you've got
> > > differing libvirt versions that expose different flags.  You either
> need to
> > > use a lowest common denominator cpu_model or do a cold migration.
> > > ------------------------------
> > > *From:* Karera Tony <tonykarera at gmail.com>
> > > *Sent:* 01 September 2023 10:13
> > > *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
> > > *Subject:* Live migration error
> > >
> > >
> > > * CAUTION: This email originates from outside THG *
> > > ------------------------------
> > > Hello Team,
> > >
> > > I am trying to migrate instances from one host to another but I am
> getting
> > > this error.
> > >
> > > *Error: *Failed to live migrate instance to host "compute1". Details
> > > <http://10.10.13.31/admin/instances/#message_details>
> > > Migration pre-check error: Unacceptable CPU info: CPU doesn't have
> > > compatibility. 0 Refer to
> > > http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult
> > > (HTTP 400) (Request-ID: req-9dfdfe2e-70fa-481a-bd3d-c2c76a6e93da)
> > >
> > > Any idea on how to fix this?
> > >
> > > Regards
> > >
> > > Tony Karera
> > >
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230904/b3dad336/attachment.htm>

From smooney at redhat.com  Mon Sep  4 11:25:50 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Mon, 04 Sep 2023 12:25:50 +0100
Subject: Live migration error
In-Reply-To: <CA+69TL2ZqN-ErtQD1JHkQBAjeA_-DHo0OU8sXmm2s+btxQApEA@mail.gmail.com>
References: <CA+69TL2=+mO-kk8AGgPrER2tm9rtA8UVO-_D1Wo82uHJB6D0jw@mail.gmail.com>
 <LO2P265MB57732DE42D150BA2CF76F5F49AE4A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CA+69TL142aYHGHJNYKMAUf2SM+nF-9epUyrDOUfiOLyCdKP30Q@mail.gmail.com>
 <b8a8fed1837f867ccd173eea607de91ed139b05a.camel@redhat.com>
 <CA+69TL2ZqN-ErtQD1JHkQBAjeA_-DHo0OU8sXmm2s+btxQApEA@mail.gmail.com>
Message-ID: <9a8d05595db731f00e30066ef00fc4df04d84f14.camel@redhat.com>

On Mon, 2023-09-04 at 12:59 +0200, Karera Tony wrote:
> Hello Danny,
> 
> I am actually using Broadwell-noTSX-IBRS on all the servers but I have seen
> that some flags are not there in the older servers.
> 
> The flags below to be specific.
> 
> hwp hwp_act_window hwp_pkg_req
so hwp is apprentlly intels pstate contol
based on https://unix.stackexchange.com/a/43540

i dont belive this is normally exposed to a guest but
if you are seeign differnce between hosts then that likely
means you have disabled pstates also know as "intel speedstep" on 
some of the host and not others.

> 
> Regards
> 
> Tony Karera
> 
> 
> 
> 
> On Fri, Sep 1, 2023 at 4:05?PM <smooney at redhat.com> wrote:
> 
> > On Fri, 2023-09-01 at 14:56 +0200, Karera Tony wrote:
> > > Hello Danny,
> > > 
> > > Thanks for the feedback.
> > > 
> > > use a lowest common denominator cpu_model : Does this mean changing the
> > > servers ?
> > 
> > it means tha tif you have a mix of cpus in the deployment you shoudl
> > hardcod
> > to the older of the diffent cpu models i.e skylake or whatever it may be
> > in your case.
> > 
> > 
> > https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cpu_models
> > 
> > [libvirt]
> > cpu_mode=custom
> > cpu_models=skylake
> > 
> > in more recent release we replaced the older cpu_model with cpu_models
> > with is a comma sperated
> > list of models in prefernce order. i.e. nova will use the first cpu_modle
> > in the list that work
> > on the current host. not that while this give extra flexiblity it vs just
> > using the oldest cpu model
> > it does limit the set of hosts you can migrate too but means you can have
> > better perfromance so its
> > a tradeoff. performance vs portablity.
> > 
> > the error you mentioned can also be caused by micorocode updates.
> > intel remove TSX and MPX i beilve in the last 2 years form come of there
> > cpus
> > that breaks live migration if a vm was create with access to that cpu
> > instruction
> > 
> > the only way to resolve that is to cold migrate the guest.
> > i.e. if a vm is currently booted with cpu_model X it cannot be modifed
> > while the guest is running
> > so you either need to update the config option and reboot all the vms or
> > more particlaly update the config
> > and then cold migrate them which will allow you to move the instnace(your
> > orginal goal) while allowing
> > the new cpu model to take effect.
> > 
> > novas default for the cpu model when not set is with our default cpu_mode
> > is host_model
> > meaning whatever model best matches the current hosts cpu.
> > 
> > that is the correct default in general but if you have mixed cpu
> > generatiosn in your cloud its not ideal.
> > 
> > hopefuly that helps
> > 
> > > 
> > > Regards
> > > 
> > > Tony Karera
> > > 
> > > 
> > > 
> > > 
> > > On Fri, Sep 1, 2023 at 12:37?PM Danny Webb <Danny.Webb at thehutgroup.com>
> > > wrote:
> > > 
> > > > It means that you have CPUs with incompatible flags or you've got
> > > > differing kernel versions that expose different flags or you've got
> > > > differing libvirt versions that expose different flags.? You either
> > need to
> > > > use a lowest common denominator cpu_model or do a cold migration.
> > > > ------------------------------
> > > > *From:* Karera Tony <tonykarera at gmail.com>
> > > > *Sent:* 01 September 2023 10:13
> > > > *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
> > > > *Subject:* Live migration error
> > > > 
> > > > 
> > > > * CAUTION: This email originates from outside THG *
> > > > ------------------------------
> > > > Hello Team,
> > > > 
> > > > I am trying to migrate instances from one host to another but I am
> > getting
> > > > this error.
> > > > 
> > > > *Error: *Failed to live migrate instance to host "compute1". Details
> > > > <http://10.10.13.31/admin/instances/#message_details>
> > > > Migration pre-check error: Unacceptable CPU info: CPU doesn't have
> > > > compatibility. 0 Refer to
> > > > http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult
> > > > (HTTP 400) (Request-ID: req-9dfdfe2e-70fa-481a-bd3d-c2c76a6e93da)
> > > > 
> > > > Any idea on how to fix this?
> > > > 
> > > > Regards
> > > > 
> > > > Tony Karera
> > > > 
> > > > 
> > > > 
> > 
> > 



From tonykarera at gmail.com  Mon Sep  4 12:11:37 2023
From: tonykarera at gmail.com (Karera Tony)
Date: Mon, 4 Sep 2023 14:11:37 +0200
Subject: Live migration error
In-Reply-To: <9a8d05595db731f00e30066ef00fc4df04d84f14.camel@redhat.com>
References: <CA+69TL2=+mO-kk8AGgPrER2tm9rtA8UVO-_D1Wo82uHJB6D0jw@mail.gmail.com>
 <LO2P265MB57732DE42D150BA2CF76F5F49AE4A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CA+69TL142aYHGHJNYKMAUf2SM+nF-9epUyrDOUfiOLyCdKP30Q@mail.gmail.com>
 <b8a8fed1837f867ccd173eea607de91ed139b05a.camel@redhat.com>
 <CA+69TL2ZqN-ErtQD1JHkQBAjeA_-DHo0OU8sXmm2s+btxQApEA@mail.gmail.com>
 <9a8d05595db731f00e30066ef00fc4df04d84f14.camel@redhat.com>
Message-ID: <CA+69TL3=7GwfgRgAjfxvx5q4aZCstXxtBeB2mGb9ofa0JCZmbA@mail.gmail.com>

Hello Smooney,

I can confirm that it is disabled on all the servers.

Regards

Tony Karera




On Mon, Sep 4, 2023 at 1:25?PM <smooney at redhat.com> wrote:

> On Mon, 2023-09-04 at 12:59 +0200, Karera Tony wrote:
> > Hello Danny,
> >
> > I am actually using Broadwell-noTSX-IBRS on all the servers but I have
> seen
> > that some flags are not there in the older servers.
> >
> > The flags below to be specific.
> >
> > hwp hwp_act_window hwp_pkg_req
> so hwp is apprentlly intels pstate contol
> based on https://unix.stackexchange.com/a/43540
>
> i dont belive this is normally exposed to a guest but
> if you are seeign differnce between hosts then that likely
> means you have disabled pstates also know as "intel speedstep" on
> some of the host and not others.
>
> >
> > Regards
> >
> > Tony Karera
> >
> >
> >
> >
> > On Fri, Sep 1, 2023 at 4:05?PM <smooney at redhat.com> wrote:
> >
> > > On Fri, 2023-09-01 at 14:56 +0200, Karera Tony wrote:
> > > > Hello Danny,
> > > >
> > > > Thanks for the feedback.
> > > >
> > > > use a lowest common denominator cpu_model : Does this mean changing
> the
> > > > servers ?
> > >
> > > it means tha tif you have a mix of cpus in the deployment you shoudl
> > > hardcod
> > > to the older of the diffent cpu models i.e skylake or whatever it may
> be
> > > in your case.
> > >
> > >
> > >
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cpu_models
> > >
> > > [libvirt]
> > > cpu_mode=custom
> > > cpu_models=skylake
> > >
> > > in more recent release we replaced the older cpu_model with cpu_models
> > > with is a comma sperated
> > > list of models in prefernce order. i.e. nova will use the first
> cpu_modle
> > > in the list that work
> > > on the current host. not that while this give extra flexiblity it vs
> just
> > > using the oldest cpu model
> > > it does limit the set of hosts you can migrate too but means you can
> have
> > > better perfromance so its
> > > a tradeoff. performance vs portablity.
> > >
> > > the error you mentioned can also be caused by micorocode updates.
> > > intel remove TSX and MPX i beilve in the last 2 years form come of
> there
> > > cpus
> > > that breaks live migration if a vm was create with access to that cpu
> > > instruction
> > >
> > > the only way to resolve that is to cold migrate the guest.
> > > i.e. if a vm is currently booted with cpu_model X it cannot be modifed
> > > while the guest is running
> > > so you either need to update the config option and reboot all the vms
> or
> > > more particlaly update the config
> > > and then cold migrate them which will allow you to move the
> instnace(your
> > > orginal goal) while allowing
> > > the new cpu model to take effect.
> > >
> > > novas default for the cpu model when not set is with our default
> cpu_mode
> > > is host_model
> > > meaning whatever model best matches the current hosts cpu.
> > >
> > > that is the correct default in general but if you have mixed cpu
> > > generatiosn in your cloud its not ideal.
> > >
> > > hopefuly that helps
> > >
> > > >
> > > > Regards
> > > >
> > > > Tony Karera
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Sep 1, 2023 at 12:37?PM Danny Webb <
> Danny.Webb at thehutgroup.com>
> > > > wrote:
> > > >
> > > > > It means that you have CPUs with incompatible flags or you've got
> > > > > differing kernel versions that expose different flags or you've got
> > > > > differing libvirt versions that expose different flags.  You either
> > > need to
> > > > > use a lowest common denominator cpu_model or do a cold migration.
> > > > > ------------------------------
> > > > > *From:* Karera Tony <tonykarera at gmail.com>
> > > > > *Sent:* 01 September 2023 10:13
> > > > > *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
> > > > > *Subject:* Live migration error
> > > > >
> > > > >
> > > > > * CAUTION: This email originates from outside THG *
> > > > > ------------------------------
> > > > > Hello Team,
> > > > >
> > > > > I am trying to migrate instances from one host to another but I am
> > > getting
> > > > > this error.
> > > > >
> > > > > *Error: *Failed to live migrate instance to host "compute1".
> Details
> > > > > <http://10.10.13.31/admin/instances/#message_details>
> > > > > Migration pre-check error: Unacceptable CPU info: CPU doesn't have
> > > > > compatibility. 0 Refer to
> > > > >
> http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult
> > > > > (HTTP 400) (Request-ID: req-9dfdfe2e-70fa-481a-bd3d-c2c76a6e93da)
> > > > >
> > > > > Any idea on how to fix this?
> > > > >
> > > > > Regards
> > > > >
> > > > > Tony Karera
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230904/8dcdbdf5/attachment.htm>

From jorgevisentini at gmail.com  Mon Sep  4 14:51:07 2023
From: jorgevisentini at gmail.com (Jorge Visentini)
Date: Mon, 4 Sep 2023 11:51:07 -0300
Subject: What is the difference between 4 and 8 virtual sockets to physical
 sockets?
Message-ID: <CAG=j6fpruTk5EG0dZTyL3M-ud2tCq7CBQHZiCBmbsr5sd6Z8Ow@mail.gmail.com>

Hello Team,

What is the difference between creating an instance with *4* or *8 virtual
sockets*, since the hypervisor has only *4 physical sockets*.
My question is where do sockets, cores and virtual threads fit into the
physical hardware. I think this question is not just related to Openstack,
but with any virtualization.

My hypervisor configuration is as follows:

CPU(s): 192
Online CPU(s) list: 0-191
Thread(s) per core: 2
Core(s) per socket: 24
Socket(s): 4
NUMA node(s): 4

Do you have any documentation that I can read and understand better?

That we have a nice week!
-- 
Att,
Jorge Visentini
+55 55 98432-9868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230904/c5702749/attachment.htm>

From elod.illes at est.tech  Mon Sep  4 15:26:39 2023
From: elod.illes at est.tech (=?utf-8?B?RWzDtWQgSWxsw6lz?=)
Date: Mon, 4 Sep 2023 15:26:39 +0000
Subject: [all][stable][ptl] Propose to EOL Stein series
Message-ID: <VI1P18901MB075178B60ADE8475F17D3751FFE9A@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>

Hi,

Core projects announced and deleted their stable/stein branches for some
time already. Furthermore, most of the projects, where stable/stein is
still open, have broken gates.

So, the same way as we transitioned Rocky series to End of Life [1][2],
now is the time to do the same with Stein.

I'll propose the stein-eol transition patches for the rest of the open
projects. I ask again the teams to signal their decision (with a +1 if
the team is ready for the transition). Thanks in advance!

(Please note, that the Extended Maintenance process is phasing out /
transforming soon, see details in Technical Committee's resolution [3],
which was accepted and merged in August.)

Thanks,

El?d Ill?s
irc: elodilles @ #openstack-stable / #openstack-release

[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031922.html
[2] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033386.html
[3] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230904/a124c0b6/attachment-0001.htm>

From smooney at redhat.com  Mon Sep  4 16:10:52 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Mon, 04 Sep 2023 17:10:52 +0100
Subject: What is the difference between 4 and 8 virtual sockets to
 physical sockets?
In-Reply-To: <CAG=j6fpruTk5EG0dZTyL3M-ud2tCq7CBQHZiCBmbsr5sd6Z8Ow@mail.gmail.com>
References: <CAG=j6fpruTk5EG0dZTyL3M-ud2tCq7CBQHZiCBmbsr5sd6Z8Ow@mail.gmail.com>
Message-ID: <961b08ba25c4eeffb430d3d60ef521e15e26df18.camel@redhat.com>

in general the only parameter you want to align to the physical host is the number of thread

so if the phsyical host has 2 thread per physical core then its best to also do that in the vm

we generally recommend setting the number of virutal socket equal to the number of virutal numa nodes
if the vm has no explict numa toploly then you should set sockets=1
else hw:cpu_sockets==hw:numa_nodes is our recomendation.

for windows in partcalar the default config generated is suboptimal as windows client only supprot 1-2 sockets
and windows serverver maxes out at 4 i believe.

On Mon, 2023-09-04 at 11:51 -0300, Jorge Visentini wrote:
> Hello Team,
> 
> What is the difference between creating an instance with *4* or *8 virtual
> sockets*, since the hypervisor has only *4 physical sockets*.
> My question is where do sockets, cores and virtual threads fit into the
> physical hardware. I think this question is not just related to Openstack,
> but with any virtualization.
> 
> My hypervisor configuration is as follows:
> 
> CPU(s): 192
> Online CPU(s) list: 0-191
> Thread(s) per core: 2
> Core(s) per socket: 24
> Socket(s): 4
> NUMA node(s): 4
> 
> Do you have any documentation that I can read and understand better?
> 
> That we have a nice week!



From ygk.kmr at gmail.com  Mon Sep  4 17:01:39 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Mon, 4 Sep 2023 22:31:39 +0530
Subject: Need assistance
Message-ID: <CAJreVFxU_QE7wSChy9dsARxjOB8NacD5dterGNm6THB7a1iOwA@mail.gmail.com>

Hi,

We have Yoga version setup of OSA. When a user is trying to use a certain
flavor which has some extra specs, same as that which is mentioned for an
aggregate, the vm creation is failing for the user. But I created a vm
using that same flavor and it succeeded for a test user account. When I
analyzed the logs, the nova scheduler is not filtering or checking the
individual hosts from that target aggregate in the case of that user. But
it is validating the target aggregate hosts  in the case of a test user and
able to select a host for vm creation. So what could be the reason that the
scheduler is unable to find the hosts from that aggregate in the case of
that user as opposed to that of the test user ? Is there any connection
between a project and an aggregate ?

Thanks
Kumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230904/3adf76bc/attachment.htm>

From gmann at ghanshyammann.com  Mon Sep  4 17:50:47 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 04 Sep 2023 10:50:47 -0700
Subject: [all][qa] Devstack dropping support for Ubuntu Focal
Message-ID: <18a61518602.fd2214f3355467.3969169943764214362@ghanshyammann.com>

Hello Everyone,

As you know, this release 2023.2 (bobcat) does not mandate testing the ubuntu Focal[1] and with
Nova bumped the libvirt version, focal jobs are failing. Devstack was planning to drop the Focal
support in the next cycle but we have to do it now only[2].

This email is a heads-up if you are still wondering about the Focal job failure. If your project still
running any of the jobs on focal, please plan to move to Jammy.

[1] https://governance.openstack.org/tc/reference/runtimes/2023.2.html
[2] https://review.opendev.org/c/openstack/devstack/+/885468

-gmann


From eblock at nde.ag  Mon Sep  4 18:27:58 2023
From: eblock at nde.ag (Eugen Block)
Date: Mon, 04 Sep 2023 18:27:58 +0000
Subject: Need assistance
In-Reply-To: <CAJreVFxU_QE7wSChy9dsARxjOB8NacD5dterGNm6THB7a1iOwA@mail.gmail.com>
Message-ID: <20230904182758.Horde.GouaYgjRk4uB_PKPQvkqktm@webmail.nde.ag>

I don?t mean to be rude but all your threads have the same subject  
?need assistance?. There?s no way to distinguish those threads without  
reading the mails, I recommend to read the etiquette  
[https://wiki.openstack.org/wiki/MailingListEtiquette#Subjects] and  
add a proper subject to your threads.

Zitat von Gk Gk <ygk.kmr at gmail.com>:

> Hi,
>
> We have Yoga version setup of OSA. When a user is trying to use a certain
> flavor which has some extra specs, same as that which is mentioned for an
> aggregate, the vm creation is failing for the user. But I created a vm
> using that same flavor and it succeeded for a test user account. When I
> analyzed the logs, the nova scheduler is not filtering or checking the
> individual hosts from that target aggregate in the case of that user. But
> it is validating the target aggregate hosts  in the case of a test user and
> able to select a host for vm creation. So what could be the reason that the
> scheduler is unable to find the hosts from that aggregate in the case of
> that user as opposed to that of the test user ? Is there any connection
> between a project and an aggregate ?
>
> Thanks
> Kumar





From jorgevisentini at gmail.com  Mon Sep  4 21:13:15 2023
From: jorgevisentini at gmail.com (Jorge Visentini)
Date: Mon, 4 Sep 2023 18:13:15 -0300
Subject: What is the difference between 4 and 8 virtual sockets to
 physical sockets?
In-Reply-To: <961b08ba25c4eeffb430d3d60ef521e15e26df18.camel@redhat.com>
References: <CAG=j6fpruTk5EG0dZTyL3M-ud2tCq7CBQHZiCBmbsr5sd6Z8Ow@mail.gmail.com>
 <961b08ba25c4eeffb430d3d60ef521e15e26df18.camel@redhat.com>
Message-ID: <CAG=j6fpbekqjUhc8_vuSPYfHTk_RruiJ=AJeVfXL54avHWFhrQ@mail.gmail.com>

Yes, yes, that I understand.

I know that for example if I want to use host_passthrough then I must use
cpu_sockets == numa_nodes.
*My question is more conceptual, for me to understand.*

*For example:* If I have a physical host with 1 physical processor (1
socket), can I define my instance with 2, 4, 8+ sockets? I mean, is it good
practice? Is it correct to define the instance with 1 socket and increase
the amount of socket colors?

Not sure if I could explain my question... In short, what is the
relationship between the socket, cores and virtual thread and the socket,
cores and physical thread.
PS: I'm not into the issue of passthrough or not.

Em seg., 4 de set. de 2023 ?s 13:10, <smooney at redhat.com> escreveu:

> in general the only parameter you want to align to the physical host is
> the number of thread
>
> so if the phsyical host has 2 thread per physical core then its best to
> also do that in the vm
>
> we generally recommend setting the number of virutal socket equal to the
> number of virutal numa nodes
> if the vm has no explict numa toploly then you should set sockets=1
> else hw:cpu_sockets==hw:numa_nodes is our recomendation.
>
> for windows in partcalar the default config generated is suboptimal as
> windows client only supprot 1-2 sockets
> and windows serverver maxes out at 4 i believe.
>
> On Mon, 2023-09-04 at 11:51 -0300, Jorge Visentini wrote:
> > Hello Team,
> >
> > What is the difference between creating an instance with *4* or *8
> virtual
> > sockets*, since the hypervisor has only *4 physical sockets*.
> > My question is where do sockets, cores and virtual threads fit into the
> > physical hardware. I think this question is not just related to
> Openstack,
> > but with any virtualization.
> >
> > My hypervisor configuration is as follows:
> >
> > CPU(s): 192
> > Online CPU(s) list: 0-191
> > Thread(s) per core: 2
> > Core(s) per socket: 24
> > Socket(s): 4
> > NUMA node(s): 4
> >
> > Do you have any documentation that I can read and understand better?
> >
> > That we have a nice week!
>
>

-- 
Att,
Jorge Visentini
+55 55 98432-9868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230904/2d798963/attachment-0001.htm>

From knikolla at bu.edu  Tue Sep  5 08:12:18 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Tue, 5 Sep 2023 08:12:18 +0000
Subject: [tc] Technical Committee next weekly meeting Today on September 5
Message-ID: <F63670AB-C930-40BA-82C2-4EAF8313145F@bu.edu>

Hi all,

This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday, September 5, 2023 at 1800 UTC on Zoom https://us06web.zoom.us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09

The agenda can be found at the link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions and attached below:

    ? Roll call
    ? Follow up on past action items
        ? No action items
    ? Gate health check
    ? OpenStack Elections
        ? #link https://governance.openstack.org/election/
        ? Ballots go out tomorrow and remain open until September 20.
        ? We have 6 candidates out of 4 seats for TC :)
    ? 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

From smooney at redhat.com  Tue Sep  5 08:48:52 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Tue, 05 Sep 2023 09:48:52 +0100
Subject: What is the difference between 4 and 8 virtual sockets to
 physical sockets?
In-Reply-To: <CAG=j6fpbekqjUhc8_vuSPYfHTk_RruiJ=AJeVfXL54avHWFhrQ@mail.gmail.com>
References: <CAG=j6fpruTk5EG0dZTyL3M-ud2tCq7CBQHZiCBmbsr5sd6Z8Ow@mail.gmail.com>
 <961b08ba25c4eeffb430d3d60ef521e15e26df18.camel@redhat.com>
 <CAG=j6fpbekqjUhc8_vuSPYfHTk_RruiJ=AJeVfXL54avHWFhrQ@mail.gmail.com>
Message-ID: <7549fec42f89c31896076d93285730d6d787c54a.camel@redhat.com>

On Mon, 2023-09-04 at 18:13 -0300, Jorge Visentini wrote:
> Yes, yes, that I understand.
> 
> I know that for example if I want to use host_passthrough then I must use
> cpu_sockets == numa_nodes.
no even without cpu_mode=host_passthough  you shoudl use cpu_sockets == numa_nodes.
The reason for that is that the windows and to a lesser degree linux scheduler
tends to make better schduling desicions when the numa nodes and sockets are aligned.

intel supported cluster on die since around sandybridge/ivybridge but it was not until
very recentlly with amd epic platform and the move to chiplet design that the windows
and linux kernels schdulers really got optimised to properly handel multipel numa nodes
per socket.

in the very early days fo openstack qemu/libvirt strongly prefer generating toplogies with 1
socket, 1 core and 1 thread per vcpu. that is still what we defautl to today in nova because
10+ years ago that outperformed other toplogies in some test done in a non openstack env i.e. with just libvirt/qemu

when i got involed in openstack 10 years ago the cracks were already forming in that analasy and wehn we
started to look at addign cpu pinnng and numa support the initall benchmarks we did show no benift to 1 socket per
vcpu and infact if you had hyperthread on the host it actully perfromed worse.

for legacy reason we did not change the defautl toplogy but our recomendation has been to 
1 socket per numa node and 1 thread per host thread by default 

so 8 VCPU with a normal floatign vm with no special numa toplogy shoudl be 

1 socket 2 thread and 4 cpus if the host has smt/hyperthreading enable or 
1 socket 1 threadn and 8 cpus. not 8 sockets,  1 thread and 1 cpu which is the defualt toplogy.

> *My question is more conceptual, for me to understand.*
no worries
> 
> *For example:* If I have a physical host with 1 physical processor (1
> socket), can I define my instance with 2, 4, 8+ sockets? I mean, is it good
> practice? Is it correct to define the instance with 1 socket and increase
> the amount of socket colors?

you do not need to align the virtual toplogy to the hsot toplogy in anyway.

so on a host with 1 socket and 1 thread per core and 64 cores
you can create a vm with 16 sockets and 2 thread per core and 1 core per socket

largely this wont impact performace vs
1 sockets and 1 thread per core and 32 core per socket

which woudl be our recomended toplogy.

what you are trying to do with the virtual toplogy is create a config that enabel the guest
kernel schduler to make good choices

historically kernel schduler were largely not numa aware but did consider moving a process
between socket to be very costly and as a result it avoided it.
that meant for old kernels (windows 2012 or linux (centos 6/linux 2.x era)) it was more
effeicnt to have 1 socket per vcpu

that change in the linux side many year ago adn windows a lot more recently.
now its more imporant to the scudherl to knwo about the numa toplogy and thread
topopligy. i.e. in the old model fo 1 socket per vcpu if you had hyperthreading enabld
the guest kernel would expect that it can run n process in parralle when infact
it really can only run n/2 so match the theread count to the host tread count allow
the guest kernel to make better choices.

setting thread=2 when the host has thread=1 also tends to have littel downside for what its worth.

for what its worth on the linux side its my understanding that the kernel also does som extra work per socket
that can be elimated if you use 1 socket instead of 32 but that is negligible unless your dealing
with realtime workloads where it might matter.


> 
> Not sure if I could explain my question... In short, what is the
> relationship between the socket, cores and virtual thread and the socket,
> cores and physical thread.
> PS: I'm not into the issue of passthrough or not.

yep so conceptually as a user o fopenstack you should have no awareness of the hsot platform.
specirfcaly as an unprivladged user you are not even ment to know if its libvirt/kvm or vmware
from an api prespective.

form an openstack admin point of view its in yoru interest to craft your flavors and default
images to be as power efficent as possible. the best way to acihve power effeicncy is often
to make the workload perform better so that it can idle sooner and you can take one
step in that direction by using some of your knowlage of the hardware to turn your images.

as an end user because you are not ment to knwo the toplogy of the host systems you
generally shoudl benchmark your workload but you shoudl not really expect a large delta
regardless of what you choose today.


openstack is not a virtualisation plathform, its a cloud plathform and while we supprot
some enhanced paltform awareness features like cpu pinning this si largely intened to be
someing the cloud admin configured and the end user just selects rather then something
an end user should have to deeply understand.

so tl;dr virtual cpu tpopligies are about optimisting the vm for the workload not the host.
optimising for the host can give a minimal performance uplift for the vm but the virutal
cpu toplogoy is intentionally decloupeld form the host toplogy.

the virtual numa topology feature is purely a performance enhancement feature
and is implictly tied to a host. ie. if you ask for 2 numa nodes we will pin
each guest numa node to a seperate host numa node. virtual numa topligecs
and cpu toplogies had two entrily diffent design goals. numa is tied to the
host toplogy to optimise for hardware constraits, cpu topliges are not tied
to the host hardware as they are optimising for guest software constraits?
(i.e. windows server only support 4 sockets so if you need more the 4 cpus you cannot
have 1 socket pre vcpu)

> 
> Em seg., 4 de set. de 2023 ?s 13:10, <smooney at redhat.com> escreveu:
> 
> > in general the only parameter you want to align to the physical host is
> > the number of thread
> > 
> > so if the phsyical host has 2 thread per physical core then its best to
> > also do that in the vm
> > 
> > we generally recommend setting the number of virutal socket equal to the
> > number of virutal numa nodes
> > if the vm has no explict numa toploly then you should set sockets=1
> > else hw:cpu_sockets==hw:numa_nodes is our recomendation.
> > 
> > for windows in partcalar the default config generated is suboptimal as
> > windows client only supprot 1-2 sockets
> > and windows serverver maxes out at 4 i believe.
> > 
> > On Mon, 2023-09-04 at 11:51 -0300, Jorge Visentini wrote:
> > > Hello Team,
> > > 
> > > What is the difference between creating an instance with *4* or *8
> > virtual
> > > sockets*, since the hypervisor has only *4 physical sockets*.
> > > My question is where do sockets, cores and virtual threads fit into the
> > > physical hardware. I think this question is not just related to
> > Openstack,
> > > but with any virtualization.
> > > 
> > > My hypervisor configuration is as follows:
> > > 
> > > CPU(s): 192
> > > Online CPU(s) list: 0-191
> > > Thread(s) per core: 2
> > > Core(s) per socket: 24
> > > Socket(s): 4
> > > NUMA node(s): 4
> > > 
> > > Do you have any documentation that I can read and understand better?
> > > 
> > > That we have a nice week!
> > 
> > 
> 



From hberaud at redhat.com  Tue Sep  5 12:09:53 2023
From: hberaud at redhat.com (Herve Beraud)
Date: Tue, 5 Sep 2023 14:09:53 +0200
Subject: [QA][release] Cycle With Intermediary without recent deliverables
Message-ID: <CAFDq9gW40W54Mrb_19Te+HvEYE4_nezy-GqOXzMTUikAMupb9A@mail.gmail.com>

Quick reminder that for deliverables following the cycle-with-intermediary
model, the release team will use the latest $series release available on
release week.

The following deliverables have done a 2023.2 bobcat release, but it was not
refreshed in the last two months:

 tempest

You should consider making a new one very soon, so that we don't use an
outdated version for the final release.


Thanks
-- 
Herv? Beraud
Senior Software Engineer at Red Hat
irc: hberaud
https://github.com/4383/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/1f57f1f7/attachment.htm>

From ygk.kmr at gmail.com  Tue Sep  5 12:49:11 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Tue, 5 Sep 2023 18:19:11 +0530
Subject: Host aggregates and placement aggregates
Message-ID: <CAJreVFw3d6AgXm4PMymG2J6=pUWsQSA7d-eLMw_DBMq5kXp4NQ@mail.gmail.com>

Hi All,

We have a yoga OSA setup. We have upgraded the setup from Xena to Yoga. We
have found that some of the host aggregates have not synced to the
placement aggregates. As a result , the vm creation on those aggregate
nodes is failing even though they have the full capacity. I have tried the
placement sync aggregates command but it did not help.

Is this a known bug in Yoga ?

Thanks
Y.G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/7067034f/attachment.htm>

From asma.naz at techavenue.biz  Tue Sep  5 04:16:01 2023
From: asma.naz at techavenue.biz (Asma Naz Shariq)
Date: Tue, 5 Sep 2023 09:16:01 +0500
Subject: ***UNCHECKED*** openstack-discuss Digest, Vol 59,
 Issue 10 | Openstack Web Interface  Issue
In-Reply-To: <mailman.27052.1693841206.934892.openstack-discuss@lists.openstack.org>
References: <mailman.27052.1693841206.934892.openstack-discuss@lists.openstack.org>
Message-ID: <000201d9dfaf$b43df350$1cb9d9f0$@techavenue.biz>

Hi Team,

I have deployed Openstack through manual installation-Yoga release. I
encountered the attached error and can't have access to Openstack dashboard.
When I entered the login credentials it displays something went wrong and
you don't have permission to use /horizon/.

Can anyone have a solution for this error.

-----Original Message-----
From: openstack-discuss-request at lists.openstack.org
<openstack-discuss-request at lists.openstack.org> 
Sent: Monday, September 4, 2023 8:27 PM
To: openstack-discuss at lists.openstack.org
Subject: ***UNCHECKED*** openstack-discuss Digest, Vol 59, Issue 10

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: Live migration error (Karera Tony)
   2. What is the difference between 4 and 8 virtual sockets to
      physical sockets? (Jorge Visentini)
   3. [all][stable][ptl] Propose to EOL Stein series (El?d Ill?s)


----------------------------------------------------------------------

Message: 1
Date: Mon, 4 Sep 2023 14:11:37 +0200
From: Karera Tony <tonykarera at gmail.com>
To: smooney at redhat.com
Cc: Danny Webb <Danny.Webb at thehutgroup.com>,  openstack-discuss
	<openstack-discuss at lists.openstack.org>
Subject: Re: Live migration error
Message-ID:
	<CA+69TL3=7GwfgRgAjfxvx5q4aZCstXxtBeB2mGb9ofa0JCZmbA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Smooney,

I can confirm that it is disabled on all the servers.

Regards

Tony Karera




On Mon, Sep 4, 2023 at 1:25?PM <smooney at redhat.com> wrote:

> On Mon, 2023-09-04 at 12:59 +0200, Karera Tony wrote:
> > Hello Danny,
> >
> > I am actually using Broadwell-noTSX-IBRS on all the servers but I 
> > have
> seen
> > that some flags are not there in the older servers.
> >
> > The flags below to be specific.
> >
> > hwp hwp_act_window hwp_pkg_req
> so hwp is apprentlly intels pstate contol based on 
> https://unix.stackexchange.com/a/43540
>
> i dont belive this is normally exposed to a guest but if you are 
> seeign differnce between hosts then that likely means you have 
> disabled pstates also know as "intel speedstep" on some of the host 
> and not others.
>
> >
> > Regards
> >
> > Tony Karera
> >
> >
> >
> >
> > On Fri, Sep 1, 2023 at 4:05?PM <smooney at redhat.com> wrote:
> >
> > > On Fri, 2023-09-01 at 14:56 +0200, Karera Tony wrote:
> > > > Hello Danny,
> > > >
> > > > Thanks for the feedback.
> > > >
> > > > use a lowest common denominator cpu_model : Does this mean 
> > > > changing
> the
> > > > servers ?
> > >
> > > it means tha tif you have a mix of cpus in the deployment you 
> > > shoudl hardcod to the older of the diffent cpu models i.e skylake 
> > > or whatever it may
> be
> > > in your case.
> > >
> > >
> > >
> https://docs.openstack.org/nova/latest/configuration/config.html#libvi
> rt.cpu_models
> > >
> > > [libvirt]
> > > cpu_mode=custom
> > > cpu_models=skylake
> > >
> > > in more recent release we replaced the older cpu_model with 
> > > cpu_models with is a comma sperated list of models in prefernce 
> > > order. i.e. nova will use the first
> cpu_modle
> > > in the list that work
> > > on the current host. not that while this give extra flexiblity it 
> > > vs
> just
> > > using the oldest cpu model
> > > it does limit the set of hosts you can migrate too but means you 
> > > can
> have
> > > better perfromance so its
> > > a tradeoff. performance vs portablity.
> > >
> > > the error you mentioned can also be caused by micorocode updates.
> > > intel remove TSX and MPX i beilve in the last 2 years form come of
> there
> > > cpus
> > > that breaks live migration if a vm was create with access to that 
> > > cpu instruction
> > >
> > > the only way to resolve that is to cold migrate the guest.
> > > i.e. if a vm is currently booted with cpu_model X it cannot be 
> > > modifed while the guest is running so you either need to update 
> > > the config option and reboot all the vms
> or
> > > more particlaly update the config
> > > and then cold migrate them which will allow you to move the
> instnace(your
> > > orginal goal) while allowing
> > > the new cpu model to take effect.
> > >
> > > novas default for the cpu model when not set is with our default
> cpu_mode
> > > is host_model
> > > meaning whatever model best matches the current hosts cpu.
> > >
> > > that is the correct default in general but if you have mixed cpu 
> > > generatiosn in your cloud its not ideal.
> > >
> > > hopefuly that helps
> > >
> > > >
> > > > Regards
> > > >
> > > > Tony Karera
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Sep 1, 2023 at 12:37?PM Danny Webb <
> Danny.Webb at thehutgroup.com>
> > > > wrote:
> > > >
> > > > > It means that you have CPUs with incompatible flags or you've 
> > > > > got differing kernel versions that expose different flags or 
> > > > > you've got differing libvirt versions that expose different 
> > > > > flags.  You either
> > > need to
> > > > > use a lowest common denominator cpu_model or do a cold migration.
> > > > > ------------------------------
> > > > > *From:* Karera Tony <tonykarera at gmail.com>
> > > > > *Sent:* 01 September 2023 10:13
> > > > > *To:* openstack-discuss 
> > > > > <openstack-discuss at lists.openstack.org>
> > > > > *Subject:* Live migration error
> > > > >
> > > > >
> > > > > * CAUTION: This email originates from outside THG *
> > > > > ------------------------------ Hello Team,
> > > > >
> > > > > I am trying to migrate instances from one host to another but 
> > > > > I am
> > > getting
> > > > > this error.
> > > > >
> > > > > *Error: *Failed to live migrate instance to host "compute1".
> Details
> > > > > <http://10.10.13.31/admin/instances/#message_details>
> > > > > Migration pre-check error: Unacceptable CPU info: CPU doesn't 
> > > > > have compatibility. 0 Refer to
> > > > >
> http://libvirt.org/html/libvirt-libvirt-host.html#virCPUCompareResult
> > > > > (HTTP 400) (Request-ID: 
> > > > > req-9dfdfe2e-70fa-481a-bd3d-c2c76a6e93da)
> > > > >
> > > > > Any idea on how to fix this?
> > > > >
> > > > > Regards
> > > > >
> > > > > Tony Karera
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.openstack.org/pipermail/openstack-discuss/attachments/2023090
4/8dcdbdf5/attachment-0001.htm>

------------------------------

Message: 2
Date: Mon, 4 Sep 2023 11:51:07 -0300
From: Jorge Visentini <jorgevisentini at gmail.com>
To: openstack-discuss at lists.openstack.org
Subject: What is the difference between 4 and 8 virtual sockets to
	physical sockets?
Message-ID:
	<CAG=j6fpruTk5EG0dZTyL3M-ud2tCq7CBQHZiCBmbsr5sd6Z8Ow at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Team,

What is the difference between creating an instance with *4* or *8 virtual
sockets*, since the hypervisor has only *4 physical sockets*.
My question is where do sockets, cores and virtual threads fit into the
physical hardware. I think this question is not just related to Openstack,
but with any virtualization.

My hypervisor configuration is as follows:

CPU(s): 192
Online CPU(s) list: 0-191
Thread(s) per core: 2
Core(s) per socket: 24
Socket(s): 4
NUMA node(s): 4

Do you have any documentation that I can read and understand better?

That we have a nice week!
--
Att,
Jorge Visentini
+55 55 98432-9868
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.openstack.org/pipermail/openstack-discuss/attachments/2023090
4/c5702749/attachment-0001.htm>

------------------------------

Message: 3
Date: Mon, 4 Sep 2023 15:26:39 +0000
From: El?d Ill?s <elod.illes at est.tech>
To: "openstack-discuss at lists.openstack.org"
	<openstack-discuss at lists.openstack.org>
Subject: [all][stable][ptl] Propose to EOL Stein series
Message-ID:
	
<VI1P18901MB075178B60ADE8475F17D3751FFE9A at VI1P18901MB0751.EURP189.PROD.OUTLO
OK.COM>
	
Content-Type: text/plain; charset="utf-8"

Hi,

Core projects announced and deleted their stable/stein branches for some
time already. Furthermore, most of the projects, where stable/stein is still
open, have broken gates.

So, the same way as we transitioned Rocky series to End of Life [1][2], now
is the time to do the same with Stein.

I'll propose the stein-eol transition patches for the rest of the open
projects. I ask again the teams to signal their decision (with a +1 if the
team is ready for the transition). Thanks in advance!

(Please note, that the Extended Maintenance process is phasing out /
transforming soon, see details in Technical Committee's resolution [3],
which was accepted and merged in August.)

Thanks,

El?d Ill?s
irc: elodilles @ #openstack-stable / #openstack-release

[1]
https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031922.
html
[2]
https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033386.ht
ml
[3]
https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branch
es.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.openstack.org/pipermail/openstack-discuss/attachments/2023090
4/a124c0b6/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
openstack-discuss mailing list
openstack-discuss at lists.openstack.org


------------------------------

End of openstack-discuss Digest, Vol 59, Issue 10
*************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apache2.err log with neutron.PNG
Type: image/png
Size: 24954 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/4e5e9471/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: neutron-server.error.PNG
Type: image/png
Size: 86403 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/4e5e9471/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openstack error_pic.PNG
Type: image/png
Size: 24672 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/4e5e9471/attachment-0005.png>

From hanoi952022 at gmail.com  Tue Sep  5 10:56:34 2023
From: hanoi952022 at gmail.com (Ha Noi)
Date: Tue, 5 Sep 2023 17:56:34 +0700
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when high
 throughput (pps)
Message-ID: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>

Hi everyone,

I'm using Openstack Train and Openvswitch for ML2 driver and GRE for tunnel
type. I tested our network performance between two VMs and suffer packet
loss as below.

VM1: IP: 10.20.1.206

VM2: IP: 10.20.1.154 <https://10.20.1.154/24>

VM3: IP: 10.20.1.72


Using iperf3 to testing performance between VM1 and VM2.

Run iperf3 client and server on both VMs.

On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206

On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
<https://10.20.1.154/24>


Using VM3 ping into VM1, then the packet is lost and the latency is quite
high.


ping -i 0.1 10.20.1.206

PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.

64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms

64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms

64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms

64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms

64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms

64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms

64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms

64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms

64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms

64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms

64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms

64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms

64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms

64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms

^C

--- 10.20.1.206 ping statistics ---

34 packets transmitted, 28 received, 17.6471% packet loss, time 3328ms

rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms



Does any one get this issue ?

Please help me. Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/f5938212/attachment.htm>

From roger.riverac at gmail.com  Tue Sep  5 12:48:49 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Tue, 5 Sep 2023 08:48:49 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
Message-ID: <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>

Hello,

We are noticing two issues with these changes:

*1*. The overrides on the file /*etc/openstack_deploy/env.d/nova.yml* are
not being honored:

nova_compute_container:
    belongs_to:
      - compute_containers
      - kvm-compute_containers
      - qemu-compute_containers
    contains:
      - neutron_sriov_nic_agent
      - neutron_ovn_controller
      - nova_compute
    properties:
      is_metal: true


The following block continues to be populated in with compute nodes in
*/etc/openstack_deploy/openstack_inventory.json* after deleting and
recreating the inventory file with
*/opt/openstack-ansible/scripts/inventory-manage.py*:

"neutron_ovn_gateway": {
        "children": [],
        "hosts": [
   "cmp3",
            "cmp4",
            "net1",
"net2"
]
    },


*2*. After changing *group_binds *to *neutron_ovn_gateway *instead of the
previous *neutron_ovn_controller*, group binds for *provider_networks *in
*openstack_user_config.yml*. Openstack-ansible still wants to create
network mappings for compute nodes, which are not part of the
*neutron_ovn_gateway
*host group:

=.=.=.=.=.=.=.=.=
TASK [os_neutron : Setup Network Provider Bridges]
**********************************************************************************************************************************************************************************************************************************************************************************************

fatal: [cmp4]: FAILED! => {"msg": "The task includes an option with an
undefined variable. The error was: list object has no element 1\n\nThe
error appears to be in
'/etc/ansible/roles/os_neutron/tasks/providers/setup_ovs_ovn.yml': line 55,
column 3, but may\nbe elsewhere in the file depending on the exact syntax
problem.\n\nThe offending line appears to be:\n\n\n- name: Setup Network
Provider Bridges\n  ^ here\n"}
=.=.=.=.=.=.=.=.=

I'll dig deeper to see if I can find anything that helps. But any
assistance will be appreciated.

Thanks


On Sat, Sep 2, 2023 at 12:08?PM Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
wrote:

> Hi,
>
> I think this is known issue which should be fixed with the following patch:
> https://review.opendev.org/c/openstack/openstack-ansible/+/892540
>
> In the meanwhile you should be able to workaround the issue by creating
> /etc/openstack_deploy/env.d/nova.yml file with following content:
>
> nova_compute_container:
>     belongs_to:
>       - compute_containers
>       - kvm-compute_containers
>       - qemu-compute_containers
>     contains:
>       - neutron_sriov_nic_agent
>       - neutron_ovn_controller
>       - nova_compute
>     properties:
>       is_metal: true
>
> You might also need to remove computes from the inventory using
> /opt/openstack-ansible/scripts/inventory-manage.py -r cmp03
>
> They will be re-added next time running openstack-ansible or
> dynamic-inventory.py. Removing them is needed to ensure that they're not
> part of ovn-gateway related group.
> You might also need to stop ovn-gateway service on these computes
> manually, but I'm not sure 100% about that.
>
> On Sat, Sep 2, 2023, 17:47 Roger Rivera <roger.riverac at gmail.com> wrote:
>
>> Hello,
>>
>> We have deployed an openstack-ansible cluster to test it on_metal with
>> OVN and defined *dedicated gateway hosts* connecting to the external
>> network with the *network-gateway_hosts* host group. Unfortunately, we
>> are not able to connect to the external/provider networks. It seems that
>> traffic wants to reach external networks via the hypervisor nodes and not
>> the gateway hosts.
>>
>> Any suggestions on changes needed to our configuration will be highly
>> appreciated.
>>
>> Environment:
>> -Openstack Antelope
>> -Ubuntu 22 on all hosts
>> -3 infra hosts - 1xNIC (ens1)
>> -2 compute hosts - 1xNIC (ens1)
>> -2 gateway hosts - 2xNIC (ens1 internal, ens2 external)
>> -No linux bridges are created.
>>
>> The gateway hosts are the only ones physically connected to the external
>> network via physical interface ens2. Therefore, we need all external
>> provider network traffic to traverse via these gateway hosts.
>>
>> Tenant networks work fine and VMs can talk to each other. However, when a
>> VM is spawned with a floating IP to the external network, they are unable
>> to reach the outside network.
>>
>> Relevant content from openstack-ansible configuration files:
>>
>>
>> =.=.=.=.=.=.=.=
>> openstack_user_config.yml
>> =.=.=.=.=.=.=.=
>> ```
>> ...
>> provider_networks:
>>     - network:
>>         container_bridge: "br-mgmt"
>>         container_type: "veth"
>>         container_interface: "ens1"
>>         ip_from_q: "management"
>>         type: "raw"
>>         group_binds:
>>           - all_containers
>>           - hosts
>>         is_management_address: true
>>     - network:
>>         container_bridge: "br-vxlan"
>>         container_type: "veth"
>>         container_interface: "ens1"
>>         ip_from_q: "tunnel"
>>         #type: "vxlan"
>>         type: "geneve"
>>         range: "1:1000"
>>         net_name: "geneve"
>>         group_binds:
>>           - neutron_ovn_controller
>>     - network:
>>         container_bridge: "br-flat"
>>         container_type: "veth"
>>         container_interface: "ens1"
>>         type: "flat"
>>         net_name: "flat"
>>         group_binds:
>>           - neutron_ovn_controller
>>     - network:
>>         container_bridge: "br-vlan"
>>         container_type: "veth"
>>         container_interface: "ens1"
>>         type: "vlan"
>>         range: "101:300,401:500"
>>         net_name: "vlan"
>>         group_binds:
>>           - neutron_ovn_controller
>>     - network:
>>         container_bridge: "br-storage"
>>         container_type: "veth"
>>         container_interface: "ens1"
>>         ip_from_q: "storage"
>>         type: "raw"
>>         group_binds:
>>           - glance_api
>>           - cinder_api
>>           - cinder_volume
>>           - nova_compute
>>
>> ...
>>
>> compute-infra_hosts:
>>   inf1:
>>     ip: 172.16.0.1
>>   inf2:
>>     ip: 172.16.0.2
>>   inf3:
>>     ip: 172.16.0.3
>>
>> compute_hosts:
>>   cmp4:
>>     ip: 172.16.0.21
>>   cmp3:
>>     ip: 172.16.0.22
>>
>> network_hosts:
>>   inf1:
>>     ip: 172.16.0.1
>>   inf2:
>>     ip: 172.16.0.2
>>   inf3:
>>     ip: 172.16.0.3
>>
>> network-gateway_hosts:
>>   net1:
>>     ip: 172.16.0.31
>>   net2:
>>     ip: 172.16.0.32
>>
>> ```
>>
>>
>> =.=.=.=.=.=.=.=
>> user_variables.yml
>> =.=.=.=.=.=.=.=
>> ```
>> ---
>> debug: false
>> install_method: source
>> rabbitmq_use_ssl: False
>> haproxy_use_keepalived: False
>> ...
>> neutron_plugin_type: ml2.ovn
>> neutron_plugin_base:
>>   - neutron.services.ovn_l3.plugin.OVNL3RouterPlugin
>>
>> neutron_ml2_drivers_type: geneve,vlan,flat
>> neutron_ml2_conf_ini_overrides:
>>   ml2:
>>     tenant_network_types: geneve
>>
>> ...
>> ```
>>
>> =.=.=.=.=.=.=.=
>> env.d/neutron.yml
>> =.=.=.=.=.=.=.=
>> ```
>> component_skel:
>>   neutron_ovn_controller:
>>     belongs_to:
>>       - neutron_all
>>   neutron_ovn_northd:
>>     belongs_to:
>>       - neutron_all
>>
>> container_skel:
>>   neutron_agents_container:
>>     contains: {}
>>   properties:
>>     is_metal: true
>>   neutron_ovn_northd_container:
>>     belongs_to:
>>       - network_containers
>>     contains:
>>       - neutron_ovn_northd
>>
>> ```
>>
>> =.=.=.=.=.=.=.=
>> env.d/nova.yml
>> =.=.=.=.=.=.=.=
>> ```
>> component_skel:
>>   nova_compute_container:
>>     belongs_to:
>>       - compute_containers
>>       - kvm-compute_containers
>>       - lxd-compute_containers
>>       - qemu-compute_containers
>>     contains:
>>       - neutron_ovn_controller
>>       - nova_compute
>>     properties:
>>       is_metal: true
>> ```
>>
>> =.=.=.=.=.=.=.=
>> group_vars/network_hosts
>> =.=.=.=.=.=.=.=
>> ```
>> openstack_host_specific_kernel_modules:
>>   - name: "openvswitch"
>>     pattern: "CONFIG_OPENVSWITCH"
>> ```
>>
>> The nodes layout is like this:
>>
>>  [image: image.png]
>>
>>
>> Any guidance on what we have wrong or how to improve this configuration
>> will be appreciated. We need to make external traffic for VMs to go out via
>> the gateway nodes and not the compute/hypervisor nodes.
>>
>> Thank you.
>>
>> Roger
>>
>

-- 
*Roger Rivera*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/bf0ea771/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 16574 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/bf0ea771/attachment-0001.png>

From gmann at ghanshyammann.com  Tue Sep  5 15:49:19 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 05 Sep 2023 08:49:19 -0700
Subject: [QA][release] Cycle With Intermediary without recent deliverables
In-Reply-To: <CAFDq9gW40W54Mrb_19Te+HvEYE4_nezy-GqOXzMTUikAMupb9A@mail.gmail.com>
References: <CAFDq9gW40W54Mrb_19Te+HvEYE4_nezy-GqOXzMTUikAMupb9A@mail.gmail.com>
Message-ID: <18a6608af79.127dbda1c450285.5437835893139603985@ghanshyammann.com>

 ---- On Tue, 05 Sep 2023 05:09:53 -0700  Herve Beraud  wrote --- 
 > Quick reminder that for deliverables following the cycle-with-intermediarymodel, the release team will use the latest $series release available onrelease week.The following deliverables have done a 2023.2 bobcat release, but it was notrefreshed in the last two months: tempestYou should consider making a new one very soon, so that we don't use anoutdated version for the final release.

Ack, I will check what changes we need to merge for 2023.2 and push the latest release.

-gmann

 > Thanks
 > -- 
 > Herv? BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/
 > 
 > 


From noonedeadpunk at gmail.com  Tue Sep  5 16:31:39 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 5 Sep 2023 18:31:39 +0200
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
Message-ID: <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>

Hey,

1. Sorry, my bad, was copying you from my phone, so the extra section (
container_skel) that is required has slipped my paste.
So /etc/openstack_deploy/env.d/nova.yml should look like this:
container_skel:
 nova_compute_container:
   belongs_to:
     - compute_containers
     - kvm-compute_containers
     - qemu-compute_containers
   contains:
     - neutron_sriov_nic_agent
     - neutron_ovn_controller
     - nova_compute
   properties:
     is_metal: true

2. Now I actually see more issues in defined openstack_user_config. I'm not
sure if that is the reason of the error or not, but it still must be
adjusted:
a) replace network_hosts with network-infra_hosts. Defining network_hosts
also adds infra servers to neutron_l3_agent (and other agents) which has in
fact no effect, but triggers a bug, where run_once is treated wrongly. But
this will cause failure down the line and I assume that's not it yet. You
might need to clean up inventory as a result.
b) also define network-northd_hosts - this usually is usually set to infra
nodes, and spawns inside LXC. I would also suggest to check out doc on OVN
configuration:
https://docs.openstack.org/openstack-ansible-os_neutron/latest/app-ovn.html
c) For the issue itself. Most likely, it is looking for `container_bridge`
or `host_bind_override` key for some network. As one of these keys are
expected in order to create a mapping and ovs bridges for you. It does
combine net_name and one of these keys. So it would be interesting to see
adjusted openstack_user_config once the above issues are sorted out.
I can also suggest defining mappings in neutron_provider_networks directly,
like mentioned in the documentation above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/d2e70ba7/attachment.htm>

From jay at gr-oss.io  Tue Sep  5 19:09:51 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Tue, 5 Sep 2023 12:09:51 -0700
Subject: [election] [tc] Running for a second year on the TC
Message-ID: <CA+sTGNck1xTV2-BdtrzHaMtcES+9ZEeqt35sYShL1sAmypCGiQ@mail.gmail.com>

Hey all,

Around a year ago, I announced my candidacy for the TC after a call for
more contributors from a diverse employer base was made. I think a year
later, it's more obvious than ever how important it is to have a diverse,
independent technical committee. We have made huge progress on this front.
We have six candidates for the four open TC positions, representing
different independent companies utilizing OpenStack. This is a major
improvement year over year.

If you've been in the community a while, you've probably worked with me and
have an idea if you want to vote for me or not in this position. Whether
elected or not, I'll continue my vocal support of OpenStack technologies in
private meetings and on social media, I'll continue to invite people I meet
interested in cloud to join our community -- not because it's my job (it
is), but also because I'm proud of what we've built.

When I have those conversations with potential users or contributors, I
highlight two things I admire about the OpenStack community: longevity --
there are not many large, distributed open source projects that have
survived as long as we have, and the four opens -- putting openness out
front as our face to the world is why I'll continue to be proud to
represent OpenStack in the future -- as a TC member or not (you decide).

If someone does want to talk about a particular policy or thought process
of mine, I'm happy to respond to comments here or via private email/IRC.

Thanks,
Jay Faulkner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/837eaf87/attachment.htm>

From ianyrchoi at gmail.com  Tue Sep  5 19:44:59 2023
From: ianyrchoi at gmail.com (Ian Y. Choi)
Date: Wed, 6 Sep 2023 04:44:59 +0900
Subject: [all][elections][ptl][tc] Opt in to CIVS voting system
Message-ID: <f7a4782c-7e6e-44e2-9946-470ce3f486c7@gmail.com>

The election uses the Condorcet Internet Voting Service (CIVS).
Due to CIVS policy, to vote in private CIVS polls, you must opt in to email
communication.

To opt in, please enter your Gerrit email address in the following page 
before
the start of the election Sep 06, 2023 23:45 UTC, and confirm with the 
code that
will sent to you via email.

https://civs1.civs.us/cgi-bin/opt_in.pl

If you have any question, please contact the election officials.
https://governance.openstack.org/election/#election-officials


From satish.txt at gmail.com  Tue Sep  5 22:50:03 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 5 Sep 2023 18:50:03 -0400
Subject: [kolla-ansible][octavia] octavia management network setup for vlan
 provider
Message-ID: <CAPgF-fp5rmJ-08D16XqdQ_HQ1ORR4o6Z=siPKpbpgoiuXsuXXg@mail.gmail.com>

Folks,

I have setup kolla-ansible and configured octavia using the o-hm0 interface
with the tenant and it works. For production I think I should use VLAN
based provider for octavia management network so this is what I did

I have created a bond0.41 dedicated interface on all 3 controller nodes and
created vlan 41 on all network switches.

This is what my global.yml looks like

## Octivia
enable_octavia: "yes"
octavia_network_interface: "bond0.41"

octavia_amp_flavor:
  name: "amphora"
  is_public: no
  vcpus: 2
  ram: 2048
  disk: 5

octavia_amp_network:
  name: lb-mgmt-net
  provider_network_type: vlan
  provider_segmentation_id: 41
  provider_physical_network: physnet1
  external: false
  shared: false
  subnet:
    name: lb-mgmt-subnet
    cidr: "192.168.41.0/24"
    allocation_pool_start: "192.168.41.100"
    allocation_pool_end: "192.168.41.200"
    enable_dhcp: yes

After running the playbook all get setup as per document. When I create
loadbalancer it just get stuck in PENDING status.

[1] Document saying make sure your octavia_network_interface is connected
to openvswitch. Do I need to connect manually or will kolla-ansible do that
for me?  If I am going to do that then on which bridge I should attach
br-ex or br-int ?

[1]
https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230905/ac26d23e/attachment-0001.htm>

From oliver.weinmann at me.com  Wed Sep  6 04:31:04 2023
From: oliver.weinmann at me.com (Oliver Weinmann)
Date: Wed, 6 Sep 2023 06:31:04 +0200
Subject: [kolla-ansible][octavia] octavia management network setup for
 vlan provider
In-Reply-To: <CAPgF-fp5rmJ-08D16XqdQ_HQ1ORR4o6Z=siPKpbpgoiuXsuXXg@mail.gmail.com>
References: <CAPgF-fp5rmJ-08D16XqdQ_HQ1ORR4o6Z=siPKpbpgoiuXsuXXg@mail.gmail.com>
Message-ID: <DA33E667-AB1C-483B-A922-26EC3C0C359D@me.com>

An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/d9b5767f/attachment.htm>

From tkajinam at redhat.com  Wed Sep  6 12:38:13 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 6 Sep 2023 21:38:13 +0900
Subject: [puppet] Transitioning train, ussuri and victoria to EOL
Message-ID: <CAL_crJToMKEPqFxjCNuiAuu79EuTqzBTHF=WNvTmJLji2YQ_Rg@mail.gmail.com>

Hello,


As we agreed in the PTG discussions at Vancouver, we'll EOL the old stable
branches
of Puppet OpenStack projects. As the first step I'll start transitioning
stable/train, ussuri
and victoria to EOL early next week.

Please let me know in case anyone has any concerns about it.

Thank you,
Takashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/0a178663/attachment.htm>

From satish.txt at gmail.com  Wed Sep  6 12:59:04 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 6 Sep 2023 08:59:04 -0400
Subject: [kolla-ansible][octavia] octavia management network setup for
 vlan provider
In-Reply-To: <DA33E667-AB1C-483B-A922-26EC3C0C359D@me.com>
References: <CAPgF-fp5rmJ-08D16XqdQ_HQ1ORR4o6Z=siPKpbpgoiuXsuXXg@mail.gmail.com>
 <DA33E667-AB1C-483B-A922-26EC3C0C359D@me.com>
Message-ID: <CAPgF-foStob8w7JgvZNd0wrG_eJChzrcgTpvOqQN8m3E0Wf0vQ@mail.gmail.com>

Hi Oliver,

Thank you for your reply, That is an awesome blog and we should add
multiple scenarios or examples to kolla-ansible official doc page to help
out people :)

By the way, Last night I figured out how to handle veth and wire up with
lb-mgmt-net and soon I will create a blog to make it easier for others to
understand the logic behind it.

On Wed, Sep 6, 2023 at 12:31?AM Oliver Weinmann <oliver.weinmann at me.com>
wrote:

> Hi Satish,
>
> I got stuck at the very same issue when I first set up Octavia. The
> control. Does need to have an interface on VLAN 41, since they need to
> communicate with the amphora instances. So you need to create a VLAN 41
> interface on all control nodes with an IP of the LB-MGMT-NET outside of
> your defined allocation pool. If you have a free interface in your control
> nodes use that, if not you can try to create VETH interfaces as explained
> in the following article:
>
> *https://cloudbase.it/openstack-on-arm64-lbaas/*
> <https://cloudbase.it/openstack-on-arm64-lbaas/>
>
>
> Cheers,
>
> Oliver
>
> Von meinem iPhone gesendet
>
> Am 06.09.2023 um 00:52 schrieb Satish Patel <satish.txt at gmail.com>:
>
> ?
> Folks,
>
> I have setup kolla-ansible and configured octavia using the o-hm0
> interface with the tenant and it works. For production I think I should use
> VLAN based provider for octavia management network so this is what I did
>
> I have created a bond0.41 dedicated interface on all 3 controller nodes
> and created vlan 41 on all network switches.
>
> This is what my global.yml looks like
>
> ## Octivia
> enable_octavia: "yes"
> octavia_network_interface: "bond0.41"
>
> octavia_amp_flavor:
>   name: "amphora"
>   is_public: no
>   vcpus: 2
>   ram: 2048
>   disk: 5
>
> octavia_amp_network:
>   name: lb-mgmt-net
>   provider_network_type: vlan
>   provider_segmentation_id: 41
>   provider_physical_network: physnet1
>   external: false
>   shared: false
>   subnet:
>     name: lb-mgmt-subnet
>     cidr: "192.168.41.0/24"
>     allocation_pool_start: "192.168.41.100"
>     allocation_pool_end: "192.168.41.200"
>     enable_dhcp: yes
>
> After running the playbook all get setup as per document. When I create
> loadbalancer it just get stuck in PENDING status.
>
> [1] Document saying make sure your octavia_network_interface is connected
> to openvswitch. Do I need to connect manually or will kolla-ansible do that
> for me?  If I am going to do that then on which bridge I should attach
> br-ex or br-int ?
>
> [1]
> https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/caf1947c/attachment.htm>

From satish.txt at gmail.com  Wed Sep  6 13:18:52 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 6 Sep 2023 09:18:52 -0400
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
Message-ID: <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>

Hi,

This is normal because OVS or LinuxBridge wire up VMs using TAP interface
which runs on kernel space and that drives higher interrupt and that makes
the kernel so busy working on handling packets. Standard OVS/LinuxBridge
are not meant for higher PPS.

If you want to handle higher PPS then look for DPDK or SRIOV deployment. (
We are running everything in SRIOV because of high PPS requirement)

On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com> wrote:

> Hi everyone,
>
> I'm using Openstack Train and Openvswitch for ML2 driver and GRE for
> tunnel type. I tested our network performance between two VMs and suffer
> packet loss as below.
>
> VM1: IP: 10.20.1.206
>
> VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>
> VM3: IP: 10.20.1.72
>
>
> Using iperf3 to testing performance between VM1 and VM2.
>
> Run iperf3 client and server on both VMs.
>
> On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
>
> On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
> <https://10.20.1.154/24>
>
>
> Using VM3 ping into VM1, then the packet is lost and the latency is quite
> high.
>
>
> ping -i 0.1 10.20.1.206
>
> PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>
> 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>
> 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>
> ^C
>
> --- 10.20.1.206 ping statistics ---
>
> 34 packets transmitted, 28 received, 17.6471% packet loss, time 3328ms
>
> rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>
>
>
> Does any one get this issue ?
>
> Please help me. Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/3a4ec650/attachment-0001.htm>

From hanoi952022 at gmail.com  Wed Sep  6 13:21:14 2023
From: hanoi952022 at gmail.com (Ha Noi)
Date: Wed, 6 Sep 2023 20:21:14 +0700
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
Message-ID: <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>

Hi Satish,

Actually, our customer get this issue when the tx/rx above only 40k pps. So
what is the threshold of this throughput for OvS?


Thanks and regards

On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com> wrote:

> Hi,
>
> This is normal because OVS or LinuxBridge wire up VMs using TAP interface
> which runs on kernel space and that drives higher interrupt and that makes
> the kernel so busy working on handling packets. Standard OVS/LinuxBridge
> are not meant for higher PPS.
>
> If you want to handle higher PPS then look for DPDK or SRIOV deployment. (
> We are running everything in SRIOV because of high PPS requirement)
>
> On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>
>> Hi everyone,
>>
>> I'm using Openstack Train and Openvswitch for ML2 driver and GRE for
>> tunnel type. I tested our network performance between two VMs and suffer
>> packet loss as below.
>>
>> VM1: IP: 10.20.1.206
>>
>> VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>
>> VM3: IP: 10.20.1.72
>>
>>
>> Using iperf3 to testing performance between VM1 and VM2.
>>
>> Run iperf3 client and server on both VMs.
>>
>> On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
>>
>> On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
>> <https://10.20.1.154/24>
>>
>>
>> Using VM3 ping into VM1, then the packet is lost and the latency is quite
>> high.
>>
>>
>> ping -i 0.1 10.20.1.206
>>
>> PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>
>> 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>>
>> 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>>
>> ^C
>>
>> --- 10.20.1.206 ping statistics ---
>>
>> 34 packets transmitted, 28 received, 17.6471% packet loss, time 3328ms
>>
>> rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>
>>
>>
>> Does any one get this issue ?
>>
>> Please help me. Thanks
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/c2b46c06/attachment-0001.htm>

From jobernar at redhat.com  Wed Sep  6 13:57:19 2023
From: jobernar at redhat.com (Jon Bernard)
Date: Wed, 6 Sep 2023 13:57:19 +0000
Subject: Cinder Bug Report 2023-09-06
Message-ID: <ZPiFPyqvy0jXq4KY@localhost>

Hello Argonauts,

Cinder Bug Meeting Etherpad
<https://etherpad.opendev.org/p/cinder-bug-squad-meeting>

Undecided

- Weak Cryptographic Algorithm (MD5) used
  <https://bugs.launchpad.net/cinder/+bug/2033612>
  - Status: New
- group list doesn't parse 'all_tenants' parameter correctly
  <https://bugs.launchpad.net/cinder/+bug/2034248>
  - Status: In Progress
- Documentation check and correction for PowerStore NFS driver
  <https://bugs.launchpad.net/cinder/+bug/2034482>
  - Status: New

Thanks

-- 
Jon



From Danny.Webb at thehutgroup.com  Wed Sep  6 14:40:18 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Wed, 6 Sep 2023 14:40:18 +0000
Subject: [kolla-ansible][octavia] octavia management network setup for
 vlan provider
In-Reply-To: <CAPgF-foStob8w7JgvZNd0wrG_eJChzrcgTpvOqQN8m3E0Wf0vQ@mail.gmail.com>
References: <CAPgF-fp5rmJ-08D16XqdQ_HQ1ORR4o6Z=siPKpbpgoiuXsuXXg@mail.gmail.com>
 <DA33E667-AB1C-483B-A922-26EC3C0C359D@me.com>
 <CAPgF-foStob8w7JgvZNd0wrG_eJChzrcgTpvOqQN8m3E0Wf0vQ@mail.gmail.com>
Message-ID: <LO2P265MB57733F4AB2E8053B847329B39AEFA@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

The one downside of using the veth method vs a vlan tagged interface on the host is making it persistent after reboot.  It's possible, but it's far more of a faff than just using a standard tagged interface.
________________________________
From: Satish Patel <satish.txt at gmail.com>
Sent: 06 September 2023 13:59
To: Oliver Weinmann <oliver.weinmann at me.com>
Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [kolla-ansible][octavia] octavia management network setup for vlan provider


CAUTION: This email originates from outside THG

________________________________
Hi Oliver,

Thank you for your reply, That is an awesome blog and we should add multiple scenarios or examples to kolla-ansible official doc page to help out people :)

By the way, Last night I figured out how to handle veth and wire up with lb-mgmt-net and soon I will create a blog to make it easier for others to understand the logic behind it.

On Wed, Sep 6, 2023 at 12:31?AM Oliver Weinmann <oliver.weinmann at me.com<mailto:oliver.weinmann at me.com>> wrote:
Hi Satish,

I got stuck at the very same issue when I first set up Octavia. The control. Does need to have an interface on VLAN 41, since they need to communicate with the amphora instances. So you need to create a VLAN 41 interface on all control nodes with an IP of the LB-MGMT-NET outside of your defined allocation pool. If you have a free interface in your control nodes use that, if not you can try to create VETH interfaces as explained in the following article:


*https://cloudbase.it/openstack-on-arm64-lbaas/*<https://cloudbase.it/openstack-on-arm64-lbaas/>


Cheers,

Oliver

Von meinem iPhone gesendet

Am 06.09.2023 um 00:52 schrieb Satish Patel <satish.txt at gmail.com<mailto:satish.txt at gmail.com>>:

?
Folks,

I have setup kolla-ansible and configured octavia using the o-hm0 interface with the tenant and it works. For production I think I should use VLAN based provider for octavia management network so this is what I did

I have created a bond0.41 dedicated interface on all 3 controller nodes and created vlan 41 on all network switches.

This is what my global.yml looks like

## Octivia
enable_octavia: "yes"
octavia_network_interface: "bond0.41"

octavia_amp_flavor:
  name: "amphora"
  is_public: no
  vcpus: 2
  ram: 2048
  disk: 5

octavia_amp_network:
  name: lb-mgmt-net
  provider_network_type: vlan
  provider_segmentation_id: 41
  provider_physical_network: physnet1
  external: false
  shared: false
  subnet:
    name: lb-mgmt-subnet
    cidr: "192.168.41.0/24<http://192.168.41.0/24>"
    allocation_pool_start: "192.168.41.100"
    allocation_pool_end: "192.168.41.200"
    enable_dhcp: yes

After running the playbook all get setup as per document. When I create loadbalancer it just get stuck in PENDING status.

[1] Document saying make sure your octavia_network_interface is connected to openvswitch. Do I need to connect manually or will kolla-ansible do that for me?  If I am going to do that then on which bridge I should attach br-ex or br-int ?

[1] https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html<https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/cf123079/attachment.htm>

From thierry at openstack.org  Wed Sep  6 15:22:59 2023
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 6 Sep 2023 17:22:59 +0200
Subject: [largescale-sig] Next meeting: Sept 6, 15utc
In-Reply-To: <94831ce5-03e2-b08c-0c78-4b000be7a681@openstack.org>
References: <94831ce5-03e2-b08c-0c78-4b000be7a681@openstack.org>
Message-ID: <1671f647-90cb-d328-f58f-7ac0e5cf060f@openstack.org>

Here is the summary of our SIG meeting today.

We discussed hosts for our next OpenInfra Live episode, a deep dive into 
NIPA Cloud deployment on Sept 21.

You can read the detailed meeting logs at:

https://meetings.opendev.org/meetings/large_scale_sig/2023/large_scale_sig.2023-09-06-15.00.html

Our next IRC meeting will be Sept 20, 8:00UTC on #openstack-operators on 
OFTC.

Regards,

-- 
Thierry Carrez (ttx)



From satish.txt at gmail.com  Wed Sep  6 15:43:42 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 6 Sep 2023 11:43:42 -0400
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
Message-ID: <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>

Damn! We have noticed the same issue around 40k to 55k PPS. Trust me
nothing is wrong in your config. This is just a limitation of the software
stack and kernel itself.

On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com> wrote:

> Hi Satish,
>
> Actually, our customer get this issue when the tx/rx above only 40k pps.
> So what is the threshold of this throughput for OvS?
>
>
> Thanks and regards
>
> On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com> wrote:
>
>> Hi,
>>
>> This is normal because OVS or LinuxBridge wire up VMs using TAP interface
>> which runs on kernel space and that drives higher interrupt and that makes
>> the kernel so busy working on handling packets. Standard OVS/LinuxBridge
>> are not meant for higher PPS.
>>
>> If you want to handle higher PPS then look for DPDK or SRIOV deployment.
>> ( We are running everything in SRIOV because of high PPS requirement)
>>
>> On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I'm using Openstack Train and Openvswitch for ML2 driver and GRE for
>>> tunnel type. I tested our network performance between two VMs and suffer
>>> packet loss as below.
>>>
>>> VM1: IP: 10.20.1.206
>>>
>>> VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>>
>>> VM3: IP: 10.20.1.72
>>>
>>>
>>> Using iperf3 to testing performance between VM1 and VM2.
>>>
>>> Run iperf3 client and server on both VMs.
>>>
>>> On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
>>>
>>> On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
>>> <https://10.20.1.154/24>
>>>
>>>
>>> Using VM3 ping into VM1, then the packet is lost and the latency is
>>> quite high.
>>>
>>>
>>> ping -i 0.1 10.20.1.206
>>>
>>> PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>>>
>>> 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>>>
>>> ^C
>>>
>>> --- 10.20.1.206 ping statistics ---
>>>
>>> 34 packets transmitted, 28 received, 17.6471% packet loss, time 3328ms
>>>
>>> rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>>
>>>
>>>
>>> Does any one get this issue ?
>>>
>>> Please help me. Thanks
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/83237d40/attachment-0001.htm>

From ces.eduardo98 at gmail.com  Wed Sep  6 17:06:17 2023
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Wed, 6 Sep 2023 14:06:17 -0300
Subject: [manila] Cancelling Sep 7 weekly meeting
Message-ID: <CAE51gQJAM9m7uXMi=6WRKDrxA72bL04vd+4RTo=k_w7-+Guvhg@mail.gmail.com>

Hello, Zorillas!

As discussed in the previous meeting, we are cancelling tomorrow's weekly
meeting, as a big part of the audience is on PTO tomorrow/this week.

The next Manila weekly meeting will be on Sep 14th. If you have something
urgent to bring up, please let me know on the #openstack-manila IRC channel.

Regards,
carloss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/1498697d/attachment.htm>

From smooney at redhat.com  Wed Sep  6 17:41:24 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Wed, 06 Sep 2023 18:41:24 +0100
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
Message-ID: <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>

On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
> Damn! We have noticed the same issue around 40k to 55k PPS. Trust me
> nothing is wrong in your config. This is just a limitation of the software
> stack and kernel itself.
its partly determined by your cpu frequency.
kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
cpu. with per port troughpuyt being lower dependin on what qos/firewall
rules that were apllied.

moving form iptables firewall to ovs firewall can help to some degree
but your partly trading connection setup time for statead state troughput
with the overhead of the connection tracker in ovs.

using stateless security groups can help

we also recently fixed a regression cause by changes in newer versions of ovs.
this was notable in goign form rhel 8 to rhel 9 where litrally it reduced
small packet performce to 1/10th and jumboframes to about 1/2
on master we have a config option that will set the default qos on a port to linux-noop
https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125

the backports are propsoed upstream https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
and we have backported this downstream to adress that performance regression.
the upstram backport is semi stalled just ebcasue we wanted to disucss if we shoudl make ti opt in
by default upstream while backporting but it might be helpful for you if this is related to yoru current
issues.

40-55 kpps is kind of low for kernel ovs but if you have a low clockrate cpu, hybrid_plug + incorrect qos
then i could see you hitting such a bottelneck.

one workaround by the way without the os-vif workaround backported is to set 
/proc/sys/net/core/default_qdisc to not apply any qos or a low overhead qos type
i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast

that may or may not help but i would ensure that your are not usign somting like fqdel or cake
for net.core.default_qdisc and if you are try changing it to pfifo_fast and see if that helps.

there isnet much you can do about the cpu clock rate but ^ is somethign you can try for free
note it wont actully take effect on an exsitng vm if you jsut change the default but you can use
tc to also chagne the qdisk for testing. hard rebooting the vm shoudl also make the default take effect.

the only other advice i can give assuming kernel ovs is the only option you have is

to look at
https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
and
https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled

if the bottelneck is actully in qemu or the guest kernel rather then ovs adjusting the rx/tx queue size and
using multi queue can help. it will have no effect if ovs is the bottel neck.


> 
> On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com> wrote:
> 
> > Hi Satish,
> > 
> > Actually, our customer get this issue when the tx/rx above only 40k pps.
> > So what is the threshold of this throughput for OvS?
> > 
> > 
> > Thanks and regards
> > 
> > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com> wrote:
> > 
> > > Hi,
> > > 
> > > This is normal because OVS or LinuxBridge wire up VMs using TAP interface
> > > which runs on kernel space and that drives higher interrupt and that makes
> > > the kernel so busy working on handling packets. Standard OVS/LinuxBridge
> > > are not meant for higher PPS.
> > > 
> > > If you want to handle higher PPS then look for DPDK or SRIOV deployment.
> > > ( We are running everything in SRIOV because of high PPS requirement)
> > > 
> > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com> wrote:
> > > 
> > > > Hi everyone,
> > > > 
> > > > I'm using Openstack Train and Openvswitch for ML2 driver and GRE for
> > > > tunnel type. I tested our network performance between two VMs and suffer
> > > > packet loss as below.
> > > > 
> > > > VM1: IP: 10.20.1.206
> > > > 
> > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
> > > > 
> > > > VM3: IP: 10.20.1.72
> > > > 
> > > > 
> > > > Using iperf3 to testing performance between VM1 and VM2.
> > > > 
> > > > Run iperf3 client and server on both VMs.
> > > > 
> > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
> > > > 
> > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
> > > > <https://10.20.1.154/24>
> > > > 
> > > > 
> > > > Using VM3 ping into VM1, then the packet is lost and the latency is
> > > > quite high.
> > > > 
> > > > 
> > > > ping -i 0.1 10.20.1.206
> > > > 
> > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
> > > > 
> > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
> > > > 
> > > > ^C
> > > > 
> > > > --- 10.20.1.206 ping statistics ---
> > > > 
> > > > 34 packets transmitted, 28 received, 17.6471% packet loss, time 3328ms
> > > > 
> > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
> > > > 
> > > > 
> > > > 
> > > > Does any one get this issue ?
> > > > 
> > > > Please help me. Thanks
> > > > 
> > > 



From roger.riverac at gmail.com  Wed Sep  6 20:25:44 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Wed, 6 Sep 2023 16:25:44 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
Message-ID: <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>

Hello,

I appreciate the prompt feedback. Unfortunately, after making multiple
changes, we cannot make external networks to connect via gateway-hosts. Our
follow up investigation has shown the following:

1. Removed flat and vlan provider_networks from
/etc/openstack_deploy/openstack_user_config.yml. Only management
provider_networks  was defined here :

provider_networks:
    - network:
        container_bridge: "br-mgmt"
        container_type: "veth"
        container_interface: "ens4"
        ip_from_q: "management"
        type: "raw"
        group_binds:
          - all_containers
          - hosts
        is_management_address: true


2. Defined ML2 information and network types in
/etc/openstack_deploy/user_variables.yml:

neutron_ml2_conf_ini_overrides:
  ml2:
    tenant_network_types: geneve
  ml2_type_flat:
    flat_networks: flat
  ml2_type_geneve:
    vni_ranges: 1:1000
    max_header_size: 38


3. Moved neutron_provider_networks configuration on a per-host basis and
removed network_mappings and network_interface_mappings for compute hosts
in /etc/openstack_deploy/host_vars/

compute node
/etc/openstack_deploy/host_vars/cmp3:

neutron_provider_networks:
  network_types: "geneve"
  network_geneve_ranges: "1:1000"


gateway node
/etc/openstack_deploy/host_vars/net1:

neutron_provider_networks:
  network_types: "geneve"
  network_geneve_ranges: "1:1000"
  network_mappings: "flat:br-flat"
  network_interface_mappings: "br-flat:ens2"


4. Upon checking the new recreated inventory targets the correct
neutron_ovn_gateway hosts
/etc/openstack_deploy/openstack_inventory.json

?
"component": "neutron_ovn_gateway",
                "container_name": "net1",
                "container_networks": {
                    "management_address": {
                        "address": "172.16.0.31",
                        "bridge": "br-mgmt",

--

                "component": "neutron_ovn_gateway",
                "container_name": "net2",
                "container_networks": {
                    "management_address": {
                        "address": "172.16.0.32",
                        "bridge": "br-mgmt",

--
"neutron_ovn_gateway": {
        "children": [],
        "hosts": [
            "net1",
            "net2"
?




5. The correct ovn-cms-options=enable-chassis-as-gw is set on gateway nodes
only:

ovn-sbctl list chassis | grep 'hostname\|ovn-cms-options'

hostname            : net2
other_config        : {ct-no-masked-label="true", datapath-type=system,
iface-types="afxdp,afxdp-nonpmd,bareudp,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
is-interconn="false", mac-binding-timestamp="true",
ovn-bridge-mappings="flat:br-flat", ovn-chassis-mac-mappings="",
ovn-cms-options=enable-chassis-as-gw, ovn-ct-lb-related="true",
ovn-enable-lflow-cache="true", ovn-limit-lflow-cache="",
ovn-memlimit-lflow-cache-kb="", ovn-monitor-all="false",
ovn-trim-limit-lflow-cache="", ovn-trim-timeout-ms="",
ovn-trim-wmark-perc-lflow-cache="", port-up-notif="true"}

hostname            : net1
other_config        : {ct-no-masked-label="true", datapath-type=system,
iface-types="afxdp,afxdp-nonpmd,bareudp,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
is-interconn="false", mac-binding-timestamp="true",
ovn-bridge-mappings="flat:br-flat", ovn-chassis-mac-mappings="",
ovn-cms-options=enable-chassis-as-gw, ovn-ct-lb-related="true",
ovn-enable-lflow-cache="true", ovn-limit-lflow-cache="",
ovn-memlimit-lflow-cache-kb="", ovn-monitor-all="false",
ovn-trim-limit-lflow-cache="", ovn-trim-timeout-ms="",
ovn-trim-wmark-perc-lflow-cache="", port-up-notif="true"}

hostname            : cmp3
other_config        : {ct-no-masked-label="true", datapath-type=system,
iface-types="afxdp,afxdp-nonpmd,bareudp,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
is-interconn="false", mac-binding-timestamp="true", ovn-bridge-mappings="",
ovn-chassis-mac-mappings="", ovn-cms-options="", ovn-ct-lb-related="true",
ovn-enable-lflow-cache="true", ovn-limit-lflow-cache="",
ovn-memlimit-lflow-cache-kb="", ovn-monitor-all="false",
ovn-trim-limit-lflow-cache="", ovn-trim-timeout-ms="",
ovn-trim-wmark-perc-lflow-cache="", port-up-notif="true"}

hostname            : cmp4
other_config        : {ct-no-masked-label="true", datapath-type=system,
iface-types="afxdp,afxdp-nonpmd,bareudp,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
is-interconn="false", mac-binding-timestamp="true", ovn-bridge-mappings="",
ovn-chassis-mac-mappings="", ovn-cms-options="", ovn-ct-lb-related="true",
ovn-enable-lflow-cache="true", ovn-limit-lflow-cache="",
ovn-memlimit-lflow-cache-kb="", ovn-monitor-all="false",
ovn-trim-limit-lflow-cache="", ovn-trim-timeout-ms="",
ovn-trim-wmark-perc-lflow-cache="", port-up-notif="true"}


RESULT: VMs fail to launch with external network (flat). Error logs
"Binding failed for port":


Sep  6 19:42:37 net1 nova-conductor[4270]: 2023-09-06 19:42:37.599 4270
ERROR nova.scheduler.utils [None req-25a6a8d6-8122-4621-a2c2-8ca0be5e594c
52059c7247434072b6823d1701fec23e 116579f970b242b996ac717fa7580311 - -
default default] [instance: 8760706e-d38f-454d-b90f-b9d5d322ba99] Error
from last host: dev-usc1-ost-cmp4 (node dev-usc1-ost-cmp4.openstack.local):
['Traceback (most recent call last):\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/compute/manager.py",
line 2607, in _build_and_run_instance\n    self.driver.spawn(context,
instance, image_meta,\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/virt/libvirt/driver.py",
line 4383, in spawn\n    xml = self._get_guest_xml(context, instance,
network_info,\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/virt/libvirt/driver.py",
line 7516, in _get_guest_xml\n    network_info_str = str(network_info)\n',
'  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/network/model.py",
line 620, in __str__\n    return self._sync_wrapper(fn, *args,
**kwargs)\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/network/model.py",
line 603, in _sync_wrapper\n    self.wait()\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/network/model.py",
line 635, in wait\n    self[:] = self._gt.wait()\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/eventlet/greenthread.py",
line 181, in wait\n    return self._exit_event.wait()\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/eventlet/event.py",
line 132, in wait\n    current.throw(*self._exc)\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/eventlet/greenthread.py",
line 221, in main\n    result = function(*args, **kwargs)\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/utils.py",
line 654, in context_wrapper\n    return func(*args, **kwargs)\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/compute/manager.py",
line 1987, in _allocate_network_async\n    raise e\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/compute/manager.py",
line 1965, in _allocate_network_async\n    nwinfo =
self.network_api.allocate_for_instance(\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/network/neutron.py",
line 1216, in allocate_for_instance\n    created_port_ids =
self._update_ports_for_instance(\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/network/neutron.py",
line 1352, in _update_ports_for_instance\n    with
excutils.save_and_reraise_exception():\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/oslo_utils/excutils.py",
line 227, in __exit__\n    self.force_reraise()\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/oslo_utils/excutils.py",
line 200, in force_reraise\n    raise self.value\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/network/neutron.py",
line 1327, in _update_ports_for_instance\n    updated_port =
self._update_port(\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/network/neutron.py",
line 585, in _update_port\n    _ensure_no_port_binding_failure(port)\n', '
 File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/network/neutron.py",
line 294, in _ensure_no_port_binding_failure\n    raise
exception.PortBindingFailed(port_id=port[\'id\'])\n',
'nova.exception.PortBindingFailed: Binding failed for port
b82f4518-ecba-49d9-a21d-2646d3f33efd, please check neutron logs for more
information.\n', '\nDuring handling of the above exception, another
exception occurred:\n\n', 'Traceback (most recent call last):\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/compute/manager.py",
line 2428, in _do_build_and_run_instance\n
 self._build_and_run_instance(context, instance, image,\n', '  File
"/openstack/venvs/nova-0.1.0.dev8112/lib/python3.10/site-packages/nova/compute/manager.py",
line 2703, in _build_and_run_instance\n    raise
exception.RescheduledException(\n', 'nova.exception.RescheduledException:
Build of instance 8760706e-d38f-454d-b90f-b9d5d322ba99 was re-scheduled:
Binding failed for port b82f4518-ecba-49d9-a21d-2646d3f33efd, please check
neutron logs for more information.\n']


All we need is to make sure external networks are routed via gateway-hosts
and not via compute nodes. In our case, compute nodes have only one
physical interface with an IP address and no connectivity to the flat
network. No layer 2 connectivity is available on compute nodes either.
That's the reason why we must traverse external traffic via gateway nodes
only.

It is worth noting that tenant/internal networks work fine.

What are we doing wrong?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/b330d822/attachment-0001.htm>

From ianyrchoi at gmail.com  Wed Sep  6 23:46:51 2023
From: ianyrchoi at gmail.com (Ian Y. Choi)
Date: Thu, 7 Sep 2023 08:46:51 +0900
Subject: [all][elections][ptl][tc] Conbined PTL/TC 2024.1 cycle Election
 Voting Kickoff
Message-ID: <8b4cf482-7598-48c6-bb42-6110bb134970@gmail.com>

Polls for PTL and TC elections are now open and will remain open for
you to cast your vote until Sep 20, 2023 23:45 UTC.

We are selecting 4 TC members, and are having PTL
elections for OpenStack_Helm. Please rank all candidates in
your order of preference.

You are eligible to vote in the TC election if you are a Foundation
individual member[0] that also has committed to any official project
team's deliverable repositories[1] over the Sep 16, 2022 00:00 UTC - Aug 
30, 2023 00:00 UTC
timeframe (2023.1 to 2023.2) or if you are
in the list of extra-atcs[2] for any official project team.

You are eligible to vote in a PTL election if you are a Foundation
individual member[0] and had a commit in one of that team's
deliverable repositories[1] over the Sep 16, 2022 00:00 UTC - Aug 30, 
2023 00:00 UTC timeframe (2023.1 to 2023.2) or if you are in that team's
list of extra-atcs[2].

If you are eligible to vote in an election, you should find your
email with a link to the Condorcet Internet Voting Service (CIVS) page
to cast your vote in the inbox of your Gerrit preferred email[3].

What to do if you don't see the email and have a commit in at
least one of the projects having an election:
* due to a new CIVS policy, to get the email from poll supervisors,
 ??? you must opt in to email communication
 ??? opt in with your Gerrit email address at:
 ??? https://civs1.civs.us/cgi-bin/opt_in.pl
* eligible voters who opt in to email communication late
 ? can see a pending poll invitation and vote
 ? until Sep 20, 2023 23:45 UTC.
* check the trash or spam folders of your Gerrit Preferred
 ??? Email address, in case it went into trash or spam
* wait a bit and check again, in case your email server is a bit slow
* find the sha of at least one commit from the project's deliverable
 ??? repos[0] and email the election officials[4].

If we can confirm that you are entitled to vote, we will add you
to the voters list for the appropriate election.

Our democratic process is important to the health of OpenStack,
please exercise your right to vote!

Candidate statements/platforms can be found linked to Candidate
names on this page:
https://governance.openstack.org/election/

Happy voting,

[0] https://www.openstack.org/community/members/

[1] The list of the repositories eligible for electoral status:
https://opendev.org/openstack/governance/src/tag/0.15.0/reference/projects.yaml

[2] Look for the extra-atcs element in [1]

[3] Sign into review.openstack.org: Go to Settings > Contact
 ??? Information. Look at the email listed as your preferred email.
 ??? That is where the ballot has been sent.

[4] https://governance.openstack.org/election/#election-officials



From ianyrchoi at gmail.com  Thu Sep  7 00:45:19 2023
From: ianyrchoi at gmail.com (Ian Y. Choi)
Date: Thu, 7 Sep 2023 09:45:19 +0900
Subject: [i18n] New I18n SIG Core
Message-ID: <ad6c72a4-23fb-4bc6-ab49-a20662010c13@gmail.com>

Hello,

I would like to happily announce a new i18n core: Seongsoo Cho, 
considering his notable contributions on I18n with volunteering:

1. PDF Docs contribution with I18n issues (font issues, latex with Asian 
languages) [1]
2. Zanata to Weblate migration volunteering effort [2]
3. Participation of I18n SIG PTG on March [3] and Forum on May [4]

Also, he is active on #openstack-i18n IRC channel (nick name: 
"seongsoocho").

All, please welcome Seongsoo as I18n-core.

I am looking forward to more active contributions from him and 
interactions with other wonderful I18n members and OpenStack team!


Thank you,

/Ian

[1] https://review.opendev.org/q/topic:bp%252Fbuild-pdf-from-rst-guides
[2] 
https://lists.openstack.org/pipermail/openstack-i18n/2022-October/003568.html
[3] https://etherpad.opendev.org/p/march2023-ptg-i18n
[4] https://etherpad.opendev.org/p/vancouver-2023-i18n-forum



From ppiyakk2 at printf.kr  Thu Sep  7 01:55:44 2023
From: ppiyakk2 at printf.kr (Seongsoo Cho)
Date: Thu, 7 Sep 2023 10:55:44 +0900
Subject: [OpenStack-I18n] [i18n] New I18n SIG Core
In-Reply-To: <ad6c72a4-23fb-4bc6-ab49-a20662010c13@gmail.com>
References: <ad6c72a4-23fb-4bc6-ab49-a20662010c13@gmail.com>
Message-ID: <CAL2V8z4-EpXwe-zdNV-Zay6-GY2VZizEUyxkUNv06o6ZAkcJEA@mail.gmail.com>

Hello OpenStack Community and i18n team

Thank you for adding me as a new i18n core team member.
As Ian said, I am now working on the i18n SIG to migrate the
translation platform from zanata to weblate.

I will do my best to internationalize OpenInfra in the future.

P.S. Thanks to Ian for always supporting me.

Best regards
Seongsoo

On Thu, Sep 7, 2023 at 9:45?AM Ian Y. Choi <ianyrchoi at gmail.com> wrote:
>
> Hello,
>
> I would like to happily announce a new i18n core: Seongsoo Cho,
> considering his notable contributions on I18n with volunteering:
>
> 1. PDF Docs contribution with I18n issues (font issues, latex with Asian
> languages) [1]
> 2. Zanata to Weblate migration volunteering effort [2]
> 3. Participation of I18n SIG PTG on March [3] and Forum on May [4]
>
> Also, he is active on #openstack-i18n IRC channel (nick name:
> "seongsoocho").
>
> All, please welcome Seongsoo as I18n-core.
>
> I am looking forward to more active contributions from him and
> interactions with other wonderful I18n members and OpenStack team!
>
>
> Thank you,
>
> /Ian
>
> [1] https://review.opendev.org/q/topic:bp%252Fbuild-pdf-from-rst-guides
> [2]
> https://lists.openstack.org/pipermail/openstack-i18n/2022-October/003568.html
> [3] https://etherpad.opendev.org/p/march2023-ptg-i18n
> [4] https://etherpad.opendev.org/p/vancouver-2023-i18n-forum
>
>
> _______________________________________________
> OpenStack-I18n mailing list
> OpenStack-I18n at lists.openstack.org



-- 
Seongsoo Cho
OpenStack Korea User Group / Community Leader
IRC #seongsoocho


From noonedeadpunk at gmail.com  Thu Sep  7 06:20:14 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Thu, 7 Sep 2023 08:20:14 +0200
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
Message-ID: <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>

Hey,

If you are using standalone gateway hosts and compute nodes do not have
access to external networks, I think it is expected that you can not bind a
port from the external network to the VM.
In this case access to the external network is done only through L3 routers.

So the idea is the following:
You attach only a private (geneve) networks to the VMs. Then, you create a
neutron router, which acts as a gateway for the private network, and is
attached to an external network as well. Then you create a floating IP from
the external network and attach it to the port of the VM from the internal
one.  This way you make the external network routed via gateway hosts.

Also, regarding your original issue "The task includes an option with an
undefined variable. The error was: list object has no element 1" - we had
similar case in IRC yesterday, and James Denton has found the workaround
there by defining the br-ex bridge instead of naming it as br-flat, here
was his paste that worked out for the folk:
https://paste.opendev.org/show/bjw3b5ncP6dbhj34ltJU/
He also found an issue in our logic that caused this issue and has proposed
a patch for that:
https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/893924
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/f22e8137/attachment.htm>

From richard.buregeya at bsc.rw  Thu Sep  7 08:29:18 2023
From: richard.buregeya at bsc.rw (Richard Buregeya)
Date: Thu, 7 Sep 2023 08:29:18 +0000
Subject: Windows Image failed to access network
Message-ID: <DBBPR03MB6716A6FD6155D8E276BAFF42F0EEA@DBBPR03MB6716.eurprd03.prod.outlook.com>

Hello Team,

I created the windows image and added the N/w drivers, but it can't be able to get from DHCP.

Any idea?

Regards
Richard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/275d2103/attachment-0001.htm>

From ralonsoh at redhat.com  Thu Sep  7 09:00:41 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Thu, 7 Sep 2023 11:00:41 +0200
Subject: [neutron][release] Proposing transition to EOL Train (Neutron and
 neutron-lib)
Message-ID: <CAECr9X6U-b1LnT5ui6uoP_Oy100cNGLH3ZvCrFx97Pt5eHdROg@mail.gmail.com>

Hello:

I'm sending this mail in advance to propose transitioning the Neutron and
the neutron-lib Train branch to EOL. This topic was proposed and approved
during the last Neutron team meeting [1]. These are the only two Neutron
related projects still in EM.

The announcement is the first step [2] to transition a stable branch to EOL.

The patch to mark these branches as EOL will be pushed in two weeks. If you
have any inconvenience, please let me know in this mail chain or in IRC
(ralonsoh, #openstack-neutron channel). You can also contact any Neutron
core reviewer in the IRC channel.

Regards.

[2]
https://meetings.opendev.org/meetings/networking/2023/networking.2023-09-05-14.00.log.html#l-144
[1]
https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/badb9370/attachment.htm>

From udaydikshit2007 at gmail.com  Thu Sep  7 09:36:24 2023
From: udaydikshit2007 at gmail.com (Uday Dikshit)
Date: Thu, 7 Sep 2023 15:06:24 +0530
Subject: Windows Image failed to access network
In-Reply-To: <DBBPR03MB6716A6FD6155D8E276BAFF42F0EEA@DBBPR03MB6716.eurprd03.prod.outlook.com>
References: <DBBPR03MB6716A6FD6155D8E276BAFF42F0EEA@DBBPR03MB6716.eurprd03.prod.outlook.com>
Message-ID: <CADYZ4k2VKGyse8zT8=OhjpNzey6mi1_POAGZR+Uf=692=jCw-g@mail.gmail.com>

Hello Richard
It will be helpful if you can share some logs from Nova and neutron.

On Thu, Sep 7, 2023, 15:00 Richard Buregeya <richard.buregeya at bsc.rw> wrote:

> Hello Team,
>
>
>
> I created the windows image and added the N/w drivers, but it can?t be
> able to get from DHCP.
>
>
>
> Any idea?
>
>
>
> Regards
>
> Richard.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/6c050bf3/attachment.htm>

From satish.txt at gmail.com  Thu Sep  7 12:03:27 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 7 Sep 2023 08:03:27 -0400
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
Message-ID: <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>

I totally agreed with Sean on all his points but trust me, I have tried
everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
pinning and name it.. but I didn't get any significant improvement. You may
gain 2 to 5% gain with all those tweek. I am running the entire workload on
sriov and life is happy except no LACP bonding.

I am very interesting is this project
https://docs.openvswitch.org/en/latest/intro/install/afxdp/

On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com> wrote:

> Dear Smoney,
>
>
>
> On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
>
>> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
>> > Damn! We have noticed the same issue around 40k to 55k PPS. Trust me
>> > nothing is wrong in your config. This is just a limitation of the
>> software
>> > stack and kernel itself.
>> its partly determined by your cpu frequency.
>> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
>> cpu. with per port troughpuyt being lower dependin on what qos/firewall
>> rules that were apllied.
>>
>>
>
> My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation. I think
> the problem is tuning in the compute node inside. But I cannot find any
> guide or best practices for it.
>
>
>
>> moving form iptables firewall to ovs firewall can help to some degree
>> but your partly trading connection setup time for statead state troughput
>> with the overhead of the connection tracker in ovs.
>>
>> using stateless security groups can help
>>
>> we also recently fixed a regression cause by changes in newer versions of
>> ovs.
>> this was notable in goign form rhel 8 to rhel 9 where litrally it reduced
>> small packet performce to 1/10th and jumboframes to about 1/2
>> on master we have a config option that will set the default qos on a port
>> to linux-noop
>>
>> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>>
>> the backports are propsoed upstream
>> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
>> and we have backported this downstream to adress that performance
>> regression.
>> the upstram backport is semi stalled just ebcasue we wanted to disucss if
>> we shoudl make ti opt in
>> by default upstream while backporting but it might be helpful for you if
>> this is related to yoru current
>> issues.
>>
>> 40-55 kpps is kind of low for kernel ovs but if you have a low clockrate
>> cpu, hybrid_plug + incorrect qos
>> then i could see you hitting such a bottelneck.
>>
>> one workaround by the way without the os-vif workaround backported is to
>> set
>> /proc/sys/net/core/default_qdisc to not apply any qos or a low overhead
>> qos type
>> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>>
>>
>
>> that may or may not help but i would ensure that your are not usign
>> somting like fqdel or cake
>> for net.core.default_qdisc and if you are try changing it to pfifo_fast
>> and see if that helps.
>>
>> there isnet much you can do about the cpu clock rate but ^ is somethign
>> you can try for free
>> note it wont actully take effect on an exsitng vm if you jsut change the
>> default but you can use
>> tc to also chagne the qdisk for testing. hard rebooting the vm shoudl
>> also make the default take effect.
>>
>> the only other advice i can give assuming kernel ovs is the only option
>> you have is
>>
>> to look at
>>
>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>>
>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
>> and
>>
>> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>>
>> if the bottelneck is actully in qemu or the guest kernel rather then ovs
>> adjusting the rx/tx queue size and
>> using multi queue can help. it will have no effect if ovs is the bottel
>> neck.
>>
>>
>>
> I have set this option to 1024, and enable multiqueue as well. But it did
> not help.
>
>
>> >
>> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>> >
>> > > Hi Satish,
>> > >
>> > > Actually, our customer get this issue when the tx/rx above only 40k
>> pps.
>> > > So what is the threshold of this throughput for OvS?
>> > >
>> > >
>> > > Thanks and regards
>> > >
>> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com>
>> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > This is normal because OVS or LinuxBridge wire up VMs using TAP
>> interface
>> > > > which runs on kernel space and that drives higher interrupt and
>> that makes
>> > > > the kernel so busy working on handling packets. Standard
>> OVS/LinuxBridge
>> > > > are not meant for higher PPS.
>> > > >
>> > > > If you want to handle higher PPS then look for DPDK or SRIOV
>> deployment.
>> > > > ( We are running everything in SRIOV because of high PPS
>> requirement)
>> > > >
>> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com>
>> wrote:
>> > > >
>> > > > > Hi everyone,
>> > > > >
>> > > > > I'm using Openstack Train and Openvswitch for ML2 driver and GRE
>> for
>> > > > > tunnel type. I tested our network performance between two VMs and
>> suffer
>> > > > > packet loss as below.
>> > > > >
>> > > > > VM1: IP: 10.20.1.206
>> > > > >
>> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>> > > > >
>> > > > > VM3: IP: 10.20.1.72
>> > > > >
>> > > > >
>> > > > > Using iperf3 to testing performance between VM1 and VM2.
>> > > > >
>> > > > > Run iperf3 client and server on both VMs.
>> > > > >
>> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
>> > > > >
>> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
>> > > > > <https://10.20.1.154/24>
>> > > > >
>> > > > >
>> > > > > Using VM3 ping into VM1, then the packet is lost and the latency
>> is
>> > > > > quite high.
>> > > > >
>> > > > >
>> > > > > ping -i 0.1 10.20.1.206
>> > > > >
>> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>> > > > >
>> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>> > > > >
>> > > > > ^C
>> > > > >
>> > > > > --- 10.20.1.206 ping statistics ---
>> > > > >
>> > > > > 34 packets transmitted, 28 received, 17.6471% packet loss, time
>> 3328ms
>> > > > >
>> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>> > > > >
>> > > > >
>> > > > >
>> > > > > Does any one get this issue ?
>> > > > >
>> > > > > Please help me. Thanks
>> > > > >
>> > > >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/cbea9470/attachment.htm>

From remo at rm.ht  Thu Sep  7 02:59:57 2023
From: remo at rm.ht (Remo Mattei)
Date: Wed, 6 Sep 2023 19:59:57 -0700
Subject: [OpenStack-I18n] [i18n] New I18n SIG Core
In-Reply-To: <CAL2V8z4-EpXwe-zdNV-Zay6-GY2VZizEUyxkUNv06o6ZAkcJEA@mail.gmail.com>
References: <ad6c72a4-23fb-4bc6-ab49-a20662010c13@gmail.com>
 <CAL2V8z4-EpXwe-zdNV-Zay6-GY2VZizEUyxkUNv06o6ZAkcJEA@mail.gmail.com>
Message-ID: <1cf874e2-5ace-4702-91d9-ae526f3ba3d6@Canary>

Well that?s nice!!

Remo

> On Wednesday, Sep 06, 2023 at 18:58, Seongsoo Cho <ppiyakk2 at printf.kr (mailto:ppiyakk2 at printf.kr)> wrote:
> Hello OpenStack Community and i18n team
>
> Thank you for adding me as a new i18n core team member.
> As Ian said, I am now working on the i18n SIG to migrate the
> translation platform from zanata to weblate.
>
> I will do my best to internationalize OpenInfra in the future.
>
> P.S. Thanks to Ian for always supporting me.
>
> Best regards
> Seongsoo
>
> On Thu, Sep 7, 2023 at 9:45?AM Ian Y. Choi <ianyrchoi at gmail.com> wrote:
> >
> > Hello,
> >
> > I would like to happily announce a new i18n core: Seongsoo Cho,
> > considering his notable contributions on I18n with volunteering:
> >
> > 1. PDF Docs contribution with I18n issues (font issues, latex with Asian
> > languages) [1]
> > 2. Zanata to Weblate migration volunteering effort [2]
> > 3. Participation of I18n SIG PTG on March [3] and Forum on May [4]
> >
> > Also, he is active on #openstack-i18n IRC channel (nick name:
> > "seongsoocho").
> >
> > All, please welcome Seongsoo as I18n-core.
> >
> > I am looking forward to more active contributions from him and
> > interactions with other wonderful I18n members and OpenStack team!
> >
> >
> > Thank you,
> >
> > /Ian
> >
> > [1] https://review.opendev.org/q/topic:bp%252Fbuild-pdf-from-rst-guides
> > [2]
> > https://lists.openstack.org/pipermail/openstack-i18n/2022-October/003568.html
> > [3] https://etherpad.opendev.org/p/march2023-ptg-i18n
> > [4] https://etherpad.opendev.org/p/vancouver-2023-i18n-forum
> >
> >
> > _______________________________________________
> > OpenStack-I18n mailing list
> > OpenStack-I18n at lists.openstack.org
>
>
>
> --
> Seongsoo Cho
> OpenStack Korea User Group / Community Leader
> IRC #seongsoocho
>
> _______________________________________________
> OpenStack-I18n mailing list
> OpenStack-I18n at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230906/a2efdcd7/attachment-0001.htm>

From hanoi952022 at gmail.com  Thu Sep  7 10:07:45 2023
From: hanoi952022 at gmail.com (Ha Noi)
Date: Thu, 7 Sep 2023 17:07:45 +0700
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
Message-ID: <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>

Dear Smoney,



On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:

> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
> > Damn! We have noticed the same issue around 40k to 55k PPS. Trust me
> > nothing is wrong in your config. This is just a limitation of the
> software
> > stack and kernel itself.
> its partly determined by your cpu frequency.
> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
> cpu. with per port troughpuyt being lower dependin on what qos/firewall
> rules that were apllied.
>
>

My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation. I think
the problem is tuning in the compute node inside. But I cannot find any
guide or best practices for it.



> moving form iptables firewall to ovs firewall can help to some degree
> but your partly trading connection setup time for statead state troughput
> with the overhead of the connection tracker in ovs.
>
> using stateless security groups can help
>
> we also recently fixed a regression cause by changes in newer versions of
> ovs.
> this was notable in goign form rhel 8 to rhel 9 where litrally it reduced
> small packet performce to 1/10th and jumboframes to about 1/2
> on master we have a config option that will set the default qos on a port
> to linux-noop
>
> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>
> the backports are propsoed upstream
> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
> and we have backported this downstream to adress that performance
> regression.
> the upstram backport is semi stalled just ebcasue we wanted to disucss if
> we shoudl make ti opt in
> by default upstream while backporting but it might be helpful for you if
> this is related to yoru current
> issues.
>
> 40-55 kpps is kind of low for kernel ovs but if you have a low clockrate
> cpu, hybrid_plug + incorrect qos
> then i could see you hitting such a bottelneck.
>
> one workaround by the way without the os-vif workaround backported is to
> set
> /proc/sys/net/core/default_qdisc to not apply any qos or a low overhead
> qos type
> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>
>

> that may or may not help but i would ensure that your are not usign
> somting like fqdel or cake
> for net.core.default_qdisc and if you are try changing it to pfifo_fast
> and see if that helps.
>
> there isnet much you can do about the cpu clock rate but ^ is somethign
> you can try for free
> note it wont actully take effect on an exsitng vm if you jsut change the
> default but you can use
> tc to also chagne the qdisk for testing. hard rebooting the vm shoudl also
> make the default take effect.
>
> the only other advice i can give assuming kernel ovs is the only option
> you have is
>
> to look at
>
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
> and
>
> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>
> if the bottelneck is actully in qemu or the guest kernel rather then ovs
> adjusting the rx/tx queue size and
> using multi queue can help. it will have no effect if ovs is the bottel
> neck.
>
>
>
I have set this option to 1024, and enable multiqueue as well. But it did
not help.


> >
> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com> wrote:
> >
> > > Hi Satish,
> > >
> > > Actually, our customer get this issue when the tx/rx above only 40k
> pps.
> > > So what is the threshold of this throughput for OvS?
> > >
> > >
> > > Thanks and regards
> > >
> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > This is normal because OVS or LinuxBridge wire up VMs using TAP
> interface
> > > > which runs on kernel space and that drives higher interrupt and that
> makes
> > > > the kernel so busy working on handling packets. Standard
> OVS/LinuxBridge
> > > > are not meant for higher PPS.
> > > >
> > > > If you want to handle higher PPS then look for DPDK or SRIOV
> deployment.
> > > > ( We are running everything in SRIOV because of high PPS requirement)
> > > >
> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com>
> wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > I'm using Openstack Train and Openvswitch for ML2 driver and GRE
> for
> > > > > tunnel type. I tested our network performance between two VMs and
> suffer
> > > > > packet loss as below.
> > > > >
> > > > > VM1: IP: 10.20.1.206
> > > > >
> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
> > > > >
> > > > > VM3: IP: 10.20.1.72
> > > > >
> > > > >
> > > > > Using iperf3 to testing performance between VM1 and VM2.
> > > > >
> > > > > Run iperf3 client and server on both VMs.
> > > > >
> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
> > > > >
> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
> > > > > <https://10.20.1.154/24>
> > > > >
> > > > >
> > > > > Using VM3 ping into VM1, then the packet is lost and the latency is
> > > > > quite high.
> > > > >
> > > > >
> > > > > ping -i 0.1 10.20.1.206
> > > > >
> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
> > > > >
> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
> > > > >
> > > > > ^C
> > > > >
> > > > > --- 10.20.1.206 ping statistics ---
> > > > >
> > > > > 34 packets transmitted, 28 received, 17.6471% packet loss, time
> 3328ms
> > > > >
> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
> > > > >
> > > > >
> > > > >
> > > > > Does any one get this issue ?
> > > > >
> > > > > Please help me. Thanks
> > > > >
> > > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/7b5c613c/attachment-0001.htm>

From hanoi952022 at gmail.com  Thu Sep  7 12:06:02 2023
From: hanoi952022 at gmail.com (Ha Noi)
Date: Thu, 7 Sep 2023 19:06:02 +0700
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
Message-ID: <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>

Hi Satish,

Why dont you use DPDK?

Thanks

On Thu, 7 Sep 2023 at 19:03 Satish Patel <satish.txt at gmail.com> wrote:

> I totally agreed with Sean on all his points but trust me, I have tried
> everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
> pinning and name it.. but I didn't get any significant improvement. You may
> gain 2 to 5% gain with all those tweek. I am running the entire workload on
> sriov and life is happy except no LACP bonding.
>
> I am very interesting is this project
> https://docs.openvswitch.org/en/latest/intro/install/afxdp/
>
> On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>
>> Dear Smoney,
>>
>>
>>
>> On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
>>
>>> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
>>> > Damn! We have noticed the same issue around 40k to 55k PPS. Trust me
>>> > nothing is wrong in your config. This is just a limitation of the
>>> software
>>> > stack and kernel itself.
>>> its partly determined by your cpu frequency.
>>> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
>>> cpu. with per port troughpuyt being lower dependin on what qos/firewall
>>> rules that were apllied.
>>>
>>>
>>
>> My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation. I think
>> the problem is tuning in the compute node inside. But I cannot find any
>> guide or best practices for it.
>>
>>
>>
>>> moving form iptables firewall to ovs firewall can help to some degree
>>> but your partly trading connection setup time for statead state troughput
>>> with the overhead of the connection tracker in ovs.
>>>
>>> using stateless security groups can help
>>>
>>> we also recently fixed a regression cause by changes in newer versions
>>> of ovs.
>>> this was notable in goign form rhel 8 to rhel 9 where litrally it reduced
>>> small packet performce to 1/10th and jumboframes to about 1/2
>>> on master we have a config option that will set the default qos on a
>>> port to linux-noop
>>>
>>> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>>>
>>> the backports are propsoed upstream
>>> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
>>> and we have backported this downstream to adress that performance
>>> regression.
>>> the upstram backport is semi stalled just ebcasue we wanted to disucss
>>> if we shoudl make ti opt in
>>> by default upstream while backporting but it might be helpful for you if
>>> this is related to yoru current
>>> issues.
>>>
>>> 40-55 kpps is kind of low for kernel ovs but if you have a low clockrate
>>> cpu, hybrid_plug + incorrect qos
>>> then i could see you hitting such a bottelneck.
>>>
>>> one workaround by the way without the os-vif workaround backported is to
>>> set
>>> /proc/sys/net/core/default_qdisc to not apply any qos or a low overhead
>>> qos type
>>> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>>>
>>>
>>
>>> that may or may not help but i would ensure that your are not usign
>>> somting like fqdel or cake
>>> for net.core.default_qdisc and if you are try changing it to pfifo_fast
>>> and see if that helps.
>>>
>>> there isnet much you can do about the cpu clock rate but ^ is somethign
>>> you can try for free
>>> note it wont actully take effect on an exsitng vm if you jsut change the
>>> default but you can use
>>> tc to also chagne the qdisk for testing. hard rebooting the vm shoudl
>>> also make the default take effect.
>>>
>>> the only other advice i can give assuming kernel ovs is the only option
>>> you have is
>>>
>>> to look at
>>>
>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>>>
>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
>>> and
>>>
>>> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>>>
>>> if the bottelneck is actully in qemu or the guest kernel rather then ovs
>>> adjusting the rx/tx queue size and
>>> using multi queue can help. it will have no effect if ovs is the bottel
>>> neck.
>>>
>>>
>>>
>> I have set this option to 1024, and enable multiqueue as well. But it did
>> not help.
>>
>>
>>> >
>>> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>> >
>>> > > Hi Satish,
>>> > >
>>> > > Actually, our customer get this issue when the tx/rx above only 40k
>>> pps.
>>> > > So what is the threshold of this throughput for OvS?
>>> > >
>>> > >
>>> > > Thanks and regards
>>> > >
>>> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com>
>>> wrote:
>>> > >
>>> > > > Hi,
>>> > > >
>>> > > > This is normal because OVS or LinuxBridge wire up VMs using TAP
>>> interface
>>> > > > which runs on kernel space and that drives higher interrupt and
>>> that makes
>>> > > > the kernel so busy working on handling packets. Standard
>>> OVS/LinuxBridge
>>> > > > are not meant for higher PPS.
>>> > > >
>>> > > > If you want to handle higher PPS then look for DPDK or SRIOV
>>> deployment.
>>> > > > ( We are running everything in SRIOV because of high PPS
>>> requirement)
>>> > > >
>>> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com>
>>> wrote:
>>> > > >
>>> > > > > Hi everyone,
>>> > > > >
>>> > > > > I'm using Openstack Train and Openvswitch for ML2 driver and GRE
>>> for
>>> > > > > tunnel type. I tested our network performance between two VMs
>>> and suffer
>>> > > > > packet loss as below.
>>> > > > >
>>> > > > > VM1: IP: 10.20.1.206
>>> > > > >
>>> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>> > > > >
>>> > > > > VM3: IP: 10.20.1.72
>>> > > > >
>>> > > > >
>>> > > > > Using iperf3 to testing performance between VM1 and VM2.
>>> > > > >
>>> > > > > Run iperf3 client and server on both VMs.
>>> > > > >
>>> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
>>> > > > >
>>> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
>>> > > > > <https://10.20.1.154/24>
>>> > > > >
>>> > > > >
>>> > > > > Using VM3 ping into VM1, then the packet is lost and the latency
>>> is
>>> > > > > quite high.
>>> > > > >
>>> > > > >
>>> > > > > ping -i 0.1 10.20.1.206
>>> > > > >
>>> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>>> > > > >
>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>>> > > > >
>>> > > > > ^C
>>> > > > >
>>> > > > > --- 10.20.1.206 ping statistics ---
>>> > > > >
>>> > > > > 34 packets transmitted, 28 received, 17.6471% packet loss, time
>>> 3328ms
>>> > > > >
>>> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > Does any one get this issue ?
>>> > > > >
>>> > > > > Please help me. Thanks
>>> > > > >
>>> > > >
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/ceafe1be/attachment-0001.htm>

From pdeore at redhat.com  Thu Sep  7 13:30:21 2023
From: pdeore at redhat.com (Pranali Deore)
Date: Thu, 7 Sep 2023 19:00:21 +0530
Subject: [Glance] Cancelling Weekly Meeting 7th Sept
Message-ID: <CADkbuWj9EwD4VYFETV-PnVbDOpD1r1WwCdh8a02bX1rQCJsAgg@mail.gmail.com>

Hello,

I won't be able to chair today's meeting, my kid is not well, going to take
him to the doctor.
so cancelling the meeting for this week.

Let's meet next week !


Thanks,
Pranali D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/85fbaa40/attachment.htm>

From satish.txt at gmail.com  Thu Sep  7 15:13:16 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 7 Sep 2023 11:13:16 -0400
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
 <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
Message-ID: <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>

Because DPDK required DPDK support inside guest VM. It's not suitable for
general purpose workload. You need your guest VM network to support DPDK to
get 100% throughput.

On Thu, Sep 7, 2023 at 8:06?AM Ha Noi <hanoi952022 at gmail.com> wrote:

> Hi Satish,
>
> Why dont you use DPDK?
>
> Thanks
>
> On Thu, 7 Sep 2023 at 19:03 Satish Patel <satish.txt at gmail.com> wrote:
>
>> I totally agreed with Sean on all his points but trust me, I have tried
>> everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
>> pinning and name it.. but I didn't get any significant improvement. You may
>> gain 2 to 5% gain with all those tweek. I am running the entire workload on
>> sriov and life is happy except no LACP bonding.
>>
>> I am very interesting is this project
>> https://docs.openvswitch.org/en/latest/intro/install/afxdp/
>>
>> On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>
>>> Dear Smoney,
>>>
>>>
>>>
>>> On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
>>>
>>>> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
>>>> > Damn! We have noticed the same issue around 40k to 55k PPS. Trust me
>>>> > nothing is wrong in your config. This is just a limitation of the
>>>> software
>>>> > stack and kernel itself.
>>>> its partly determined by your cpu frequency.
>>>> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
>>>> cpu. with per port troughpuyt being lower dependin on what qos/firewall
>>>> rules that were apllied.
>>>>
>>>>
>>>
>>> My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation. I
>>> think the problem is tuning in the compute node inside. But I cannot find
>>> any guide or best practices for it.
>>>
>>>
>>>
>>>> moving form iptables firewall to ovs firewall can help to some degree
>>>> but your partly trading connection setup time for statead state
>>>> troughput
>>>> with the overhead of the connection tracker in ovs.
>>>>
>>>> using stateless security groups can help
>>>>
>>>> we also recently fixed a regression cause by changes in newer versions
>>>> of ovs.
>>>> this was notable in goign form rhel 8 to rhel 9 where litrally it
>>>> reduced
>>>> small packet performce to 1/10th and jumboframes to about 1/2
>>>> on master we have a config option that will set the default qos on a
>>>> port to linux-noop
>>>>
>>>> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>>>>
>>>> the backports are propsoed upstream
>>>> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
>>>> and we have backported this downstream to adress that performance
>>>> regression.
>>>> the upstram backport is semi stalled just ebcasue we wanted to disucss
>>>> if we shoudl make ti opt in
>>>> by default upstream while backporting but it might be helpful for you
>>>> if this is related to yoru current
>>>> issues.
>>>>
>>>> 40-55 kpps is kind of low for kernel ovs but if you have a low
>>>> clockrate cpu, hybrid_plug + incorrect qos
>>>> then i could see you hitting such a bottelneck.
>>>>
>>>> one workaround by the way without the os-vif workaround backported is
>>>> to set
>>>> /proc/sys/net/core/default_qdisc to not apply any qos or a low overhead
>>>> qos type
>>>> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>>>>
>>>>
>>>
>>>> that may or may not help but i would ensure that your are not usign
>>>> somting like fqdel or cake
>>>> for net.core.default_qdisc and if you are try changing it to pfifo_fast
>>>> and see if that helps.
>>>>
>>>> there isnet much you can do about the cpu clock rate but ^ is somethign
>>>> you can try for free
>>>> note it wont actully take effect on an exsitng vm if you jsut change
>>>> the default but you can use
>>>> tc to also chagne the qdisk for testing. hard rebooting the vm shoudl
>>>> also make the default take effect.
>>>>
>>>> the only other advice i can give assuming kernel ovs is the only option
>>>> you have is
>>>>
>>>> to look at
>>>>
>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>>>>
>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
>>>> and
>>>>
>>>> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>>>>
>>>> if the bottelneck is actully in qemu or the guest kernel rather then
>>>> ovs adjusting the rx/tx queue size and
>>>> using multi queue can help. it will have no effect if ovs is the bottel
>>>> neck.
>>>>
>>>>
>>>>
>>> I have set this option to 1024, and enable multiqueue as well. But it
>>> did not help.
>>>
>>>
>>>> >
>>>> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>> >
>>>> > > Hi Satish,
>>>> > >
>>>> > > Actually, our customer get this issue when the tx/rx above only 40k
>>>> pps.
>>>> > > So what is the threshold of this throughput for OvS?
>>>> > >
>>>> > >
>>>> > > Thanks and regards
>>>> > >
>>>> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com>
>>>> wrote:
>>>> > >
>>>> > > > Hi,
>>>> > > >
>>>> > > > This is normal because OVS or LinuxBridge wire up VMs using TAP
>>>> interface
>>>> > > > which runs on kernel space and that drives higher interrupt and
>>>> that makes
>>>> > > > the kernel so busy working on handling packets. Standard
>>>> OVS/LinuxBridge
>>>> > > > are not meant for higher PPS.
>>>> > > >
>>>> > > > If you want to handle higher PPS then look for DPDK or SRIOV
>>>> deployment.
>>>> > > > ( We are running everything in SRIOV because of high PPS
>>>> requirement)
>>>> > > >
>>>> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com>
>>>> wrote:
>>>> > > >
>>>> > > > > Hi everyone,
>>>> > > > >
>>>> > > > > I'm using Openstack Train and Openvswitch for ML2 driver and
>>>> GRE for
>>>> > > > > tunnel type. I tested our network performance between two VMs
>>>> and suffer
>>>> > > > > packet loss as below.
>>>> > > > >
>>>> > > > > VM1: IP: 10.20.1.206
>>>> > > > >
>>>> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>>> > > > >
>>>> > > > > VM3: IP: 10.20.1.72
>>>> > > > >
>>>> > > > >
>>>> > > > > Using iperf3 to testing performance between VM1 and VM2.
>>>> > > > >
>>>> > > > > Run iperf3 client and server on both VMs.
>>>> > > > >
>>>> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
>>>> > > > >
>>>> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
>>>> > > > > <https://10.20.1.154/24>
>>>> > > > >
>>>> > > > >
>>>> > > > > Using VM3 ping into VM1, then the packet is lost and the
>>>> latency is
>>>> > > > > quite high.
>>>> > > > >
>>>> > > > >
>>>> > > > > ping -i 0.1 10.20.1.206
>>>> > > > >
>>>> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>>>> > > > >
>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>>>> > > > >
>>>> > > > > ^C
>>>> > > > >
>>>> > > > > --- 10.20.1.206 ping statistics ---
>>>> > > > >
>>>> > > > > 34 packets transmitted, 28 received, 17.6471% packet loss, time
>>>> 3328ms
>>>> > > > >
>>>> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>>> > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > > Does any one get this issue ?
>>>> > > > >
>>>> > > > > Please help me. Thanks
>>>> > > > >
>>>> > > >
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/ac05d93f/attachment-0001.htm>

From gmann at ghanshyammann.com  Thu Sep  7 15:35:47 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 07 Sep 2023 08:35:47 -0700
Subject: [OpenStack-I18n] [i18n] New I18n SIG Core
In-Reply-To: <CAL2V8z4-EpXwe-zdNV-Zay6-GY2VZizEUyxkUNv06o6ZAkcJEA@mail.gmail.com>
References: <ad6c72a4-23fb-4bc6-ab49-a20662010c13@gmail.com>
 <CAL2V8z4-EpXwe-zdNV-Zay6-GY2VZizEUyxkUNv06o6ZAkcJEA@mail.gmail.com>
Message-ID: <18a70490102.ff8e772d643566.6427525976911462058@ghanshyammann.com>

Thanks, Seongsoo, for help here and Ian too

-gmann

 ---- On Wed, 06 Sep 2023 18:55:44 -0700  Seongsoo Cho  wrote --- 
 > Hello OpenStack Community and i18n team
 > 
 > Thank you for adding me as a new i18n core team member.
 > As Ian said, I am now working on the i18n SIG to migrate the
 > translation platform from zanata to weblate.
 > 
 > I will do my best to internationalize OpenInfra in the future.
 > 
 > P.S. Thanks to Ian for always supporting me.
 > 
 > Best regards
 > Seongsoo
 > 
 > On Thu, Sep 7, 2023 at 9:45?AM Ian Y. Choi ianyrchoi at gmail.com> wrote:
 > >
 > > Hello,
 > >
 > > I would like to happily announce a new i18n core: Seongsoo Cho,
 > > considering his notable contributions on I18n with volunteering:
 > >
 > > 1. PDF Docs contribution with I18n issues (font issues, latex with Asian
 > > languages) [1]
 > > 2. Zanata to Weblate migration volunteering effort [2]
 > > 3. Participation of I18n SIG PTG on March [3] and Forum on May [4]
 > >
 > > Also, he is active on #openstack-i18n IRC channel (nick name:
 > > "seongsoocho").
 > >
 > > All, please welcome Seongsoo as I18n-core.
 > >
 > > I am looking forward to more active contributions from him and
 > > interactions with other wonderful I18n members and OpenStack team!
 > >
 > >
 > > Thank you,
 > >
 > > /Ian
 > >
 > > [1] https://review.opendev.org/q/topic:bp%252Fbuild-pdf-from-rst-guides
 > > [2]
 > > https://lists.openstack.org/pipermail/openstack-i18n/2022-October/003568.html
 > > [3] https://etherpad.opendev.org/p/march2023-ptg-i18n
 > > [4] https://etherpad.opendev.org/p/vancouver-2023-i18n-forum
 > >
 > >
 > > _______________________________________________
 > > OpenStack-I18n mailing list
 > > OpenStack-I18n at lists.openstack.org
 > 
 > 
 > 
 > -- 
 > Seongsoo Cho
 > OpenStack Korea User Group / Community Leader
 > IRC #seongsoocho
 > 
 > 


From gmann at ghanshyammann.com  Thu Sep  7 16:03:52 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 07 Sep 2023 09:03:52 -0700
Subject: [all][tc] python 3.11 testing plan
In-Reply-To: <18a19500dda.1179e4341294220.8475553822244831650@ghanshyammann.com>
References: <18a19500dda.1179e4341294220.8475553822244831650@ghanshyammann.com>
Message-ID: <18a7062b69d.d3f024e6645938.1764325247310912451@ghanshyammann.com>

 ---- On Mon, 21 Aug 2023 11:16:31 -0700  Ghanshyam Mann  wrote --- 
 > 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.

Hello Everyone,

Many projects still need to fix the py3.11 job[1]. I started fixing a few of them, so changes are up
for review of those projects.

NOTE: The deadline to fix is the 2023.2 release (Oct 6th); after that, this job will become voting on the
master (2024.1 dev cycle but remain non-voting on stable/2023.2) and will block the master gate.

[1] https://zuul.openstack.org/builds?job_name=openstack-tox-py311+&result=RETRY_LIMIT&result=RETRY&result=CONFIG_ERROR&result=FAILURE&skip=0&limit=100


-gmann

 > 
 > 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
 > 
 > 


From mihalis68 at gmail.com  Thu Sep  7 17:26:08 2023
From: mihalis68 at gmail.com (Chris Morgan)
Date: Thu, 7 Sep 2023 13:26:08 -0400
Subject: [ops]
Message-ID: <CA+NmNoPPxBu2aDR5Sx9GEOwcAM09BUJLYcqr4BJqUUQA-W9vfQ@mail.gmail.com>

I'm trying to reanimate the openstack ops meetups. I moved the social media
account used for notifications from X to mastodon (using the fosstodon
instance). Please follow there if interested (link below). I also posted a
similar announcement to the openstack group on linkedin. One of the first
tasks (besides reforming the team) is finding which communications channels
actually work.

https://fosstodon.org/@osopsmeetup

The old account was here

https://twitter.com/osopsmeetup

now "sepia-tinted" because it's just historical.

Cheers,

Chris

-- 
Chris Morgan <mihalis68 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/db275da1/attachment.htm>

From roger.riverac at gmail.com  Thu Sep  7 17:30:03 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Thu, 7 Sep 2023 13:30:03 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
Message-ID: <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>

Hello Dimitry,

Thanks again for your help. Unfortunately, we've tried everything that's
been suggested to no avail. And it seems plausible that external
connectivity will not be achieved on the compute nodes if there are no
bridges mapped to the external network on those hosts. Keep in mind these
compute hosts do not have the ens2 physical interface to bind the ext-br or
br-flat bridges to.

Having said that, we would have loved to see a complete OVN scenario
reference configuration with dedicated networking/gateway nodes.

The documentation we have reviewed assumes compute nodes as gateways and
that bridges can be set up on compute nodes, which is not our case. We are
relying 100% on a single L3 interface on compute nodes with GENEVE as a
tunneling protocol. And it is because of GENEVE that private east/west
traffic works without a problem.

Only networking nodes have that second ens2 network interface that
physically connects to the external network, hence the need to make those
chassis as gateway nodes.

Again, our setup has the following configuration:

-Compute nodes with x1 L3 NIC and IP.
-Network/gateway nodes with x1 L3 NIC and x1 L2 NIC with connection to
external network.


Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/14fc484a/attachment.htm>

From noonedeadpunk at gmail.com  Thu Sep  7 17:45:59 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Thu, 7 Sep 2023 19:45:59 +0200
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
Message-ID: <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>

I'm not a huge expert in OVN, but I believe this specific part works in
pretty much the same way for OVS and LXB.

We have exactly same usecase as you do, but with OVS for now. And the only
way to get external connectivity is to create neutron router, which will be
used as a gateway to public networks. And router should be created on OVN
gateway nodes from what I know. So your VMs always have only geneve
network, that is passed inside the router, and then router connected to
external network on gateway nodes.

Floating IP is kind of 1-to-1 NAT on the router, which allows to access
your VM through external network (and router).

Attaching public network to the VM directly in your scenario should not be
possible by design.

Feel free to join us on #openstack-ansible channel on OFTC IRC network and
we will be glad to answer your questions.


On Thu, Sep 7, 2023, 19:30 Roger Rivera <roger.riverac at gmail.com> wrote:

> Hello Dimitry,
>
> Thanks again for your help. Unfortunately, we've tried everything that's
> been suggested to no avail. And it seems plausible that external
> connectivity will not be achieved on the compute nodes if there are no
> bridges mapped to the external network on those hosts. Keep in mind these
> compute hosts do not have the ens2 physical interface to bind the ext-br or
> br-flat bridges to.
>
> Having said that, we would have loved to see a complete OVN scenario
> reference configuration with dedicated networking/gateway nodes.
>
> The documentation we have reviewed assumes compute nodes as gateways and
> that bridges can be set up on compute nodes, which is not our case. We are
> relying 100% on a single L3 interface on compute nodes with GENEVE as a
> tunneling protocol. And it is because of GENEVE that private east/west
> traffic works without a problem.
>
> Only networking nodes have that second ens2 network interface that
> physically connects to the external network, hence the need to make those
> chassis as gateway nodes.
>
> Again, our setup has the following configuration:
>
> -Compute nodes with x1 L3 NIC and IP.
> -Network/gateway nodes with x1 L3 NIC and x1 L2 NIC with connection to
> external network.
>
>
> Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/bd3ca4c1/attachment-0001.htm>

From james.denton at rackspace.com  Thu Sep  7 19:17:48 2023
From: james.denton at rackspace.com (James Denton)
Date: Thu, 7 Sep 2023 19:17:48 +0000
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
 <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
Message-ID: <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>

Hi Roger,

I believe there is an expectation that if a compute node will host a router or instance connected to a VLAN (provider or tenant network), it should have the provider network interface plumbed to it (and mapped accordingly). On the compute, you can get look at the external_ids field of the ?ovs-vsctl list open_vswitch? output and see ovn-bridge-mappings populated. If it?s also a gateway node, you?d see ?ovn-cms-options=enable-chassis-as-gw?. The consensus among those I?ve talked to in the past is that network nodes should be gateway nodes, rather than enabling the compute nodes to also be gateway nodes. Others might feel differently.

There are some things you can do with the neutron provider setup in OSA to treat network/gateway nodes differently from compute nodes from a plumbing POV; heterogenous vs homogenous network and bridge configuration. This doc, https://docs.openstack.org/openstack-ansible/latest/user/prod/provnet_groups.html, might help ? but don?t hesitate to ask for more help if that?s what you?re looking for.

--
James Denton
Principal Architect
Rackspace Private Cloud - OpenStack
james.denton at rackspace.com

From: Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
Date: Thursday, September 7, 2023 at 12:46 PM
To: Roger Rivera <roger.riverac at gmail.com>
Cc: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [openstack-ansible] Dedicated gateway hosts not working with OVN
CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!

I'm not a huge expert in OVN, but I believe this specific part works in pretty much the same way for OVS and LXB.

We have exactly same usecase as you do, but with OVS for now. And the only way to get external connectivity is to create neutron router, which will be used as a gateway to public networks. And router should be created on OVN gateway nodes from what I know. So your VMs always have only geneve network, that is passed inside the router, and then router connected to external network on gateway nodes.

Floating IP is kind of 1-to-1 NAT on the router, which allows to access your VM through external network (and router).

Attaching public network to the VM directly in your scenario should not be possible by design.

Feel free to join us on #openstack-ansible channel on OFTC IRC network and we will be glad to answer your questions.

On Thu, Sep 7, 2023, 19:30 Roger Rivera <roger.riverac at gmail.com<mailto:roger.riverac at gmail.com>> wrote:
Hello Dimitry,

Thanks again for your help. Unfortunately, we've tried everything that's been suggested to no avail. And it seems plausible that external connectivity will not be achieved on the compute nodes if there are no bridges mapped to the external network on those hosts. Keep in mind these compute hosts do not have the ens2 physical interface to bind the ext-br or br-flat bridges to.

Having said that, we would have loved to see a complete OVN scenario reference configuration with dedicated networking/gateway nodes.

The documentation we have reviewed assumes compute nodes as gateways and that bridges can be set up on compute nodes, which is not our case. We are relying 100% on a single L3 interface on compute nodes with GENEVE as a tunneling protocol. And it is because of GENEVE that private east/west traffic works without a problem.

Only networking nodes have that second ens2 network interface that physically connects to the external network, hence the need to make those chassis as gateway nodes.

Again, our setup has the following configuration:

-Compute nodes with x1 L3 NIC and IP.
-Network/gateway nodes with x1 L3 NIC and x1 L2 NIC with connection to external network.


Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/0b5c81fd/attachment.htm>

From hanoi952022 at gmail.com  Thu Sep  7 21:27:42 2023
From: hanoi952022 at gmail.com (Ha Noi)
Date: Fri, 8 Sep 2023 04:27:42 +0700
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
 <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
 <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>
Message-ID: <CAPTyaN_Ni_TnNuxgtK5C8nDL2v9J2S9uj3i-g_EaWk62VWPJjA@mail.gmail.com>

Oh. I heard from someone on the reddit said that Ovs-dpdk is transparent
with user?

So It?s not correct?

On Thu, 7 Sep 2023 at 22:13 Satish Patel <satish.txt at gmail.com> wrote:

> Because DPDK required DPDK support inside guest VM. It's not suitable for
> general purpose workload. You need your guest VM network to support DPDK to
> get 100% throughput.
>
> On Thu, Sep 7, 2023 at 8:06?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>
>> Hi Satish,
>>
>> Why dont you use DPDK?
>>
>> Thanks
>>
>> On Thu, 7 Sep 2023 at 19:03 Satish Patel <satish.txt at gmail.com> wrote:
>>
>>> I totally agreed with Sean on all his points but trust me, I have tried
>>> everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
>>> pinning and name it.. but I didn't get any significant improvement. You may
>>> gain 2 to 5% gain with all those tweek. I am running the entire workload on
>>> sriov and life is happy except no LACP bonding.
>>>
>>> I am very interesting is this project
>>> https://docs.openvswitch.org/en/latest/intro/install/afxdp/
>>>
>>> On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>
>>>> Dear Smoney,
>>>>
>>>>
>>>>
>>>> On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
>>>>
>>>>> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
>>>>> > Damn! We have noticed the same issue around 40k to 55k PPS. Trust me
>>>>> > nothing is wrong in your config. This is just a limitation of the
>>>>> software
>>>>> > stack and kernel itself.
>>>>> its partly determined by your cpu frequency.
>>>>> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
>>>>> cpu. with per port troughpuyt being lower dependin on what qos/firewall
>>>>> rules that were apllied.
>>>>>
>>>>>
>>>>
>>>> My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation. I
>>>> think the problem is tuning in the compute node inside. But I cannot find
>>>> any guide or best practices for it.
>>>>
>>>>
>>>>
>>>>> moving form iptables firewall to ovs firewall can help to some degree
>>>>> but your partly trading connection setup time for statead state
>>>>> troughput
>>>>> with the overhead of the connection tracker in ovs.
>>>>>
>>>>> using stateless security groups can help
>>>>>
>>>>> we also recently fixed a regression cause by changes in newer versions
>>>>> of ovs.
>>>>> this was notable in goign form rhel 8 to rhel 9 where litrally it
>>>>> reduced
>>>>> small packet performce to 1/10th and jumboframes to about 1/2
>>>>> on master we have a config option that will set the default qos on a
>>>>> port to linux-noop
>>>>>
>>>>> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>>>>>
>>>>> the backports are propsoed upstream
>>>>> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
>>>>> and we have backported this downstream to adress that performance
>>>>> regression.
>>>>> the upstram backport is semi stalled just ebcasue we wanted to disucss
>>>>> if we shoudl make ti opt in
>>>>> by default upstream while backporting but it might be helpful for you
>>>>> if this is related to yoru current
>>>>> issues.
>>>>>
>>>>> 40-55 kpps is kind of low for kernel ovs but if you have a low
>>>>> clockrate cpu, hybrid_plug + incorrect qos
>>>>> then i could see you hitting such a bottelneck.
>>>>>
>>>>> one workaround by the way without the os-vif workaround backported is
>>>>> to set
>>>>> /proc/sys/net/core/default_qdisc to not apply any qos or a low
>>>>> overhead qos type
>>>>> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>>>>>
>>>>>
>>>>
>>>>> that may or may not help but i would ensure that your are not usign
>>>>> somting like fqdel or cake
>>>>> for net.core.default_qdisc and if you are try changing it to
>>>>> pfifo_fast and see if that helps.
>>>>>
>>>>> there isnet much you can do about the cpu clock rate but ^ is
>>>>> somethign you can try for free
>>>>> note it wont actully take effect on an exsitng vm if you jsut change
>>>>> the default but you can use
>>>>> tc to also chagne the qdisk for testing. hard rebooting the vm shoudl
>>>>> also make the default take effect.
>>>>>
>>>>> the only other advice i can give assuming kernel ovs is the only
>>>>> option you have is
>>>>>
>>>>> to look at
>>>>>
>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>>>>>
>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
>>>>> and
>>>>>
>>>>> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>>>>>
>>>>> if the bottelneck is actully in qemu or the guest kernel rather then
>>>>> ovs adjusting the rx/tx queue size and
>>>>> using multi queue can help. it will have no effect if ovs is the
>>>>> bottel neck.
>>>>>
>>>>>
>>>>>
>>>> I have set this option to 1024, and enable multiqueue as well. But it
>>>> did not help.
>>>>
>>>>
>>>>> >
>>>>> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>>> >
>>>>> > > Hi Satish,
>>>>> > >
>>>>> > > Actually, our customer get this issue when the tx/rx above only
>>>>> 40k pps.
>>>>> > > So what is the threshold of this throughput for OvS?
>>>>> > >
>>>>> > >
>>>>> > > Thanks and regards
>>>>> > >
>>>>> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com>
>>>>> wrote:
>>>>> > >
>>>>> > > > Hi,
>>>>> > > >
>>>>> > > > This is normal because OVS or LinuxBridge wire up VMs using TAP
>>>>> interface
>>>>> > > > which runs on kernel space and that drives higher interrupt and
>>>>> that makes
>>>>> > > > the kernel so busy working on handling packets. Standard
>>>>> OVS/LinuxBridge
>>>>> > > > are not meant for higher PPS.
>>>>> > > >
>>>>> > > > If you want to handle higher PPS then look for DPDK or SRIOV
>>>>> deployment.
>>>>> > > > ( We are running everything in SRIOV because of high PPS
>>>>> requirement)
>>>>> > > >
>>>>> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com>
>>>>> wrote:
>>>>> > > >
>>>>> > > > > Hi everyone,
>>>>> > > > >
>>>>> > > > > I'm using Openstack Train and Openvswitch for ML2 driver and
>>>>> GRE for
>>>>> > > > > tunnel type. I tested our network performance between two VMs
>>>>> and suffer
>>>>> > > > > packet loss as below.
>>>>> > > > >
>>>>> > > > > VM1: IP: 10.20.1.206
>>>>> > > > >
>>>>> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>>>> > > > >
>>>>> > > > > VM3: IP: 10.20.1.72
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > Using iperf3 to testing performance between VM1 and VM2.
>>>>> > > > >
>>>>> > > > > Run iperf3 client and server on both VMs.
>>>>> > > > >
>>>>> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
>>>>> > > > >
>>>>> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
>>>>> > > > > <https://10.20.1.154/24>
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > Using VM3 ping into VM1, then the packet is lost and the
>>>>> latency is
>>>>> > > > > quite high.
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > ping -i 0.1 10.20.1.206
>>>>> > > > >
>>>>> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>>>>> > > > >
>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>>>>> > > > >
>>>>> > > > > ^C
>>>>> > > > >
>>>>> > > > > --- 10.20.1.206 ping statistics ---
>>>>> > > > >
>>>>> > > > > 34 packets transmitted, 28 received, 17.6471% packet loss,
>>>>> time 3328ms
>>>>> > > > >
>>>>> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>>>> > > > >
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > Does any one get this issue ?
>>>>> > > > >
>>>>> > > > > Please help me. Thanks
>>>>> > > > >
>>>>> > > >
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/c67f2a72/attachment-0001.htm>

From roger.riverac at gmail.com  Thu Sep  7 23:08:37 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Thu, 7 Sep 2023 19:08:37 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
 <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
 <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>
Message-ID: <CAGe_KfywcDq3yRMOLb4BpZ1872BZYZcbfTiFdXkxpmF5=erqgA@mail.gmail.com>

Hello James,

Thank you for the information. Unfortunately nothing seems to work in this
scenario/environment. We have worked on deployments where compute nodes
have a direct interface to external networks. but this dedicated
network/gateway scenario has proven difficult to implement with OVN.

The main issue is displayed when we remove all bridge mappings from compute
nodes (neutron_ovn_controller host group). Leaving the provider network
mappings exclusively on the network/gateway hosts (neutron_ovn_gateway host
group). Upon attempting to attach an interface to the external network,
neutron complains about a PortBindingFailed error.

Our relevant configuration files/content:
https://paste.opendev.org/show/821535/

I have run out of ideas here. Any help would be appreciated.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/9e772a8b/attachment.htm>

From satish.txt at gmail.com  Fri Sep  8 01:53:38 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 7 Sep 2023 21:53:38 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAGe_KfywcDq3yRMOLb4BpZ1872BZYZcbfTiFdXkxpmF5=erqgA@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
 <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
 <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>
 <CAGe_KfywcDq3yRMOLb4BpZ1872BZYZcbfTiFdXkxpmF5=erqgA@mail.gmail.com>
Message-ID: <CAPgF-frFUYkcaH6rfp2i2+RS=q7p3Lk6LvSkjuKOfAwDKeqmHw@mail.gmail.com>

Hi Roger,

Since last 1 week I have been watching this thread and it just keeps
getting interesting. As James and Dimitry mentioned earlier that wherever
"ovn-cms-options=enable-chassis-as-gw" is set that node will act like
gateway of all VM and It will handle all external in/out traffic.

Can you post output of ovs-vsctl show and ovs-vsctl list Open_vSwitch of
your gateway node?

I will see if I can set up my lab to create a scenario similar to you to
untangle this mistry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/102942f7/attachment.htm>

From satish.txt at gmail.com  Fri Sep  8 01:57:36 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 7 Sep 2023 21:57:36 -0400
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPTyaN-5P1uCXnz9i-WJ5A+hGRemgfZihGthubJz=wO7qDnCgA@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
 <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
 <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>
 <CAPTyaN_Ni_TnNuxgtK5C8nDL2v9J2S9uj3i-g_EaWk62VWPJjA@mail.gmail.com>
 <CAPgF-fqJbS=HitSiFbZF4PW_OYcFCnqntuRM7nkZQHVu6wqe3A@mail.gmail.com>
 <CAPTyaN-5P1uCXnz9i-WJ5A+hGRemgfZihGthubJz=wO7qDnCgA@mail.gmail.com>
Message-ID: <CAPgF-fqWW+SC6aKM6wSM+CRXXhb_MtdXojJh08cg3uAhKpxa-g@mail.gmail.com>

I would say let's run your same benchmark with OVS-DPDK and tell me if you
see better performance. I doubt you will see significant performance boot
but lets see. Please prove me wrong :)

On Thu, Sep 7, 2023 at 9:45?PM Ha Noi <hanoi952022 at gmail.com> wrote:

> Hi Satish,
>
> Actually, the guess interface is not using tap anymore.
>
>     <interface type='vhostuser'>
>       <mac address='fa:16:3e:76:77:dd'/>
>       <source type='unix' path='/var/run/openvswitch/vhu3766ee8a-86'
> mode='server'/>
>       <target dev='vhu3766ee8a-86'/>
>       <model type='virtio'/>
>       <alias name='net0'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
> function='0x0'/>
>     </interface>
>
> It's totally bypass the kernel stack ?
>
>
>
>
> On Fri, Sep 8, 2023 at 5:02?AM Satish Patel <satish.txt at gmail.com> wrote:
>
>> I did test OVS-DPDK and it helps offload the packet process on compute
>> nodes, But what about VMs it will still use a tap interface to attach from
>> compute to vm and bottleneck will be in vm. I strongly believe that we have
>> to run DPDK based guest to pass through the kernel stack.
>>
>> I love to hear from other people if I am missing something here.
>>
>> On Thu, Sep 7, 2023 at 5:27?PM Ha Noi <hanoi952022 at gmail.com> wrote:
>>
>>> Oh. I heard from someone on the reddit said that Ovs-dpdk is transparent
>>> with user?
>>>
>>> So It?s not correct?
>>>
>>> On Thu, 7 Sep 2023 at 22:13 Satish Patel <satish.txt at gmail.com> wrote:
>>>
>>>> Because DPDK required DPDK support inside guest VM. It's not
>>>> suitable for general purpose workload. You need your guest VM network to
>>>> support DPDK to get 100% throughput.
>>>>
>>>> On Thu, Sep 7, 2023 at 8:06?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>>
>>>>> Hi Satish,
>>>>>
>>>>> Why dont you use DPDK?
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Thu, 7 Sep 2023 at 19:03 Satish Patel <satish.txt at gmail.com> wrote:
>>>>>
>>>>>> I totally agreed with Sean on all his points but trust me, I have
>>>>>> tried everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
>>>>>> pinning and name it.. but I didn't get any significant improvement. You may
>>>>>> gain 2 to 5% gain with all those tweek. I am running the entire workload on
>>>>>> sriov and life is happy except no LACP bonding.
>>>>>>
>>>>>> I am very interesting is this project
>>>>>> https://docs.openvswitch.org/en/latest/intro/install/afxdp/
>>>>>>
>>>>>> On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>>>>
>>>>>>> Dear Smoney,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
>>>>>>>
>>>>>>>> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
>>>>>>>> > Damn! We have noticed the same issue around 40k to 55k PPS. Trust
>>>>>>>> me
>>>>>>>> > nothing is wrong in your config. This is just a limitation of the
>>>>>>>> software
>>>>>>>> > stack and kernel itself.
>>>>>>>> its partly determined by your cpu frequency.
>>>>>>>> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
>>>>>>>> cpu. with per port troughpuyt being lower dependin on what
>>>>>>>> qos/firewall
>>>>>>>> rules that were apllied.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation. I
>>>>>>> think the problem is tuning in the compute node inside. But I cannot find
>>>>>>> any guide or best practices for it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> moving form iptables firewall to ovs firewall can help to some
>>>>>>>> degree
>>>>>>>> but your partly trading connection setup time for statead state
>>>>>>>> troughput
>>>>>>>> with the overhead of the connection tracker in ovs.
>>>>>>>>
>>>>>>>> using stateless security groups can help
>>>>>>>>
>>>>>>>> we also recently fixed a regression cause by changes in newer
>>>>>>>> versions of ovs.
>>>>>>>> this was notable in goign form rhel 8 to rhel 9 where litrally it
>>>>>>>> reduced
>>>>>>>> small packet performce to 1/10th and jumboframes to about 1/2
>>>>>>>> on master we have a config option that will set the default qos on
>>>>>>>> a port to linux-noop
>>>>>>>>
>>>>>>>> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>>>>>>>>
>>>>>>>> the backports are propsoed upstream
>>>>>>>> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
>>>>>>>> and we have backported this downstream to adress that performance
>>>>>>>> regression.
>>>>>>>> the upstram backport is semi stalled just ebcasue we wanted to
>>>>>>>> disucss if we shoudl make ti opt in
>>>>>>>> by default upstream while backporting but it might be helpful for
>>>>>>>> you if this is related to yoru current
>>>>>>>> issues.
>>>>>>>>
>>>>>>>> 40-55 kpps is kind of low for kernel ovs but if you have a low
>>>>>>>> clockrate cpu, hybrid_plug + incorrect qos
>>>>>>>> then i could see you hitting such a bottelneck.
>>>>>>>>
>>>>>>>> one workaround by the way without the os-vif workaround backported
>>>>>>>> is to set
>>>>>>>> /proc/sys/net/core/default_qdisc to not apply any qos or a low
>>>>>>>> overhead qos type
>>>>>>>> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> that may or may not help but i would ensure that your are not usign
>>>>>>>> somting like fqdel or cake
>>>>>>>> for net.core.default_qdisc and if you are try changing it to
>>>>>>>> pfifo_fast and see if that helps.
>>>>>>>>
>>>>>>>> there isnet much you can do about the cpu clock rate but ^ is
>>>>>>>> somethign you can try for free
>>>>>>>> note it wont actully take effect on an exsitng vm if you jsut
>>>>>>>> change the default but you can use
>>>>>>>> tc to also chagne the qdisk for testing. hard rebooting the vm
>>>>>>>> shoudl also make the default take effect.
>>>>>>>>
>>>>>>>> the only other advice i can give assuming kernel ovs is the only
>>>>>>>> option you have is
>>>>>>>>
>>>>>>>> to look at
>>>>>>>>
>>>>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>>>>>>>>
>>>>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
>>>>>>>> and
>>>>>>>>
>>>>>>>> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>>>>>>>>
>>>>>>>> if the bottelneck is actully in qemu or the guest kernel rather
>>>>>>>> then ovs adjusting the rx/tx queue size and
>>>>>>>> using multi queue can help. it will have no effect if ovs is the
>>>>>>>> bottel neck.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I have set this option to 1024, and enable multiqueue as well. But
>>>>>>> it did not help.
>>>>>>>
>>>>>>>
>>>>>>>> >
>>>>>>>> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com>
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> > > Hi Satish,
>>>>>>>> > >
>>>>>>>> > > Actually, our customer get this issue when the tx/rx above only
>>>>>>>> 40k pps.
>>>>>>>> > > So what is the threshold of this throughput for OvS?
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > > Thanks and regards
>>>>>>>> > >
>>>>>>>> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com>
>>>>>>>> wrote:
>>>>>>>> > >
>>>>>>>> > > > Hi,
>>>>>>>> > > >
>>>>>>>> > > > This is normal because OVS or LinuxBridge wire up VMs using
>>>>>>>> TAP interface
>>>>>>>> > > > which runs on kernel space and that drives higher interrupt
>>>>>>>> and that makes
>>>>>>>> > > > the kernel so busy working on handling packets. Standard
>>>>>>>> OVS/LinuxBridge
>>>>>>>> > > > are not meant for higher PPS.
>>>>>>>> > > >
>>>>>>>> > > > If you want to handle higher PPS then look for DPDK or SRIOV
>>>>>>>> deployment.
>>>>>>>> > > > ( We are running everything in SRIOV because of high PPS
>>>>>>>> requirement)
>>>>>>>> > > >
>>>>>>>> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com>
>>>>>>>> wrote:
>>>>>>>> > > >
>>>>>>>> > > > > Hi everyone,
>>>>>>>> > > > >
>>>>>>>> > > > > I'm using Openstack Train and Openvswitch for ML2 driver
>>>>>>>> and GRE for
>>>>>>>> > > > > tunnel type. I tested our network performance between two
>>>>>>>> VMs and suffer
>>>>>>>> > > > > packet loss as below.
>>>>>>>> > > > >
>>>>>>>> > > > > VM1: IP: 10.20.1.206
>>>>>>>> > > > >
>>>>>>>> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>>>>>>> > > > >
>>>>>>>> > > > > VM3: IP: 10.20.1.72
>>>>>>>> > > > >
>>>>>>>> > > > >
>>>>>>>> > > > > Using iperf3 to testing performance between VM1 and VM2.
>>>>>>>> > > > >
>>>>>>>> > > > > Run iperf3 client and server on both VMs.
>>>>>>>> > > > >
>>>>>>>> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c
>>>>>>>> 10.20.1.206
>>>>>>>> > > > >
>>>>>>>> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c
>>>>>>>> 10.20.1.154
>>>>>>>> > > > > <https://10.20.1.154/24>
>>>>>>>> > > > >
>>>>>>>> > > > >
>>>>>>>> > > > > Using VM3 ping into VM1, then the packet is lost and the
>>>>>>>> latency is
>>>>>>>> > > > > quite high.
>>>>>>>> > > > >
>>>>>>>> > > > >
>>>>>>>> > > > > ping -i 0.1 10.20.1.206
>>>>>>>> > > > >
>>>>>>>> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>>>>>>>> > > > >
>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>>>>>>>> > > > >
>>>>>>>> > > > > ^C
>>>>>>>> > > > >
>>>>>>>> > > > > --- 10.20.1.206 ping statistics ---
>>>>>>>> > > > >
>>>>>>>> > > > > 34 packets transmitted, 28 received, 17.6471% packet loss,
>>>>>>>> time 3328ms
>>>>>>>> > > > >
>>>>>>>> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>>>>>>> > > > >
>>>>>>>> > > > >
>>>>>>>> > > > >
>>>>>>>> > > > > Does any one get this issue ?
>>>>>>>> > > > >
>>>>>>>> > > > > Please help me. Thanks
>>>>>>>> > > > >
>>>>>>>> > > >
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/74e830be/attachment-0001.htm>

From satish.txt at gmail.com  Fri Sep  8 02:05:54 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 7 Sep 2023 22:05:54 -0400
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPTyaN-5o1M-YBA5TY7QwrZT1PCGq7Nv06FXJTwpSTsTCgYe1Q@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
 <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
 <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>
 <CAPTyaN_Ni_TnNuxgtK5C8nDL2v9J2S9uj3i-g_EaWk62VWPJjA@mail.gmail.com>
 <CAPgF-fqJbS=HitSiFbZF4PW_OYcFCnqntuRM7nkZQHVu6wqe3A@mail.gmail.com>
 <CAPTyaN-5P1uCXnz9i-WJ5A+hGRemgfZihGthubJz=wO7qDnCgA@mail.gmail.com>
 <CAPgF-fqWW+SC6aKM6wSM+CRXXhb_MtdXojJh08cg3uAhKpxa-g@mail.gmail.com>
 <CAPTyaN-5o1M-YBA5TY7QwrZT1PCGq7Nv06FXJTwpSTsTCgYe1Q@mail.gmail.com>
Message-ID: <CAPgF-fqCx4Yh8wp8SrfNoDtf_CFzJzZ-k2URFMB0nB+rQSgtFA@mail.gmail.com>

Do one thing, use test-pmd base benchmark and see because test-pmd
application is DPDK aware. with test-pmd you will have a 1000% better
performance :)

On Thu, Sep 7, 2023 at 9:59?PM Ha Noi <hanoi952022 at gmail.com> wrote:

> I run the performance test using iperf3. But the performance is not
> increased as theory. I don't know which configuration is not correct.
>
> On Fri, Sep 8, 2023 at 8:57?AM Satish Patel <satish.txt at gmail.com> wrote:
>
>> I would say let's run your same benchmark with OVS-DPDK and tell me if
>> you see better performance. I doubt you will see significant performance
>> boot but lets see. Please prove me wrong :)
>>
>> On Thu, Sep 7, 2023 at 9:45?PM Ha Noi <hanoi952022 at gmail.com> wrote:
>>
>>> Hi Satish,
>>>
>>> Actually, the guess interface is not using tap anymore.
>>>
>>>     <interface type='vhostuser'>
>>>       <mac address='fa:16:3e:76:77:dd'/>
>>>       <source type='unix' path='/var/run/openvswitch/vhu3766ee8a-86'
>>> mode='server'/>
>>>       <target dev='vhu3766ee8a-86'/>
>>>       <model type='virtio'/>
>>>       <alias name='net0'/>
>>>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>>> function='0x0'/>
>>>     </interface>
>>>
>>> It's totally bypass the kernel stack ?
>>>
>>>
>>>
>>>
>>> On Fri, Sep 8, 2023 at 5:02?AM Satish Patel <satish.txt at gmail.com>
>>> wrote:
>>>
>>>> I did test OVS-DPDK and it helps offload the packet process on compute
>>>> nodes, But what about VMs it will still use a tap interface to attach from
>>>> compute to vm and bottleneck will be in vm. I strongly believe that we have
>>>> to run DPDK based guest to pass through the kernel stack.
>>>>
>>>> I love to hear from other people if I am missing something here.
>>>>
>>>> On Thu, Sep 7, 2023 at 5:27?PM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>>
>>>>> Oh. I heard from someone on the reddit said that Ovs-dpdk is
>>>>> transparent with user?
>>>>>
>>>>> So It?s not correct?
>>>>>
>>>>> On Thu, 7 Sep 2023 at 22:13 Satish Patel <satish.txt at gmail.com> wrote:
>>>>>
>>>>>> Because DPDK required DPDK support inside guest VM. It's not
>>>>>> suitable for general purpose workload. You need your guest VM network to
>>>>>> support DPDK to get 100% throughput.
>>>>>>
>>>>>> On Thu, Sep 7, 2023 at 8:06?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Satish,
>>>>>>>
>>>>>>> Why dont you use DPDK?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> On Thu, 7 Sep 2023 at 19:03 Satish Patel <satish.txt at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I totally agreed with Sean on all his points but trust me, I have
>>>>>>>> tried everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
>>>>>>>> pinning and name it.. but I didn't get any significant improvement. You may
>>>>>>>> gain 2 to 5% gain with all those tweek. I am running the entire workload on
>>>>>>>> sriov and life is happy except no LACP bonding.
>>>>>>>>
>>>>>>>> I am very interesting is this project
>>>>>>>> https://docs.openvswitch.org/en/latest/intro/install/afxdp/
>>>>>>>>
>>>>>>>> On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Dear Smoney,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
>>>>>>>>>> > Damn! We have noticed the same issue around 40k to 55k PPS.
>>>>>>>>>> Trust me
>>>>>>>>>> > nothing is wrong in your config. This is just a limitation of
>>>>>>>>>> the software
>>>>>>>>>> > stack and kernel itself.
>>>>>>>>>> its partly determined by your cpu frequency.
>>>>>>>>>> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
>>>>>>>>>> cpu. with per port troughpuyt being lower dependin on what
>>>>>>>>>> qos/firewall
>>>>>>>>>> rules that were apllied.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation.
>>>>>>>>> I think the problem is tuning in the compute node inside. But I cannot find
>>>>>>>>> any guide or best practices for it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> moving form iptables firewall to ovs firewall can help to some
>>>>>>>>>> degree
>>>>>>>>>> but your partly trading connection setup time for statead state
>>>>>>>>>> troughput
>>>>>>>>>> with the overhead of the connection tracker in ovs.
>>>>>>>>>>
>>>>>>>>>> using stateless security groups can help
>>>>>>>>>>
>>>>>>>>>> we also recently fixed a regression cause by changes in newer
>>>>>>>>>> versions of ovs.
>>>>>>>>>> this was notable in goign form rhel 8 to rhel 9 where litrally it
>>>>>>>>>> reduced
>>>>>>>>>> small packet performce to 1/10th and jumboframes to about 1/2
>>>>>>>>>> on master we have a config option that will set the default qos
>>>>>>>>>> on a port to linux-noop
>>>>>>>>>>
>>>>>>>>>> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>>>>>>>>>>
>>>>>>>>>> the backports are propsoed upstream
>>>>>>>>>> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
>>>>>>>>>> and we have backported this downstream to adress that performance
>>>>>>>>>> regression.
>>>>>>>>>> the upstram backport is semi stalled just ebcasue we wanted to
>>>>>>>>>> disucss if we shoudl make ti opt in
>>>>>>>>>> by default upstream while backporting but it might be helpful for
>>>>>>>>>> you if this is related to yoru current
>>>>>>>>>> issues.
>>>>>>>>>>
>>>>>>>>>> 40-55 kpps is kind of low for kernel ovs but if you have a low
>>>>>>>>>> clockrate cpu, hybrid_plug + incorrect qos
>>>>>>>>>> then i could see you hitting such a bottelneck.
>>>>>>>>>>
>>>>>>>>>> one workaround by the way without the os-vif workaround
>>>>>>>>>> backported is to set
>>>>>>>>>> /proc/sys/net/core/default_qdisc to not apply any qos or a low
>>>>>>>>>> overhead qos type
>>>>>>>>>> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> that may or may not help but i would ensure that your are not
>>>>>>>>>> usign somting like fqdel or cake
>>>>>>>>>> for net.core.default_qdisc and if you are try changing it to
>>>>>>>>>> pfifo_fast and see if that helps.
>>>>>>>>>>
>>>>>>>>>> there isnet much you can do about the cpu clock rate but ^ is
>>>>>>>>>> somethign you can try for free
>>>>>>>>>> note it wont actully take effect on an exsitng vm if you jsut
>>>>>>>>>> change the default but you can use
>>>>>>>>>> tc to also chagne the qdisk for testing. hard rebooting the vm
>>>>>>>>>> shoudl also make the default take effect.
>>>>>>>>>>
>>>>>>>>>> the only other advice i can give assuming kernel ovs is the only
>>>>>>>>>> option you have is
>>>>>>>>>>
>>>>>>>>>> to look at
>>>>>>>>>>
>>>>>>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>>>>>>>>>>
>>>>>>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
>>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>>> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>>>>>>>>>>
>>>>>>>>>> if the bottelneck is actully in qemu or the guest kernel rather
>>>>>>>>>> then ovs adjusting the rx/tx queue size and
>>>>>>>>>> using multi queue can help. it will have no effect if ovs is the
>>>>>>>>>> bottel neck.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I have set this option to 1024, and enable multiqueue as well. But
>>>>>>>>> it did not help.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> >
>>>>>>>>>> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> >
>>>>>>>>>> > > Hi Satish,
>>>>>>>>>> > >
>>>>>>>>>> > > Actually, our customer get this issue when the tx/rx above
>>>>>>>>>> only 40k pps.
>>>>>>>>>> > > So what is the threshold of this throughput for OvS?
>>>>>>>>>> > >
>>>>>>>>>> > >
>>>>>>>>>> > > Thanks and regards
>>>>>>>>>> > >
>>>>>>>>>> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <
>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>> > >
>>>>>>>>>> > > > Hi,
>>>>>>>>>> > > >
>>>>>>>>>> > > > This is normal because OVS or LinuxBridge wire up VMs using
>>>>>>>>>> TAP interface
>>>>>>>>>> > > > which runs on kernel space and that drives higher interrupt
>>>>>>>>>> and that makes
>>>>>>>>>> > > > the kernel so busy working on handling packets. Standard
>>>>>>>>>> OVS/LinuxBridge
>>>>>>>>>> > > > are not meant for higher PPS.
>>>>>>>>>> > > >
>>>>>>>>>> > > > If you want to handle higher PPS then look for DPDK or
>>>>>>>>>> SRIOV deployment.
>>>>>>>>>> > > > ( We are running everything in SRIOV because of high PPS
>>>>>>>>>> requirement)
>>>>>>>>>> > > >
>>>>>>>>>> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <
>>>>>>>>>> hanoi952022 at gmail.com> wrote:
>>>>>>>>>> > > >
>>>>>>>>>> > > > > Hi everyone,
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > I'm using Openstack Train and Openvswitch for ML2 driver
>>>>>>>>>> and GRE for
>>>>>>>>>> > > > > tunnel type. I tested our network performance between two
>>>>>>>>>> VMs and suffer
>>>>>>>>>> > > > > packet loss as below.
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > VM1: IP: 10.20.1.206
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > VM3: IP: 10.20.1.72
>>>>>>>>>> > > > >
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > Using iperf3 to testing performance between VM1 and VM2.
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > Run iperf3 client and server on both VMs.
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c
>>>>>>>>>> 10.20.1.206
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c
>>>>>>>>>> 10.20.1.154
>>>>>>>>>> > > > > <https://10.20.1.154/24>
>>>>>>>>>> > > > >
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > Using VM3 ping into VM1, then the packet is lost and the
>>>>>>>>>> latency is
>>>>>>>>>> > > > > quite high.
>>>>>>>>>> > > > >
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > ping -i 0.1 10.20.1.206
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57
>>>>>>>>>> ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74
>>>>>>>>>> ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37
>>>>>>>>>> ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59
>>>>>>>>>> ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97
>>>>>>>>>> ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72
>>>>>>>>>> ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23
>>>>>>>>>> ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > ^C
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > --- 10.20.1.206 ping statistics ---
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > 34 packets transmitted, 28 received, 17.6471% packet
>>>>>>>>>> loss, time 3328ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>>>>>>>>> > > > >
>>>>>>>>>> > > > >
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > Does any one get this issue ?
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > Please help me. Thanks
>>>>>>>>>> > > > >
>>>>>>>>>> > > >
>>>>>>>>>>
>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230907/beda0d62/attachment-0001.htm>

From tkajinam at redhat.com  Fri Sep  8 12:19:13 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Fri, 8 Sep 2023 21:19:13 +0900
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and
 maintainers
In-Reply-To: <188ea6f2a53.ee65931886747.6600003948918544663@ghanshyammann.com>
References: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
 <188ea6f2a53.ee65931886747.6600003948918544663@ghanshyammann.com>
Message-ID: <CAL_crJTTn2=y5_6rg2ODPWb3Rvc=BvOt=MeQ2F7FosL9YfdWWg@mail.gmail.com>

Let me bump this old thread because we still need some follow-up about the
retirement of os-win.

I noticed that some projects have not yet deprecated the implementations
dependent on os-win.
I submitted a few patches to make these implementations deprecated so that
we can smoothly remove these
in the future.
 https://review.opendev.org/c/openstack/cinder/+/894237
 https://review.opendev.org/c/openstack/glance/+/894236
 https://review.opendev.org/c/openstack/ceilometer/+/894296
It'd be nice if the relevant teams can review these.

My remaining question is whether we should mark all implementations for
Windows support, which are not directly
dependent on os-win[1]. Technically we can go through individual projects
and add warning logs and release notes
about the deprecation. However I'm not too sure if that's worth the effort.
If we can agree that we remove support
for running OpenStack on Windows Operating System at a specific release,
then I tend to leave the ones independent
from os-win, unless it has any impact on user-facing items like config
options[1].

I'd like to hear any thoughts about this plan, as well as any target
release to remove Windows "host" support globally
from OpenStack (maybe after 2024.1 release ?).

[1] Some examples

https://github.com/openstack/ceilometer/blob/d31d4ed3574a5d19fe4b09ab2c227dba64da170a/ceilometer/cmd/polling.py#L95-L96

https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py#L624-L625

[2] event_log option in oslo.log is one good example
https://review.opendev.org/c/openstack/oslo.log/+/894235

On Sat, Jun 24, 2023 at 7:50?AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

> As there is no volunteer to maintain this project, I have proposed the
> retirement
>
> - https://review.opendev.org/c/openstack/governance/+/886880
>
> -gmann
>
>  ---- On Thu, 13 Apr 2023 07:54:12 -0700  James Page  wrote ---
>  > Hi All
>  >
>  > As announced by Lucian last November (see [0]) Cloudbase Solutions are
> no longer in a position to maintain support for running OpenStack on
> Windows and have also ceased operation of their 3rd party CI for the
> windows support across a number of OpenStack projects.
>  > This situation has resulted in the Winstackers project becoming
> PTL-less for the 2023.2 cycle with no volunteers responding to the TC's
> call to fill this role and take this feature in OpenStack forward (see [1]).
>  > This is the final call for any maintainers to step forward if this
> feature is important to them in OpenStack.
>  > The last user survey in 2022 indicated that 2% of respondents were
> running on Hyper-V so this might be important enough to warrant a
> commitment from someone operating OpenStack on Windows to maintain these
> features going forward.
>  > Here is a reminder from Lucian's original email on the full list of
> projects which are impacted in some way: * nova hyper-v driver - in-tree
> plus out-of-tree compute-hyperv driver* os-win - common Windows library for
> Openstack* neutron hyperv ml2 plugin and agent* ovs on Windows and neutron
> ovs agent support* cinder drivers - SMB and Windows iSCSI* os-brick Windows
> connectors - iSCSI, FC, SMB, RBD* ceilometer Windows poller* manila Windows
> driver* glance Windows support* freerdp gateway
>  > The lack of 3rd party CI for testing all of this really needs to be
> addressed as well.
>  > If no maintainers are forthcoming between now and the next PTG in June
> the TC will need to officially retire the project and start the process of
> removing support for Windows across the various projects that support this
> operating system in some way - either directly or through the use of os-win.
>  > For clarity this call refers to the use of the Hyper-V virtualisation
> driver and associated Windows server components to provide WIndows based
> OpenStack Hypervisors and does not relate to the ability to run Windows
> images as guests on OpenStack.
>  > Regards
>  > James
>  > [0]
> https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html[1]
>
> https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032888.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/dc7cf421/attachment.htm>

From ralonsoh at redhat.com  Fri Sep  8 12:37:30 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 8 Sep 2023 14:37:30 +0200
Subject: [neutron] Neutron drivers meeting cancelled
Message-ID: <CAECr9X4L72TnPe1DVg9SRYFVx6CDf7fKZP9XgfvNC5yg2FhgyA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/e5f8b4a8/attachment.htm>

From roger.riverac at gmail.com  Fri Sep  8 13:11:06 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Fri, 8 Sep 2023 09:11:06 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAPgF-frFUYkcaH6rfp2i2+RS=q7p3Lk6LvSkjuKOfAwDKeqmHw@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
 <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
 <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>
 <CAGe_KfywcDq3yRMOLb4BpZ1872BZYZcbfTiFdXkxpmF5=erqgA@mail.gmail.com>
 <CAPgF-frFUYkcaH6rfp2i2+RS=q7p3Lk6LvSkjuKOfAwDKeqmHw@mail.gmail.com>
Message-ID: <CAGe_KfzFGoT417fne=fum6LYtQic4TYSacsiRie89eAbA-sKyQ@mail.gmail.com>

Hello Satish,

I appreciate your feedback and any help will be greatly appreciated. Please
find the requested outputs pasted here:
https://paste.opendev.org/show/bHWvGMUYW35sU43zUxem/

I've included outputs for one compute and one network/gateway node.

As a recap, among other nodes, the environment includes:

-2x compute - 1x NIC ens1 with IPv4 (geneve) - no bridges
-2x network/gateway nodes - 2x NICs - ens1 with IPv4 (geneve), ens2 as
external net interface, br-vlan connected to ens2 bridge.

Let me know if you need further information. Much appreciated.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/a6d8f0c1/attachment.htm>

From james.denton at rackspace.com  Fri Sep  8 13:31:00 2023
From: james.denton at rackspace.com (James Denton)
Date: Fri, 8 Sep 2023 13:31:00 +0000
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAGe_KfzFGoT417fne=fum6LYtQic4TYSacsiRie89eAbA-sKyQ@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
 <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
 <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>
 <CAGe_KfywcDq3yRMOLb4BpZ1872BZYZcbfTiFdXkxpmF5=erqgA@mail.gmail.com>
 <CAPgF-frFUYkcaH6rfp2i2+RS=q7p3Lk6LvSkjuKOfAwDKeqmHw@mail.gmail.com>
 <CAGe_KfzFGoT417fne=fum6LYtQic4TYSacsiRie89eAbA-sKyQ@mail.gmail.com>
Message-ID: <BL1PR20MB46099B8B78FF800F3382EB1F8EEDA@BL1PR20MB4609.namprd20.prod.outlook.com>

Hi Roger,

That output looks as I would expect, thank you.

Can you please provide the output for ?openstack network show? for the network being attached to the VM?

Thanks,
James

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Roger Rivera <roger.riverac at gmail.com>
Sent: Friday, September 8, 2023 8:11:06 AM
To: Satish Patel <satish.txt at gmail.com>
Cc: James Denton <james.denton at rackspace.com>; Dmitriy Rabotyagov <noonedeadpunk at gmail.com>; openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [openstack-ansible] Dedicated gateway hosts not working with OVN

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!

Hello Satish,

I appreciate your feedback and any help will be greatly appreciated. Please find the requested outputs pasted here: https://paste.opendev.org/show/bHWvGMUYW35sU43zUxem/

I've included outputs for one compute and one network/gateway node.

As a recap, among other nodes, the environment includes:

-2x compute - 1x NIC ens1 with IPv4 (geneve) - no bridges
-2x network/gateway nodes - 2x NICs - ens1 with IPv4 (geneve), ens2 as external net interface, br-vlan connected to ens2 bridge.

Let me know if you need further information. Much appreciated.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/4fd64b4a/attachment-0001.htm>

From roger.riverac at gmail.com  Fri Sep  8 13:43:19 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Fri, 8 Sep 2023 09:43:19 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <BL1PR20MB46099B8B78FF800F3382EB1F8EEDA@BL1PR20MB4609.namprd20.prod.outlook.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
 <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
 <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>
 <CAGe_KfywcDq3yRMOLb4BpZ1872BZYZcbfTiFdXkxpmF5=erqgA@mail.gmail.com>
 <CAPgF-frFUYkcaH6rfp2i2+RS=q7p3Lk6LvSkjuKOfAwDKeqmHw@mail.gmail.com>
 <CAGe_KfzFGoT417fne=fum6LYtQic4TYSacsiRie89eAbA-sKyQ@mail.gmail.com>
 <BL1PR20MB46099B8B78FF800F3382EB1F8EEDA@BL1PR20MB4609.namprd20.prod.outlook.com>
Message-ID: <CAGe_Kfx4fG96rNh1QD3qOT4joD+WS=5pHXoM2SiMAiyDDyJ4Ug@mail.gmail.com>

Hello James,

I appreciate the prompt response. Please see the output for openstack
network show <net> , pasted at
https://paste.opendev.org/show/bIhYhu6fDWoMaIiyaRMJ/

Thanks you

On Fri, Sep 8, 2023 at 9:31?AM James Denton <james.denton at rackspace.com>
wrote:

> Hi Roger,
>
> That output looks as I would expect, thank you.
>
> Can you please provide the output for ?openstack network show? for the
> network being attached to the VM?
>
> Thanks,
> James
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* Roger Rivera <roger.riverac at gmail.com>
> *Sent:* Friday, September 8, 2023 8:11:06 AM
> *To:* Satish Patel <satish.txt at gmail.com>
> *Cc:* James Denton <james.denton at rackspace.com>; Dmitriy Rabotyagov <
> noonedeadpunk at gmail.com>; openstack-discuss <
> openstack-discuss at lists.openstack.org>
> *Subject:* Re: [openstack-ansible] Dedicated gateway hosts not working
> with OVN
>
> CAUTION: This message originated externally, please use caution when
> clicking on links or opening attachments!
>
> Hello Satish,
>
> I appreciate your feedback and any help will be greatly appreciated.
> Please find the requested outputs pasted here:
> https://paste.opendev.org/show/bHWvGMUYW35sU43zUxem/
>
> I've included outputs for one compute and one network/gateway node.
>
> As a recap, among other nodes, the environment includes:
>
> -2x compute - 1x NIC ens1 with IPv4 (geneve) - no bridges
> -2x network/gateway nodes - 2x NICs - ens1 with IPv4 (geneve), ens2 as
> external net interface, br-vlan connected to ens2 bridge.
>
> Let me know if you need further information. Much appreciated.
>
> Thank you.
>


-- 
*Roger Rivera*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/f311167c/attachment.htm>

From hanoi952022 at gmail.com  Fri Sep  8 01:45:05 2023
From: hanoi952022 at gmail.com (Ha Noi)
Date: Fri, 8 Sep 2023 08:45:05 +0700
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPgF-fqJbS=HitSiFbZF4PW_OYcFCnqntuRM7nkZQHVu6wqe3A@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
 <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
 <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>
 <CAPTyaN_Ni_TnNuxgtK5C8nDL2v9J2S9uj3i-g_EaWk62VWPJjA@mail.gmail.com>
 <CAPgF-fqJbS=HitSiFbZF4PW_OYcFCnqntuRM7nkZQHVu6wqe3A@mail.gmail.com>
Message-ID: <CAPTyaN-5P1uCXnz9i-WJ5A+hGRemgfZihGthubJz=wO7qDnCgA@mail.gmail.com>

Hi Satish,

Actually, the guess interface is not using tap anymore.

    <interface type='vhostuser'>
      <mac address='fa:16:3e:76:77:dd'/>
      <source type='unix' path='/var/run/openvswitch/vhu3766ee8a-86'
mode='server'/>
      <target dev='vhu3766ee8a-86'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
    </interface>

It's totally bypass the kernel stack ?




On Fri, Sep 8, 2023 at 5:02?AM Satish Patel <satish.txt at gmail.com> wrote:

> I did test OVS-DPDK and it helps offload the packet process on compute
> nodes, But what about VMs it will still use a tap interface to attach from
> compute to vm and bottleneck will be in vm. I strongly believe that we have
> to run DPDK based guest to pass through the kernel stack.
>
> I love to hear from other people if I am missing something here.
>
> On Thu, Sep 7, 2023 at 5:27?PM Ha Noi <hanoi952022 at gmail.com> wrote:
>
>> Oh. I heard from someone on the reddit said that Ovs-dpdk is transparent
>> with user?
>>
>> So It?s not correct?
>>
>> On Thu, 7 Sep 2023 at 22:13 Satish Patel <satish.txt at gmail.com> wrote:
>>
>>> Because DPDK required DPDK support inside guest VM. It's not
>>> suitable for general purpose workload. You need your guest VM network to
>>> support DPDK to get 100% throughput.
>>>
>>> On Thu, Sep 7, 2023 at 8:06?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>
>>>> Hi Satish,
>>>>
>>>> Why dont you use DPDK?
>>>>
>>>> Thanks
>>>>
>>>> On Thu, 7 Sep 2023 at 19:03 Satish Patel <satish.txt at gmail.com> wrote:
>>>>
>>>>> I totally agreed with Sean on all his points but trust me, I have
>>>>> tried everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
>>>>> pinning and name it.. but I didn't get any significant improvement. You may
>>>>> gain 2 to 5% gain with all those tweek. I am running the entire workload on
>>>>> sriov and life is happy except no LACP bonding.
>>>>>
>>>>> I am very interesting is this project
>>>>> https://docs.openvswitch.org/en/latest/intro/install/afxdp/
>>>>>
>>>>> On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>>>
>>>>>> Dear Smoney,
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
>>>>>>
>>>>>>> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
>>>>>>> > Damn! We have noticed the same issue around 40k to 55k PPS. Trust
>>>>>>> me
>>>>>>> > nothing is wrong in your config. This is just a limitation of the
>>>>>>> software
>>>>>>> > stack and kernel itself.
>>>>>>> its partly determined by your cpu frequency.
>>>>>>> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
>>>>>>> cpu. with per port troughpuyt being lower dependin on what
>>>>>>> qos/firewall
>>>>>>> rules that were apllied.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation. I
>>>>>> think the problem is tuning in the compute node inside. But I cannot find
>>>>>> any guide or best practices for it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> moving form iptables firewall to ovs firewall can help to some degree
>>>>>>> but your partly trading connection setup time for statead state
>>>>>>> troughput
>>>>>>> with the overhead of the connection tracker in ovs.
>>>>>>>
>>>>>>> using stateless security groups can help
>>>>>>>
>>>>>>> we also recently fixed a regression cause by changes in newer
>>>>>>> versions of ovs.
>>>>>>> this was notable in goign form rhel 8 to rhel 9 where litrally it
>>>>>>> reduced
>>>>>>> small packet performce to 1/10th and jumboframes to about 1/2
>>>>>>> on master we have a config option that will set the default qos on a
>>>>>>> port to linux-noop
>>>>>>>
>>>>>>> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>>>>>>>
>>>>>>> the backports are propsoed upstream
>>>>>>> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
>>>>>>> and we have backported this downstream to adress that performance
>>>>>>> regression.
>>>>>>> the upstram backport is semi stalled just ebcasue we wanted to
>>>>>>> disucss if we shoudl make ti opt in
>>>>>>> by default upstream while backporting but it might be helpful for
>>>>>>> you if this is related to yoru current
>>>>>>> issues.
>>>>>>>
>>>>>>> 40-55 kpps is kind of low for kernel ovs but if you have a low
>>>>>>> clockrate cpu, hybrid_plug + incorrect qos
>>>>>>> then i could see you hitting such a bottelneck.
>>>>>>>
>>>>>>> one workaround by the way without the os-vif workaround backported
>>>>>>> is to set
>>>>>>> /proc/sys/net/core/default_qdisc to not apply any qos or a low
>>>>>>> overhead qos type
>>>>>>> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>> that may or may not help but i would ensure that your are not usign
>>>>>>> somting like fqdel or cake
>>>>>>> for net.core.default_qdisc and if you are try changing it to
>>>>>>> pfifo_fast and see if that helps.
>>>>>>>
>>>>>>> there isnet much you can do about the cpu clock rate but ^ is
>>>>>>> somethign you can try for free
>>>>>>> note it wont actully take effect on an exsitng vm if you jsut change
>>>>>>> the default but you can use
>>>>>>> tc to also chagne the qdisk for testing. hard rebooting the vm
>>>>>>> shoudl also make the default take effect.
>>>>>>>
>>>>>>> the only other advice i can give assuming kernel ovs is the only
>>>>>>> option you have is
>>>>>>>
>>>>>>> to look at
>>>>>>>
>>>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>>>>>>>
>>>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
>>>>>>> and
>>>>>>>
>>>>>>> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>>>>>>>
>>>>>>> if the bottelneck is actully in qemu or the guest kernel rather then
>>>>>>> ovs adjusting the rx/tx queue size and
>>>>>>> using multi queue can help. it will have no effect if ovs is the
>>>>>>> bottel neck.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I have set this option to 1024, and enable multiqueue as well. But it
>>>>>> did not help.
>>>>>>
>>>>>>
>>>>>>> >
>>>>>>> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > > Hi Satish,
>>>>>>> > >
>>>>>>> > > Actually, our customer get this issue when the tx/rx above only
>>>>>>> 40k pps.
>>>>>>> > > So what is the threshold of this throughput for OvS?
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > Thanks and regards
>>>>>>> > >
>>>>>>> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com>
>>>>>>> wrote:
>>>>>>> > >
>>>>>>> > > > Hi,
>>>>>>> > > >
>>>>>>> > > > This is normal because OVS or LinuxBridge wire up VMs using
>>>>>>> TAP interface
>>>>>>> > > > which runs on kernel space and that drives higher interrupt
>>>>>>> and that makes
>>>>>>> > > > the kernel so busy working on handling packets. Standard
>>>>>>> OVS/LinuxBridge
>>>>>>> > > > are not meant for higher PPS.
>>>>>>> > > >
>>>>>>> > > > If you want to handle higher PPS then look for DPDK or SRIOV
>>>>>>> deployment.
>>>>>>> > > > ( We are running everything in SRIOV because of high PPS
>>>>>>> requirement)
>>>>>>> > > >
>>>>>>> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <hanoi952022 at gmail.com>
>>>>>>> wrote:
>>>>>>> > > >
>>>>>>> > > > > Hi everyone,
>>>>>>> > > > >
>>>>>>> > > > > I'm using Openstack Train and Openvswitch for ML2 driver and
>>>>>>> GRE for
>>>>>>> > > > > tunnel type. I tested our network performance between two
>>>>>>> VMs and suffer
>>>>>>> > > > > packet loss as below.
>>>>>>> > > > >
>>>>>>> > > > > VM1: IP: 10.20.1.206
>>>>>>> > > > >
>>>>>>> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>>>>>> > > > >
>>>>>>> > > > > VM3: IP: 10.20.1.72
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > > Using iperf3 to testing performance between VM1 and VM2.
>>>>>>> > > > >
>>>>>>> > > > > Run iperf3 client and server on both VMs.
>>>>>>> > > > >
>>>>>>> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.206
>>>>>>> > > > >
>>>>>>> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c 10.20.1.154
>>>>>>> > > > > <https://10.20.1.154/24>
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > > Using VM3 ping into VM1, then the packet is lost and the
>>>>>>> latency is
>>>>>>> > > > > quite high.
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > > ping -i 0.1 10.20.1.206
>>>>>>> > > > >
>>>>>>> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>>>>>>> > > > >
>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>>>>>>> > > > >
>>>>>>> > > > > ^C
>>>>>>> > > > >
>>>>>>> > > > > --- 10.20.1.206 ping statistics ---
>>>>>>> > > > >
>>>>>>> > > > > 34 packets transmitted, 28 received, 17.6471% packet loss,
>>>>>>> time 3328ms
>>>>>>> > > > >
>>>>>>> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > > Does any one get this issue ?
>>>>>>> > > > >
>>>>>>> > > > > Please help me. Thanks
>>>>>>> > > > >
>>>>>>> > > >
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/643d43e3/attachment-0001.htm>

From hanoi952022 at gmail.com  Fri Sep  8 01:59:14 2023
From: hanoi952022 at gmail.com (Ha Noi)
Date: Fri, 8 Sep 2023 08:59:14 +0700
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPgF-fqWW+SC6aKM6wSM+CRXXhb_MtdXojJh08cg3uAhKpxa-g@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
 <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
 <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>
 <CAPTyaN_Ni_TnNuxgtK5C8nDL2v9J2S9uj3i-g_EaWk62VWPJjA@mail.gmail.com>
 <CAPgF-fqJbS=HitSiFbZF4PW_OYcFCnqntuRM7nkZQHVu6wqe3A@mail.gmail.com>
 <CAPTyaN-5P1uCXnz9i-WJ5A+hGRemgfZihGthubJz=wO7qDnCgA@mail.gmail.com>
 <CAPgF-fqWW+SC6aKM6wSM+CRXXhb_MtdXojJh08cg3uAhKpxa-g@mail.gmail.com>
Message-ID: <CAPTyaN-5o1M-YBA5TY7QwrZT1PCGq7Nv06FXJTwpSTsTCgYe1Q@mail.gmail.com>

I run the performance test using iperf3. But the performance is not
increased as theory. I don't know which configuration is not correct.

On Fri, Sep 8, 2023 at 8:57?AM Satish Patel <satish.txt at gmail.com> wrote:

> I would say let's run your same benchmark with OVS-DPDK and tell me if you
> see better performance. I doubt you will see significant performance boot
> but lets see. Please prove me wrong :)
>
> On Thu, Sep 7, 2023 at 9:45?PM Ha Noi <hanoi952022 at gmail.com> wrote:
>
>> Hi Satish,
>>
>> Actually, the guess interface is not using tap anymore.
>>
>>     <interface type='vhostuser'>
>>       <mac address='fa:16:3e:76:77:dd'/>
>>       <source type='unix' path='/var/run/openvswitch/vhu3766ee8a-86'
>> mode='server'/>
>>       <target dev='vhu3766ee8a-86'/>
>>       <model type='virtio'/>
>>       <alias name='net0'/>
>>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>> function='0x0'/>
>>     </interface>
>>
>> It's totally bypass the kernel stack ?
>>
>>
>>
>>
>> On Fri, Sep 8, 2023 at 5:02?AM Satish Patel <satish.txt at gmail.com> wrote:
>>
>>> I did test OVS-DPDK and it helps offload the packet process on compute
>>> nodes, But what about VMs it will still use a tap interface to attach from
>>> compute to vm and bottleneck will be in vm. I strongly believe that we have
>>> to run DPDK based guest to pass through the kernel stack.
>>>
>>> I love to hear from other people if I am missing something here.
>>>
>>> On Thu, Sep 7, 2023 at 5:27?PM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>
>>>> Oh. I heard from someone on the reddit said that Ovs-dpdk is
>>>> transparent with user?
>>>>
>>>> So It?s not correct?
>>>>
>>>> On Thu, 7 Sep 2023 at 22:13 Satish Patel <satish.txt at gmail.com> wrote:
>>>>
>>>>> Because DPDK required DPDK support inside guest VM. It's not
>>>>> suitable for general purpose workload. You need your guest VM network to
>>>>> support DPDK to get 100% throughput.
>>>>>
>>>>> On Thu, Sep 7, 2023 at 8:06?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>>>
>>>>>> Hi Satish,
>>>>>>
>>>>>> Why dont you use DPDK?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On Thu, 7 Sep 2023 at 19:03 Satish Patel <satish.txt at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I totally agreed with Sean on all his points but trust me, I have
>>>>>>> tried everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
>>>>>>> pinning and name it.. but I didn't get any significant improvement. You may
>>>>>>> gain 2 to 5% gain with all those tweek. I am running the entire workload on
>>>>>>> sriov and life is happy except no LACP bonding.
>>>>>>>
>>>>>>> I am very interesting is this project
>>>>>>> https://docs.openvswitch.org/en/latest/intro/install/afxdp/
>>>>>>>
>>>>>>> On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com> wrote:
>>>>>>>
>>>>>>>> Dear Smoney,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
>>>>>>>>> > Damn! We have noticed the same issue around 40k to 55k PPS.
>>>>>>>>> Trust me
>>>>>>>>> > nothing is wrong in your config. This is just a limitation of
>>>>>>>>> the software
>>>>>>>>> > stack and kernel itself.
>>>>>>>>> its partly determined by your cpu frequency.
>>>>>>>>> kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
>>>>>>>>> cpu. with per port troughpuyt being lower dependin on what
>>>>>>>>> qos/firewall
>>>>>>>>> rules that were apllied.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation. I
>>>>>>>> think the problem is tuning in the compute node inside. But I cannot find
>>>>>>>> any guide or best practices for it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> moving form iptables firewall to ovs firewall can help to some
>>>>>>>>> degree
>>>>>>>>> but your partly trading connection setup time for statead state
>>>>>>>>> troughput
>>>>>>>>> with the overhead of the connection tracker in ovs.
>>>>>>>>>
>>>>>>>>> using stateless security groups can help
>>>>>>>>>
>>>>>>>>> we also recently fixed a regression cause by changes in newer
>>>>>>>>> versions of ovs.
>>>>>>>>> this was notable in goign form rhel 8 to rhel 9 where litrally it
>>>>>>>>> reduced
>>>>>>>>> small packet performce to 1/10th and jumboframes to about 1/2
>>>>>>>>> on master we have a config option that will set the default qos on
>>>>>>>>> a port to linux-noop
>>>>>>>>>
>>>>>>>>> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
>>>>>>>>>
>>>>>>>>> the backports are propsoed upstream
>>>>>>>>> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
>>>>>>>>> and we have backported this downstream to adress that performance
>>>>>>>>> regression.
>>>>>>>>> the upstram backport is semi stalled just ebcasue we wanted to
>>>>>>>>> disucss if we shoudl make ti opt in
>>>>>>>>> by default upstream while backporting but it might be helpful for
>>>>>>>>> you if this is related to yoru current
>>>>>>>>> issues.
>>>>>>>>>
>>>>>>>>> 40-55 kpps is kind of low for kernel ovs but if you have a low
>>>>>>>>> clockrate cpu, hybrid_plug + incorrect qos
>>>>>>>>> then i could see you hitting such a bottelneck.
>>>>>>>>>
>>>>>>>>> one workaround by the way without the os-vif workaround backported
>>>>>>>>> is to set
>>>>>>>>> /proc/sys/net/core/default_qdisc to not apply any qos or a low
>>>>>>>>> overhead qos type
>>>>>>>>> i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>> that may or may not help but i would ensure that your are not
>>>>>>>>> usign somting like fqdel or cake
>>>>>>>>> for net.core.default_qdisc and if you are try changing it to
>>>>>>>>> pfifo_fast and see if that helps.
>>>>>>>>>
>>>>>>>>> there isnet much you can do about the cpu clock rate but ^ is
>>>>>>>>> somethign you can try for free
>>>>>>>>> note it wont actully take effect on an exsitng vm if you jsut
>>>>>>>>> change the default but you can use
>>>>>>>>> tc to also chagne the qdisk for testing. hard rebooting the vm
>>>>>>>>> shoudl also make the default take effect.
>>>>>>>>>
>>>>>>>>> the only other advice i can give assuming kernel ovs is the only
>>>>>>>>> option you have is
>>>>>>>>>
>>>>>>>>> to look at
>>>>>>>>>
>>>>>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
>>>>>>>>>
>>>>>>>>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
>>>>>>>>>
>>>>>>>>> if the bottelneck is actully in qemu or the guest kernel rather
>>>>>>>>> then ovs adjusting the rx/tx queue size and
>>>>>>>>> using multi queue can help. it will have no effect if ovs is the
>>>>>>>>> bottel neck.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I have set this option to 1024, and enable multiqueue as well. But
>>>>>>>> it did not help.
>>>>>>>>
>>>>>>>>
>>>>>>>>> >
>>>>>>>>> > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > > Hi Satish,
>>>>>>>>> > >
>>>>>>>>> > > Actually, our customer get this issue when the tx/rx above
>>>>>>>>> only 40k pps.
>>>>>>>>> > > So what is the threshold of this throughput for OvS?
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > > Thanks and regards
>>>>>>>>> > >
>>>>>>>>> > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <satish.txt at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> > >
>>>>>>>>> > > > Hi,
>>>>>>>>> > > >
>>>>>>>>> > > > This is normal because OVS or LinuxBridge wire up VMs using
>>>>>>>>> TAP interface
>>>>>>>>> > > > which runs on kernel space and that drives higher interrupt
>>>>>>>>> and that makes
>>>>>>>>> > > > the kernel so busy working on handling packets. Standard
>>>>>>>>> OVS/LinuxBridge
>>>>>>>>> > > > are not meant for higher PPS.
>>>>>>>>> > > >
>>>>>>>>> > > > If you want to handle higher PPS then look for DPDK or SRIOV
>>>>>>>>> deployment.
>>>>>>>>> > > > ( We are running everything in SRIOV because of high PPS
>>>>>>>>> requirement)
>>>>>>>>> > > >
>>>>>>>>> > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <
>>>>>>>>> hanoi952022 at gmail.com> wrote:
>>>>>>>>> > > >
>>>>>>>>> > > > > Hi everyone,
>>>>>>>>> > > > >
>>>>>>>>> > > > > I'm using Openstack Train and Openvswitch for ML2 driver
>>>>>>>>> and GRE for
>>>>>>>>> > > > > tunnel type. I tested our network performance between two
>>>>>>>>> VMs and suffer
>>>>>>>>> > > > > packet loss as below.
>>>>>>>>> > > > >
>>>>>>>>> > > > > VM1: IP: 10.20.1.206
>>>>>>>>> > > > >
>>>>>>>>> > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
>>>>>>>>> > > > >
>>>>>>>>> > > > > VM3: IP: 10.20.1.72
>>>>>>>>> > > > >
>>>>>>>>> > > > >
>>>>>>>>> > > > > Using iperf3 to testing performance between VM1 and VM2.
>>>>>>>>> > > > >
>>>>>>>>> > > > > Run iperf3 client and server on both VMs.
>>>>>>>>> > > > >
>>>>>>>>> > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c
>>>>>>>>> 10.20.1.206
>>>>>>>>> > > > >
>>>>>>>>> > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c
>>>>>>>>> 10.20.1.154
>>>>>>>>> > > > > <https://10.20.1.154/24>
>>>>>>>>> > > > >
>>>>>>>>> > > > >
>>>>>>>>> > > > > Using VM3 ping into VM1, then the packet is lost and the
>>>>>>>>> latency is
>>>>>>>>> > > > > quite high.
>>>>>>>>> > > > >
>>>>>>>>> > > > >
>>>>>>>>> > > > > ping -i 0.1 10.20.1.206
>>>>>>>>> > > > >
>>>>>>>>> > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > ^C
>>>>>>>>> > > > >
>>>>>>>>> > > > > --- 10.20.1.206 ping statistics ---
>>>>>>>>> > > > >
>>>>>>>>> > > > > 34 packets transmitted, 28 received, 17.6471% packet loss,
>>>>>>>>> time 3328ms
>>>>>>>>> > > > >
>>>>>>>>> > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
>>>>>>>>> > > > >
>>>>>>>>> > > > >
>>>>>>>>> > > > >
>>>>>>>>> > > > > Does any one get this issue ?
>>>>>>>>> > > > >
>>>>>>>>> > > > > Please help me. Thanks
>>>>>>>>> > > > >
>>>>>>>>> > > >
>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/967cb5fd/attachment-0001.htm>

From smooney at redhat.com  Fri Sep  8 14:20:01 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Fri, 08 Sep 2023 15:20:01 +0100
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <CAPgF-fqCx4Yh8wp8SrfNoDtf_CFzJzZ-k2URFMB0nB+rQSgtFA@mail.gmail.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
 <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
 <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>
 <CAPTyaN_Ni_TnNuxgtK5C8nDL2v9J2S9uj3i-g_EaWk62VWPJjA@mail.gmail.com>
 <CAPgF-fqJbS=HitSiFbZF4PW_OYcFCnqntuRM7nkZQHVu6wqe3A@mail.gmail.com>
 <CAPTyaN-5P1uCXnz9i-WJ5A+hGRemgfZihGthubJz=wO7qDnCgA@mail.gmail.com>
 <CAPgF-fqWW+SC6aKM6wSM+CRXXhb_MtdXojJh08cg3uAhKpxa-g@mail.gmail.com>
 <CAPTyaN-5o1M-YBA5TY7QwrZT1PCGq7Nv06FXJTwpSTsTCgYe1Q@mail.gmail.com>
 <CAPgF-fqCx4Yh8wp8SrfNoDtf_CFzJzZ-k2URFMB0nB+rQSgtFA@mail.gmail.com>
Message-ID: <1273520546bf8174f04012ef6c442439e9dd84da.camel@redhat.com>

On Thu, 2023-09-07 at 22:05 -0400, Satish Patel wrote:
> Do one thing, use test-pmd base benchmark and see because test-pmd
> application is DPDK aware. with test-pmd you will have a 1000% better
> performance :)

actully test-pmd is not DPDK aware
its a dpdk applciation so it is faster because it remove the overhead of kernel networking in the guest
not because it has any dpdk awareness. testpmd cannot tell that ovs-dpdk is in use
form a gust perspecive you cannot tell if your using ovs-dpdk or kernel ovs as there is no viable diffence
in the virtio-net-pci device which  is presented to the guest kernel by qemu.

iper3 with a single core cant actully saturate a virtio-net-interface when its backed
by vhost-user/dpdk or something like a macvtap sriov port.
you can reach line rate with larger packet sizes or multipel cores but
if you wanted too test small packet io then testpmd, dpdk packetgen  or tgen
are better tools in that regard. they can eaiclly saturate a link into the 10s of gibitits per second using
64byte packets.

> 
> On Thu, Sep 7, 2023 at 9:59?PM Ha Noi <hanoi952022 at gmail.com> wrote:
> 
> > I run the performance test using iperf3. But the performance is not
> > increased as theory. I don't know which configuration is not correct.
> > 
> > On Fri, Sep 8, 2023 at 8:57?AM Satish Patel <satish.txt at gmail.com> wrote:
> > 
> > > I would say let's run your same benchmark with OVS-DPDK and tell me if
> > > you see better performance. I doubt you will see significant performance
> > > boot but lets see. Please prove me wrong :)
> > > 
> > > On Thu, Sep 7, 2023 at 9:45?PM Ha Noi <hanoi952022 at gmail.com> wrote:
> > > 
> > > > Hi Satish,
> > > > 
> > > > Actually, the guess interface is not using tap anymore.
> > > > 
> > > > ??? <interface type='vhostuser'>
> > > > ????? <mac address='fa:16:3e:76:77:dd'/>
> > > > ????? <source type='unix' path='/var/run/openvswitch/vhu3766ee8a-86'
> > > > mode='server'/>
> > > > ????? <target dev='vhu3766ee8a-86'/>
> > > > ????? <model type='virtio'/>
> > > > ????? <alias name='net0'/>
> > > > ????? <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
> > > > function='0x0'/>
> > > > ??? </interface>
> > > > 
> > > > It's totally bypass the kernel stack ?
yep dpdk is userspace networkign and it gets its performace boost form that
so the data is "trasnproted" by doding a direct mmap of the virtio ring buffers
between the DPDK pool mode driver and the qemu process.

> > > > 
> > > > 
> > > > 
> > > > 
> > > > On Fri, Sep 8, 2023 at 5:02?AM Satish Patel <satish.txt at gmail.com>
> > > > wrote:
> > > > 
> > > > > I did test OVS-DPDK and it helps offload the packet process on compute
> > > > > nodes, But what about VMs it will still use a tap interface to attach from
> > > > > compute to vm and bottleneck will be in vm. I strongly believe that we have
> > > > > to run DPDK based guest to pass through the kernel stack.
> > > > > 
> > > > > I love to hear from other people if I am missing something here.
> > > > > 
> > > > > On Thu, Sep 7, 2023 at 5:27?PM Ha Noi <hanoi952022 at gmail.com> wrote:
> > > > > 
> > > > > > Oh. I heard from someone on the reddit said that Ovs-dpdk is
> > > > > > transparent with user?
> > > > > > 
> > > > > > So It?s not correct?
> > > > > > 
> > > > > > On Thu, 7 Sep 2023 at 22:13 Satish Patel <satish.txt at gmail.com> wrote:
> > > > > > 
> > > > > > > Because DPDK required DPDK support inside guest VM. It's not
> > > > > > > suitable for general purpose workload. You need your guest VM network to
> > > > > > > support DPDK to get 100% throughput.
> > > > > > > 
> > > > > > > On Thu, Sep 7, 2023 at 8:06?AM Ha Noi <hanoi952022 at gmail.com> wrote:
> > > > > > > 
> > > > > > > > Hi Satish,
> > > > > > > > 
> > > > > > > > Why dont you use DPDK?
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > 
> > > > > > > > On Thu, 7 Sep 2023 at 19:03 Satish Patel <satish.txt at gmail.com>
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > I totally agreed with Sean on all his points but trust me, I have
> > > > > > > > > tried everything possible to tune OS, Network stack, multi-queue, NUMA, CPU
> > > > > > > > > pinning and name it.. but I didn't get any significant improvement. You may
> > > > > > > > > gain 2 to 5% gain with all those tweek. I am running the entire workload on
> > > > > > > > > sriov and life is happy except no LACP bonding.
> > > > > > > > > 
> > > > > > > > > I am very interesting is this project
> > > > > > > > > https://docs.openvswitch.org/en/latest/intro/install/afxdp/
> > > > > > > > > 
> > > > > > > > > On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <hanoi952022 at gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > Dear Smoney,
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com> wrote:
> > > > > > > > > > 
> > > > > > > > > > > On Wed, 2023-09-06 at 11:43 -0400, Satish Patel wrote:
> > > > > > > > > > > > Damn! We have noticed the same issue around 40k to 55k PPS.
> > > > > > > > > > > Trust me
> > > > > > > > > > > > nothing is wrong in your config. This is just a limitation of
> > > > > > > > > > > the software
> > > > > > > > > > > > stack and kernel itself.
> > > > > > > > > > > its partly determined by your cpu frequency.
> > > > > > > > > > > kernel ovs of yesteryear could handel about 1mpps total on a ~4GHZ
> > > > > > > > > > > cpu. with per port troughpuyt being lower dependin on what
> > > > > > > > > > > qos/firewall
> > > > > > > > > > > rules that were apllied.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > My CPU frequency is 3Ghz and using CPU Intel Gold 2nd generation.
> > > > > > > > > > I think the problem is tuning in the compute node inside. But I cannot find
> > > > > > > > > > any guide or best practices for it.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > moving form iptables firewall to ovs firewall can help to some
> > > > > > > > > > > degree
> > > > > > > > > > > but your partly trading connection setup time for statead state
> > > > > > > > > > > troughput
> > > > > > > > > > > with the overhead of the connection tracker in ovs.
> > > > > > > > > > > 
> > > > > > > > > > > using stateless security groups can help
> > > > > > > > > > > 
> > > > > > > > > > > we also recently fixed a regression cause by changes in newer
> > > > > > > > > > > versions of ovs.
> > > > > > > > > > > this was notable in goign form rhel 8 to rhel 9 where litrally it
> > > > > > > > > > > reduced
> > > > > > > > > > > small packet performce to 1/10th and jumboframes to about 1/2
> > > > > > > > > > > on master we have a config option that will set the default qos
> > > > > > > > > > > on a port to linux-noop
> > > > > > > > > > > 
> > > > > > > > > > > https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
> > > > > > > > > > > 
> > > > > > > > > > > the backports are propsoed upstream
> > > > > > > > > > > https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
> > > > > > > > > > > and we have backported this downstream to adress that performance
> > > > > > > > > > > regression.
> > > > > > > > > > > the upstram backport is semi stalled just ebcasue we wanted to
> > > > > > > > > > > disucss if we shoudl make ti opt in
> > > > > > > > > > > by default upstream while backporting but it might be helpful for
> > > > > > > > > > > you if this is related to yoru current
> > > > > > > > > > > issues.
> > > > > > > > > > > 
> > > > > > > > > > > 40-55 kpps is kind of low for kernel ovs but if you have a low
> > > > > > > > > > > clockrate cpu, hybrid_plug + incorrect qos
> > > > > > > > > > > then i could see you hitting such a bottelneck.
> > > > > > > > > > > 
> > > > > > > > > > > one workaround by the way without the os-vif workaround
> > > > > > > > > > > backported is to set
> > > > > > > > > > > /proc/sys/net/core/default_qdisc to not apply any qos or a low
> > > > > > > > > > > overhead qos type
> > > > > > > > > > > i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > that may or may not help but i would ensure that your are not
> > > > > > > > > > > usign somting like fqdel or cake
> > > > > > > > > > > for net.core.default_qdisc and if you are try changing it to
> > > > > > > > > > > pfifo_fast and see if that helps.
> > > > > > > > > > > 
> > > > > > > > > > > there isnet much you can do about the cpu clock rate but ^ is
> > > > > > > > > > > somethign you can try for free
> > > > > > > > > > > note it wont actully take effect on an exsitng vm if you jsut
> > > > > > > > > > > change the default but you can use
> > > > > > > > > > > tc to also chagne the qdisk for testing. hard rebooting the vm
> > > > > > > > > > > shoudl also make the default take effect.
> > > > > > > > > > > 
> > > > > > > > > > > the only other advice i can give assuming kernel ovs is the only
> > > > > > > > > > > option you have is
> > > > > > > > > > > 
> > > > > > > > > > > to look at
> > > > > > > > > > > 
> > > > > > > > > > > https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
> > > > > > > > > > > 
> > > > > > > > > > > https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
> > > > > > > > > > > and
> > > > > > > > > > > 
> > > > > > > > > > > https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
> > > > > > > > > > > 
> > > > > > > > > > > if the bottelneck is actully in qemu or the guest kernel rather
> > > > > > > > > > > then ovs adjusting the rx/tx queue size and
> > > > > > > > > > > using multi queue can help. it will have no effect if ovs is the
> > > > > > > > > > > bottel neck.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > I have set this option to 1024, and enable multiqueue as well. But
> > > > > > > > > > it did not help.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <hanoi952022 at gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > Hi Satish,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Actually, our customer get this issue when the tx/rx above
> > > > > > > > > > > only 40k pps.
> > > > > > > > > > > > > So what is the threshold of this throughput for OvS?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Thanks and regards
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <
> > > > > > > > > > > satish.txt at gmail.com> wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > This is normal because OVS or LinuxBridge wire up VMs using
> > > > > > > > > > > TAP interface
> > > > > > > > > > > > > > which runs on kernel space and that drives higher interrupt
> > > > > > > > > > > and that makes
> > > > > > > > > > > > > > the kernel so busy working on handling packets. Standard
> > > > > > > > > > > OVS/LinuxBridge
> > > > > > > > > > > > > > are not meant for higher PPS.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > If you want to handle higher PPS then look for DPDK or
> > > > > > > > > > > SRIOV deployment.
> > > > > > > > > > > > > > ( We are running everything in SRIOV because of high PPS
> > > > > > > > > > > requirement)
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <
> > > > > > > > > > > hanoi952022 at gmail.com> wrote:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi everyone,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I'm using Openstack Train and Openvswitch for ML2 driver
> > > > > > > > > > > and GRE for
> > > > > > > > > > > > > > > tunnel type. I tested our network performance between two
> > > > > > > > > > > VMs and suffer
> > > > > > > > > > > > > > > packet loss as below.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > VM1: IP: 10.20.1.206
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24>
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > VM3: IP: 10.20.1.72
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Using iperf3 to testing performance between VM1 and VM2.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Run iperf3 client and server on both VMs.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c
> > > > > > > > > > > 10.20.1.206
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6 -u -c
> > > > > > > > > > > 10.20.1.154
> > > > > > > > > > > > > > > <https://10.20.1.154/24>
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Using VM3 ping into VM1, then the packet is lost and the
> > > > > > > > > > > latency is
> > > > > > > > > > > > > > > quite high.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ping -i 0.1 10.20.1.206
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes of data.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=1 ttl=64 time=7.70 ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=2 ttl=64 time=6.90 ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=3 ttl=64 time=7.71 ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=4 ttl=64 time=7.98 ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=6 ttl=64 time=8.58 ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=7 ttl=64 time=8.34 ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=8 ttl=64 time=8.09 ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=10 ttl=64 time=4.57
> > > > > > > > > > > ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=11 ttl=64 time=8.74
> > > > > > > > > > > ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=12 ttl=64 time=9.37
> > > > > > > > > > > ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=14 ttl=64 time=9.59
> > > > > > > > > > > ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=15 ttl=64 time=7.97
> > > > > > > > > > > ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=16 ttl=64 time=8.72
> > > > > > > > > > > ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=17 ttl=64 time=9.23
> > > > > > > > > > > ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > ^C
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > --- 10.20.1.206 ping statistics ---
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 34 packets transmitted, 28 received, 17.6471% packet
> > > > > > > > > > > loss, time 3328ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > rtt min/avg/max/mdev = 1.396/6.266/9.590/2.805 ms
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Does any one get this issue ?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Please help me. Thanks
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 



From hberaud at redhat.com  Fri Sep  8 14:30:07 2023
From: hberaud at redhat.com (Herve Beraud)
Date: Fri, 8 Sep 2023 16:30:07 +0200
Subject: [release] Release countdown for week R-3, Sep 11-15
Message-ID: <CAFDq9gUDJ0R60RZ=iENe_CapiKfj-eAvTY8=wsjFZm4nsE4Thg@mail.gmail.com>

Development Focus
-----------------

The Release Candidate (RC) deadline is next Thursday, September 14. Work
should be focused on fixing any release-critical bugs.

General Information
-------------------

All deliverables released under a cycle-with-rc model should have a first
release candidate by the end of the week, from which a stable/2023.2
branch will be cut. This branch will track the 2023.2 Bobcat release.

Once stable/2023.2 has been created, the master branch will be ready to
switch to 2024.1 Caracal development. While the master branch will no longer
be feature-frozen, please prioritize any work necessary for completing
2023.2 Bobcat plans.  Release-critical bugfixes will need to be merged in
the
master branch first, then backported to the stable/2023.2 branch before
a new release candidate can be proposed.

Actions
-------

Early in the week, the release team will be proposing RC1 patches for all
cycle-with-rc projects, using the latest commit from the master branch.
If your team is ready to go for cutting RC1, please let us know by
leaving a +1 on these patches.

If there are still a few more patches needed before RC1, you can -1 the
patch and update it later in the week with the new commit hash you would
like to use. Remember, stable/2023.2 branches will be created with this,
so you will want to make sure you have what you need included to avoid
needing to backport changes from the master branch (which will
technically then be 2024.1 Bobcat) to this stable branch for any
additional RCs before the final release.

The release team will also be proposing releases for any deliverable
following a cycle-with-intermediary model that has not produced any 2023.2
Bobcat
release so far.

Finally, now is a good time to finalize release highlights. Release
highlights help shape the messaging around the release and make sure that
your work is properly represented.

Upcoming Deadlines & Dates
--------------------------

RC1 deadline: September 14 (R-3 week)
Final RC deadline: September 28 (R-1 week)
Final 2023.2 Bobcat release: October 4


-- 
Herv? Beraud
Senior Software Engineer at Red Hat
irc: hberaud
https://github.com/4383/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/26d735cf/attachment-0001.htm>

From james.denton at rackspace.com  Fri Sep  8 15:28:14 2023
From: james.denton at rackspace.com (James Denton)
Date: Fri, 8 Sep 2023 15:28:14 +0000
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <CAGe_Kfx4fG96rNh1QD3qOT4joD+WS=5pHXoM2SiMAiyDDyJ4Ug@mail.gmail.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
 <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
 <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>
 <CAGe_KfywcDq3yRMOLb4BpZ1872BZYZcbfTiFdXkxpmF5=erqgA@mail.gmail.com>
 <CAPgF-frFUYkcaH6rfp2i2+RS=q7p3Lk6LvSkjuKOfAwDKeqmHw@mail.gmail.com>
 <CAGe_KfzFGoT417fne=fum6LYtQic4TYSacsiRie89eAbA-sKyQ@mail.gmail.com>
 <BL1PR20MB46099B8B78FF800F3382EB1F8EEDA@BL1PR20MB4609.namprd20.prod.outlook.com>
 <CAGe_Kfx4fG96rNh1QD3qOT4joD+WS=5pHXoM2SiMAiyDDyJ4Ug@mail.gmail.com>
Message-ID: <BL1PR20MB4609860418513958DF7110DF8EEDA@BL1PR20MB4609.namprd20.prod.outlook.com>

Thanks, Roger. Super helpful.

If you?re attempting to launch the VM on that network it will fail, since that network is only plumbed to the net nodes as an 'external' network. For the VM, you will want to create a non-provider (tenant) network, which would likely be geneve, and then create a neutron router that connects to the external network and the tenant network. Your VM traffic would then traverse that router from compute->net node and out over the geneve overlay.

Keep us posted.

James

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Roger Rivera <roger.riverac at gmail.com>
Sent: Friday, September 8, 2023 8:43:19 AM
To: James Denton <james.denton at rackspace.com>
Cc: Satish Patel <satish.txt at gmail.com>; Dmitriy Rabotyagov <noonedeadpunk at gmail.com>; openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [openstack-ansible] Dedicated gateway hosts not working with OVN

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!

Hello James,

I appreciate the prompt response. Please see the output for openstack network show <net> , pasted at https://paste.opendev.org/show/bIhYhu6fDWoMaIiyaRMJ/

Thanks you

On Fri, Sep 8, 2023 at 9:31?AM James Denton <james.denton at rackspace.com<mailto:james.denton at rackspace.com>> wrote:
Hi Roger,

That output looks as I would expect, thank you.

Can you please provide the output for ?openstack network show? for the network being attached to the VM?

Thanks,
James

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Roger Rivera <roger.riverac at gmail.com<mailto:roger.riverac at gmail.com>>
Sent: Friday, September 8, 2023 8:11:06 AM
To: Satish Patel <satish.txt at gmail.com<mailto:satish.txt at gmail.com>>
Cc: James Denton <james.denton at rackspace.com<mailto:james.denton at rackspace.com>>; Dmitriy Rabotyagov <noonedeadpunk at gmail.com<mailto:noonedeadpunk at gmail.com>>; openstack-discuss <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Subject: Re: [openstack-ansible] Dedicated gateway hosts not working with OVN

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!

Hello Satish,

I appreciate your feedback and any help will be greatly appreciated. Please find the requested outputs pasted here: https://paste.opendev.org/show/bHWvGMUYW35sU43zUxem/

I've included outputs for one compute and one network/gateway node.

As a recap, among other nodes, the environment includes:

-2x compute - 1x NIC ens1 with IPv4 (geneve) - no bridges
-2x network/gateway nodes - 2x NICs - ens1 with IPv4 (geneve), ens2 as external net interface, br-vlan connected to ens2 bridge.

Let me know if you need further information. Much appreciated.

Thank you.


--
Roger Rivera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/682fa502/attachment.htm>

From satish.txt at gmail.com  Fri Sep  8 20:44:06 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Fri, 8 Sep 2023 16:44:06 -0400
Subject: [Skyline] error username or password incorrect
In-Reply-To: <CABAODRfq-jFRJzaNbypy3rT_vhUV6DQFVpmjL-hAsLRj=RPTgA@mail.gmail.com>
References: <CAPgF-fqgk=zFdetgrT+kr1tiQevNxwHVT8tgyQ+88w4wR0qU9g@mail.gmail.com>
 <CAPgF-fqo4Tev15oeObkJBq-f-h3M4VKy1JsZY7ZHXfFHpDpcVg@mail.gmail.com>
 <CAPgF-fo8wX-2go2wKQ6n1ZL_MLYXhR7K61Z7LsQmnRjb0dvcVA@mail.gmail.com>
 <CABAODRcbmAZ7m+A=ye2MsKaCUhZTWzksPcYfMDB36xDWagQBWg@mail.gmail.com>
 <CAPgF-fpGXDMD9+1vFJKSQFSRb3xskhBvsUpLPX1N0fRQYLz8NQ@mail.gmail.com>
 <CABAODReHKzqNeLN+JY_WPwtHkebS1E5QhwUEdE2aUtbGt_DEUQ@mail.gmail.com>
 <CAPgF-foxeMDoRBdD1oi7d2tynVi3cNO7SJu-p-yyC7tAH9u+qw@mail.gmail.com>
 <CABAODRfJb1eaQ=7WDaKQs34dj6jrtU7tD=DvYADUOX5rOU5eBQ@mail.gmail.com>
 <CAPgF-frY==mp=81YV_LtjmMvaqmCVkz+JmfGJLwOq5iGx+vr5A@mail.gmail.com>
 <CABAODRdOogiHNo2xZ7QiYRQeWR2aPHP7zas=7WrWHG6jHWWaMA@mail.gmail.com>
 <CAPgF-fqMPDB3KMQLvJQ1y6rtXuQtmEVBaa7mnE0T3f3Q9EKBRw@mail.gmail.com>
 <CABAODRfq-jFRJzaNbypy3rT_vhUV6DQFVpmjL-hAsLRj=RPTgA@mail.gmail.com>
Message-ID: <CAPgF-fp2Wh=vye3wMRdJj2pvWY4TkmBMw3iGFO034rKi=4C+qQ@mail.gmail.com>

Hi,

I have shared all the information in this bug report
https://bugs.launchpad.net/skyline-apiserver/+bug/2025755

On Tue, Aug 29, 2023 at 5:09?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello,
>
> Can u share me OS and your file configure?
>
>
> Nguyen Huu Khoi
>
>
> On Mon, Aug 28, 2023 at 9:37?PM Satish Patel <satish.txt at gmail.com> wrote:
>
>> Zed stable.
>>
>> On Mon, Aug 28, 2023 at 10:26?AM Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com> wrote:
>>
>>> Which kolla version you deployed.
>>>
>>>
>>> On Mon, Aug 28, 2023, 9:22 PM Satish Patel <satish.txt at gmail.com> wrote:
>>>
>>>> No kidding, that is the doc I am following line by line and no error at
>>>> all during installation. Problems start when you try to get into the UI
>>>> interface and it throws username/password errors. Could you please share
>>>> your skyline.yml config file (ofc hide your password :) )
>>>>
>>>> ~S
>>>>
>>>> On Mon, Aug 28, 2023 at 9:47?AM Nguy?n H?u Kh?i <
>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>
>>>>> No.
>>>>> I set it seperately.
>>>>>
>>>>>
>>>>> https://docs.openstack.org/skyline-console/latest/install/docker-install-ubuntu.html
>>>>>
>>>>> On Mon, Aug 28, 2023, 8:41 PM Satish Patel <satish.txt at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Can you tell me how you set it with kolla-ansible?
>>>>>>
>>>>>> Did you set this in globals.yml and just playbook? Trying to
>>>>>> understand what are the differences between my method and yours :)
>>>>>> enable_skyline: yes
>>>>>>
>>>>>> On Mon, Aug 28, 2023 at 9:15?AM Nguy?n H?u Kh?i <
>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>
>>>>>>> It is ok with docker. I use it with my exist cloud by kolla ansible.
>>>>>>>
>>>>>>> On Mon, Aug 28, 2023, 8:09 PM Satish Patel <satish.txt at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This is very odd, I am following line to line doc from skyline
>>>>>>>> official page and its docker container but still getting the same error on
>>>>>>>> multiple machines. Same time the developer says it's working for them. How
>>>>>>>> to get help and move forward from here?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Aug 25, 2023 at 12:53?AM Nguy?n H?u Kh?i <
>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> I got same problem but with mariadb.
>>>>>>>>> Nguyen Huu Khoi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Aug 8, 2023 at 12:17?PM Satish Patel <satish.txt at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Update:
>>>>>>>>>>
>>>>>>>>>> After switching DB from sqlite to mysql DB it works. Now admin
>>>>>>>>>> account works but when I login with _member_ users or normal account and
>>>>>>>>>> trying to create instance then pop up windows throwing error:
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>>   "message": "You don't have access to get instances.",
>>>>>>>>>>   "status": 401
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 7, 2023 at 11:51?PM Satish Patel <
>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Skyline Team,
>>>>>>>>>>>
>>>>>>>>>>> I found similar issue in BUG Report but no solution yet
>>>>>>>>>>>
>>>>>>>>>>> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 7, 2023 at 7:25?PM Satish Patel <
>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Folks,
>>>>>>>>>>>>
>>>>>>>>>>>> Try to install skyline UI to replace horizon using doc:
>>>>>>>>>>>> https://docs.openstack.org/skyline-apiserver/latest/install/docker-install-ubuntu.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Everything went well and I got a login page on
>>>>>>>>>>>> http://x.x.x.x:9999 also it pulled Region/Domains. When I am
>>>>>>>>>>>> trying to login with my account, I get an error: Username or Password is
>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>
>>>>>>>>>>>> I am using sqlite DB for skyline as per documents.
>>>>>>>>>>>>
>>>>>>>>>>>> No errors in logs command
>>>>>>>>>>>> $ docker logs skyline
>>>>>>>>>>>>
>>>>>>>>>>>> When I use Chrome Developer Tools then it was indicating an
>>>>>>>>>>>> error in these URLs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/profile
>>>>>>>>>>>>
>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/policies
>>>>>>>>>>>>
>>>>>>>>>>>> 401 Unauthorized ( {"detail":"no such table: revoked_token"} )
>>>>>>>>>>>>
>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/7e0ff55d/attachment-0001.htm>

From satish.txt at gmail.com  Fri Sep  8 21:17:11 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Fri, 8 Sep 2023 17:17:11 -0400
Subject: [Skyline] error username or password incorrect
In-Reply-To: <CAPgF-fpRNV-5Y65syrRNJ1VT0yg3XP_1oNo6nuUp3w1pxuH5Og@mail.gmail.com>
References: <CAPgF-fqgk=zFdetgrT+kr1tiQevNxwHVT8tgyQ+88w4wR0qU9g@mail.gmail.com>
 <CAPgF-fqo4Tev15oeObkJBq-f-h3M4VKy1JsZY7ZHXfFHpDpcVg@mail.gmail.com>
 <CAPgF-fo8wX-2go2wKQ6n1ZL_MLYXhR7K61Z7LsQmnRjb0dvcVA@mail.gmail.com>
 <CABAODRcbmAZ7m+A=ye2MsKaCUhZTWzksPcYfMDB36xDWagQBWg@mail.gmail.com>
 <CAPgF-fpGXDMD9+1vFJKSQFSRb3xskhBvsUpLPX1N0fRQYLz8NQ@mail.gmail.com>
 <CABAODReHKzqNeLN+JY_WPwtHkebS1E5QhwUEdE2aUtbGt_DEUQ@mail.gmail.com>
 <CAPgF-foxeMDoRBdD1oi7d2tynVi3cNO7SJu-p-yyC7tAH9u+qw@mail.gmail.com>
 <CABAODRfJb1eaQ=7WDaKQs34dj6jrtU7tD=DvYADUOX5rOU5eBQ@mail.gmail.com>
 <CAPgF-frY==mp=81YV_LtjmMvaqmCVkz+JmfGJLwOq5iGx+vr5A@mail.gmail.com>
 <CABAODRdOogiHNo2xZ7QiYRQeWR2aPHP7zas=7WrWHG6jHWWaMA@mail.gmail.com>
 <CAPgF-fqMPDB3KMQLvJQ1y6rtXuQtmEVBaa7mnE0T3f3Q9EKBRw@mail.gmail.com>
 <CABAODRfq-jFRJzaNbypy3rT_vhUV6DQFVpmjL-hAsLRj=RPTgA@mail.gmail.com>
 <CAPgF-fp2Wh=vye3wMRdJj2pvWY4TkmBMw3iGFO034rKi=4C+qQ@mail.gmail.com>
 <CAPgF-fpRNV-5Y65syrRNJ1VT0yg3XP_1oNo6nuUp3w1pxuH5Og@mail.gmail.com>
Message-ID: <CAPgF-fpfYqH5dqfyU=C0y_7dfbHsv7KKSbe0FNdmipRgZOV96g@mail.gmail.com>

I found similar bug here
https://bugs.launchpad.net/skyline-apiserver/+bug/1942284

On Fri, Sep 8, 2023 at 5:11?PM Satish Patel <satish.txt at gmail.com> wrote:

> This is my fill configuration of skyline.yaml, my problem is I can get
> into the interface with the admin account and everything works. But when I
> login as normal user account and try to do anything it throwing error
>
> {
>   "message": "You don't have access to get instances.",
>   "status": 401
> }
>
> Find attached screenshot.
>
>
> # cat /etc/skyline/skyline.yaml
> default:
>   access_token_expire: 3600
>   access_token_renew: 1800
>   cors_allow_origins: []
>   #database_url: sqlite:////tmp/skyline.db
>   database_url: mysql://skyline:myskylinedb123 at localhost:3306/skyline
>   debug: true
>   log_dir: /var/log
>   log_file: skyline.log
>   prometheus_basic_auth_password: ''
>   prometheus_basic_auth_user: ''
>   prometheus_enable_basic_auth: false
>   prometheus_endpoint: http://localhost:9091
>   secret_key: aCtmgbcUqYUy_HNVg5BDXCaeJgJQzHJXwqbXr0Nmb2o
>   session_name: session
>   ssl_enabled: true
> openstack:
>   base_domains:
>   - heat_user_domain
>   default_region: RegionOne
>   enforce_new_defaults: true
>   extension_mapping:
>     floating-ip-port-forwarding: neutron_port_forwarding
>     fwaas_v2: neutron_firewall
>     qos: neutron_qos
>     vpnaas: neutron_vpn
>   interface_type: public
>   keystone_url: http://10.30.50.10:5000/v3/
>   nginx_prefix: /api/openstack
>   reclaim_instance_interval: 604800
>   service_mapping:
>     baremetal: ironic
>     compute: nova
>     container: zun
>     container-infra: magnum
>     database: trove
>     identity: keystone
>     image: glance
>     key-manager: barbican
>     load-balancer: octavia
>     network: neutron
>     object-store: swift
>     orchestration: heat
>     placement: placement
>     sharev2: manilav2
>     volumev3: cinder
>   sso_enabled: false
>   sso_protocols:
>   - openid
>   sso_region: RegionOne
>   system_admin_roles:
>   - admin
>   - system_admin
>   system_project: service
>   system_project_domain: Default
>   system_reader_roles:
>   - system_reader
>   system_user_domain: Default
>   system_user_name: skyline
>   system_user_password: 'skyline123'
> setting:
>   base_settings:
>   - flavor_families
>   - gpu_models
>   - usb_models
>   flavor_families:
>   - architecture: x86_architecture
>     categories:
>     - name: general_purpose
>       properties: []
>     - name: compute_optimized
>       properties: []
>     - name: memory_optimized
>       properties: []
>     - name: high_clock_speed
>       properties: []
>   - architecture: heterogeneous_computing
>     categories:
>     - name: compute_optimized_type_with_gpu
>       properties: []
>     - name: visualization_compute_optimized_type_with_gpu
>       properties: []
>   gpu_models:
>   - nvidia_t4
>   usb_models:
>   - usb_c
>
> On Fri, Sep 8, 2023 at 4:44?PM Satish Patel <satish.txt at gmail.com> wrote:
>
>> Hi,
>>
>> I have shared all the information in this bug report
>> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>>
>> On Tue, Aug 29, 2023 at 5:09?AM Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Can u share me OS and your file configure?
>>>
>>>
>>> Nguyen Huu Khoi
>>>
>>>
>>> On Mon, Aug 28, 2023 at 9:37?PM Satish Patel <satish.txt at gmail.com>
>>> wrote:
>>>
>>>> Zed stable.
>>>>
>>>> On Mon, Aug 28, 2023 at 10:26?AM Nguy?n H?u Kh?i <
>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>
>>>>> Which kolla version you deployed.
>>>>>
>>>>>
>>>>> On Mon, Aug 28, 2023, 9:22 PM Satish Patel <satish.txt at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> No kidding, that is the doc I am following line by line and no error
>>>>>> at all during installation. Problems start when you try to get into the UI
>>>>>> interface and it throws username/password errors. Could you please share
>>>>>> your skyline.yml config file (ofc hide your password :) )
>>>>>>
>>>>>> ~S
>>>>>>
>>>>>> On Mon, Aug 28, 2023 at 9:47?AM Nguy?n H?u Kh?i <
>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>
>>>>>>> No.
>>>>>>> I set it seperately.
>>>>>>>
>>>>>>>
>>>>>>> https://docs.openstack.org/skyline-console/latest/install/docker-install-ubuntu.html
>>>>>>>
>>>>>>> On Mon, Aug 28, 2023, 8:41 PM Satish Patel <satish.txt at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Can you tell me how you set it with kolla-ansible?
>>>>>>>>
>>>>>>>> Did you set this in globals.yml and just playbook? Trying to
>>>>>>>> understand what are the differences between my method and yours :)
>>>>>>>> enable_skyline: yes
>>>>>>>>
>>>>>>>> On Mon, Aug 28, 2023 at 9:15?AM Nguy?n H?u Kh?i <
>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> It is ok with docker. I use it with my exist cloud by kolla
>>>>>>>>> ansible.
>>>>>>>>>
>>>>>>>>> On Mon, Aug 28, 2023, 8:09 PM Satish Patel <satish.txt at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> This is very odd, I am following line to line doc from skyline
>>>>>>>>>> official page and its docker container but still getting the same error on
>>>>>>>>>> multiple machines. Same time the developer says it's working for them. How
>>>>>>>>>> to get help and move forward from here?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 25, 2023 at 12:53?AM Nguy?n H?u Kh?i <
>>>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> I got same problem but with mariadb.
>>>>>>>>>>> Nguyen Huu Khoi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Aug 8, 2023 at 12:17?PM Satish Patel <
>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Update:
>>>>>>>>>>>>
>>>>>>>>>>>> After switching DB from sqlite to mysql DB it works. Now admin
>>>>>>>>>>>> account works but when I login with _member_ users or normal account and
>>>>>>>>>>>> trying to create instance then pop up windows throwing error:
>>>>>>>>>>>>
>>>>>>>>>>>> {
>>>>>>>>>>>>   "message": "You don't have access to get instances.",
>>>>>>>>>>>>   "status": 401
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Aug 7, 2023 at 11:51?PM Satish Patel <
>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Skyline Team,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I found similar issue in BUG Report but no solution yet
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Aug 7, 2023 at 7:25?PM Satish Patel <
>>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Try to install skyline UI to replace horizon using doc:
>>>>>>>>>>>>>> https://docs.openstack.org/skyline-apiserver/latest/install/docker-install-ubuntu.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Everything went well and I got a login page on
>>>>>>>>>>>>>> http://x.x.x.x:9999 also it pulled Region/Domains. When I am
>>>>>>>>>>>>>> trying to login with my account, I get an error: Username or Password is
>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am using sqlite DB for skyline as per documents.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No errors in logs command
>>>>>>>>>>>>>> $ docker logs skyline
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When I use Chrome Developer Tools then it was indicating an
>>>>>>>>>>>>>> error in these URLs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/profile
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/policies
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 401 Unauthorized ( {"detail":"no such table: revoked_token"}
>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/14422b5f/attachment.htm>

From satish.txt at gmail.com  Fri Sep  8 21:33:47 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Fri, 8 Sep 2023 17:33:47 -0400
Subject: [Skyline] error username or password incorrect
In-Reply-To: <CAPgF-fpfYqH5dqfyU=C0y_7dfbHsv7KKSbe0FNdmipRgZOV96g@mail.gmail.com>
References: <CAPgF-fqgk=zFdetgrT+kr1tiQevNxwHVT8tgyQ+88w4wR0qU9g@mail.gmail.com>
 <CAPgF-fqo4Tev15oeObkJBq-f-h3M4VKy1JsZY7ZHXfFHpDpcVg@mail.gmail.com>
 <CAPgF-fo8wX-2go2wKQ6n1ZL_MLYXhR7K61Z7LsQmnRjb0dvcVA@mail.gmail.com>
 <CABAODRcbmAZ7m+A=ye2MsKaCUhZTWzksPcYfMDB36xDWagQBWg@mail.gmail.com>
 <CAPgF-fpGXDMD9+1vFJKSQFSRb3xskhBvsUpLPX1N0fRQYLz8NQ@mail.gmail.com>
 <CABAODReHKzqNeLN+JY_WPwtHkebS1E5QhwUEdE2aUtbGt_DEUQ@mail.gmail.com>
 <CAPgF-foxeMDoRBdD1oi7d2tynVi3cNO7SJu-p-yyC7tAH9u+qw@mail.gmail.com>
 <CABAODRfJb1eaQ=7WDaKQs34dj6jrtU7tD=DvYADUOX5rOU5eBQ@mail.gmail.com>
 <CAPgF-frY==mp=81YV_LtjmMvaqmCVkz+JmfGJLwOq5iGx+vr5A@mail.gmail.com>
 <CABAODRdOogiHNo2xZ7QiYRQeWR2aPHP7zas=7WrWHG6jHWWaMA@mail.gmail.com>
 <CAPgF-fqMPDB3KMQLvJQ1y6rtXuQtmEVBaa7mnE0T3f3Q9EKBRw@mail.gmail.com>
 <CABAODRfq-jFRJzaNbypy3rT_vhUV6DQFVpmjL-hAsLRj=RPTgA@mail.gmail.com>
 <CAPgF-fp2Wh=vye3wMRdJj2pvWY4TkmBMw3iGFO034rKi=4C+qQ@mail.gmail.com>
 <CAPgF-fpRNV-5Y65syrRNJ1VT0yg3XP_1oNo6nuUp3w1pxuH5Og@mail.gmail.com>
 <CAPgF-fpfYqH5dqfyU=C0y_7dfbHsv7KKSbe0FNdmipRgZOV96g@mail.gmail.com>
Message-ID: <CAPgF-fowoLU-p5wSYQvrd=Nbm-tzcMmgxFCJLUW9fKkUaJ-JVQ@mail.gmail.com>

I found my issue and reported here

https://bugs.launchpad.net/skyline-apiserver/+bug/2034976

On Fri, Sep 8, 2023 at 5:17?PM Satish Patel <satish.txt at gmail.com> wrote:

> I found similar bug here
> https://bugs.launchpad.net/skyline-apiserver/+bug/1942284
>
> On Fri, Sep 8, 2023 at 5:11?PM Satish Patel <satish.txt at gmail.com> wrote:
>
>> This is my fill configuration of skyline.yaml, my problem is I can get
>> into the interface with the admin account and everything works. But when I
>> login as normal user account and try to do anything it throwing error
>>
>> {
>>   "message": "You don't have access to get instances.",
>>   "status": 401
>> }
>>
>> Find attached screenshot.
>>
>>
>> # cat /etc/skyline/skyline.yaml
>> default:
>>   access_token_expire: 3600
>>   access_token_renew: 1800
>>   cors_allow_origins: []
>>   #database_url: sqlite:////tmp/skyline.db
>>   database_url: mysql://skyline:myskylinedb123 at localhost:3306/skyline
>>   debug: true
>>   log_dir: /var/log
>>   log_file: skyline.log
>>   prometheus_basic_auth_password: ''
>>   prometheus_basic_auth_user: ''
>>   prometheus_enable_basic_auth: false
>>   prometheus_endpoint: http://localhost:9091
>>   secret_key: aCtmgbcUqYUy_HNVg5BDXCaeJgJQzHJXwqbXr0Nmb2o
>>   session_name: session
>>   ssl_enabled: true
>> openstack:
>>   base_domains:
>>   - heat_user_domain
>>   default_region: RegionOne
>>   enforce_new_defaults: true
>>   extension_mapping:
>>     floating-ip-port-forwarding: neutron_port_forwarding
>>     fwaas_v2: neutron_firewall
>>     qos: neutron_qos
>>     vpnaas: neutron_vpn
>>   interface_type: public
>>   keystone_url: http://10.30.50.10:5000/v3/
>>   nginx_prefix: /api/openstack
>>   reclaim_instance_interval: 604800
>>   service_mapping:
>>     baremetal: ironic
>>     compute: nova
>>     container: zun
>>     container-infra: magnum
>>     database: trove
>>     identity: keystone
>>     image: glance
>>     key-manager: barbican
>>     load-balancer: octavia
>>     network: neutron
>>     object-store: swift
>>     orchestration: heat
>>     placement: placement
>>     sharev2: manilav2
>>     volumev3: cinder
>>   sso_enabled: false
>>   sso_protocols:
>>   - openid
>>   sso_region: RegionOne
>>   system_admin_roles:
>>   - admin
>>   - system_admin
>>   system_project: service
>>   system_project_domain: Default
>>   system_reader_roles:
>>   - system_reader
>>   system_user_domain: Default
>>   system_user_name: skyline
>>   system_user_password: 'skyline123'
>> setting:
>>   base_settings:
>>   - flavor_families
>>   - gpu_models
>>   - usb_models
>>   flavor_families:
>>   - architecture: x86_architecture
>>     categories:
>>     - name: general_purpose
>>       properties: []
>>     - name: compute_optimized
>>       properties: []
>>     - name: memory_optimized
>>       properties: []
>>     - name: high_clock_speed
>>       properties: []
>>   - architecture: heterogeneous_computing
>>     categories:
>>     - name: compute_optimized_type_with_gpu
>>       properties: []
>>     - name: visualization_compute_optimized_type_with_gpu
>>       properties: []
>>   gpu_models:
>>   - nvidia_t4
>>   usb_models:
>>   - usb_c
>>
>> On Fri, Sep 8, 2023 at 4:44?PM Satish Patel <satish.txt at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have shared all the information in this bug report
>>> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>>>
>>> On Tue, Aug 29, 2023 at 5:09?AM Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Can u share me OS and your file configure?
>>>>
>>>>
>>>> Nguyen Huu Khoi
>>>>
>>>>
>>>> On Mon, Aug 28, 2023 at 9:37?PM Satish Patel <satish.txt at gmail.com>
>>>> wrote:
>>>>
>>>>> Zed stable.
>>>>>
>>>>> On Mon, Aug 28, 2023 at 10:26?AM Nguy?n H?u Kh?i <
>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>
>>>>>> Which kolla version you deployed.
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 28, 2023, 9:22 PM Satish Patel <satish.txt at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> No kidding, that is the doc I am following line by line and no error
>>>>>>> at all during installation. Problems start when you try to get into the UI
>>>>>>> interface and it throws username/password errors. Could you please share
>>>>>>> your skyline.yml config file (ofc hide your password :) )
>>>>>>>
>>>>>>> ~S
>>>>>>>
>>>>>>> On Mon, Aug 28, 2023 at 9:47?AM Nguy?n H?u Kh?i <
>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>
>>>>>>>> No.
>>>>>>>> I set it seperately.
>>>>>>>>
>>>>>>>>
>>>>>>>> https://docs.openstack.org/skyline-console/latest/install/docker-install-ubuntu.html
>>>>>>>>
>>>>>>>> On Mon, Aug 28, 2023, 8:41 PM Satish Patel <satish.txt at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Can you tell me how you set it with kolla-ansible?
>>>>>>>>>
>>>>>>>>> Did you set this in globals.yml and just playbook? Trying to
>>>>>>>>> understand what are the differences between my method and yours :)
>>>>>>>>> enable_skyline: yes
>>>>>>>>>
>>>>>>>>> On Mon, Aug 28, 2023 at 9:15?AM Nguy?n H?u Kh?i <
>>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> It is ok with docker. I use it with my exist cloud by kolla
>>>>>>>>>> ansible.
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 28, 2023, 8:09 PM Satish Patel <satish.txt at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> This is very odd, I am following line to line doc from skyline
>>>>>>>>>>> official page and its docker container but still getting the same error on
>>>>>>>>>>> multiple machines. Same time the developer says it's working for them. How
>>>>>>>>>>> to get help and move forward from here?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Aug 25, 2023 at 12:53?AM Nguy?n H?u Kh?i <
>>>>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> I got same problem but with mariadb.
>>>>>>>>>>>> Nguyen Huu Khoi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Aug 8, 2023 at 12:17?PM Satish Patel <
>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Update:
>>>>>>>>>>>>>
>>>>>>>>>>>>> After switching DB from sqlite to mysql DB it works. Now admin
>>>>>>>>>>>>> account works but when I login with _member_ users or normal account and
>>>>>>>>>>>>> trying to create instance then pop up windows throwing error:
>>>>>>>>>>>>>
>>>>>>>>>>>>> {
>>>>>>>>>>>>>   "message": "You don't have access to get instances.",
>>>>>>>>>>>>>   "status": 401
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Aug 7, 2023 at 11:51?PM Satish Patel <
>>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Skyline Team,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I found similar issue in BUG Report but no solution yet
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Aug 7, 2023 at 7:25?PM Satish Patel <
>>>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Try to install skyline UI to replace horizon using doc:
>>>>>>>>>>>>>>> https://docs.openstack.org/skyline-apiserver/latest/install/docker-install-ubuntu.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Everything went well and I got a login page on
>>>>>>>>>>>>>>> http://x.x.x.x:9999 also it pulled Region/Domains. When I
>>>>>>>>>>>>>>> am trying to login with my account, I get an error: Username or Password is
>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am using sqlite DB for skyline as per documents.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No errors in logs command
>>>>>>>>>>>>>>> $ docker logs skyline
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When I use Chrome Developer Tools then it was indicating an
>>>>>>>>>>>>>>> error in these URLs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/profile
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/policies
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 401 Unauthorized ( {"detail":"no such table:
>>>>>>>>>>>>>>> revoked_token"} )
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/dd96e3d9/attachment-0001.htm>

From satish.txt at gmail.com  Fri Sep  8 21:11:36 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Fri, 8 Sep 2023 17:11:36 -0400
Subject: [Skyline] error username or password incorrect
In-Reply-To: <CAPgF-fp2Wh=vye3wMRdJj2pvWY4TkmBMw3iGFO034rKi=4C+qQ@mail.gmail.com>
References: <CAPgF-fqgk=zFdetgrT+kr1tiQevNxwHVT8tgyQ+88w4wR0qU9g@mail.gmail.com>
 <CAPgF-fqo4Tev15oeObkJBq-f-h3M4VKy1JsZY7ZHXfFHpDpcVg@mail.gmail.com>
 <CAPgF-fo8wX-2go2wKQ6n1ZL_MLYXhR7K61Z7LsQmnRjb0dvcVA@mail.gmail.com>
 <CABAODRcbmAZ7m+A=ye2MsKaCUhZTWzksPcYfMDB36xDWagQBWg@mail.gmail.com>
 <CAPgF-fpGXDMD9+1vFJKSQFSRb3xskhBvsUpLPX1N0fRQYLz8NQ@mail.gmail.com>
 <CABAODReHKzqNeLN+JY_WPwtHkebS1E5QhwUEdE2aUtbGt_DEUQ@mail.gmail.com>
 <CAPgF-foxeMDoRBdD1oi7d2tynVi3cNO7SJu-p-yyC7tAH9u+qw@mail.gmail.com>
 <CABAODRfJb1eaQ=7WDaKQs34dj6jrtU7tD=DvYADUOX5rOU5eBQ@mail.gmail.com>
 <CAPgF-frY==mp=81YV_LtjmMvaqmCVkz+JmfGJLwOq5iGx+vr5A@mail.gmail.com>
 <CABAODRdOogiHNo2xZ7QiYRQeWR2aPHP7zas=7WrWHG6jHWWaMA@mail.gmail.com>
 <CAPgF-fqMPDB3KMQLvJQ1y6rtXuQtmEVBaa7mnE0T3f3Q9EKBRw@mail.gmail.com>
 <CABAODRfq-jFRJzaNbypy3rT_vhUV6DQFVpmjL-hAsLRj=RPTgA@mail.gmail.com>
 <CAPgF-fp2Wh=vye3wMRdJj2pvWY4TkmBMw3iGFO034rKi=4C+qQ@mail.gmail.com>
Message-ID: <CAPgF-fpRNV-5Y65syrRNJ1VT0yg3XP_1oNo6nuUp3w1pxuH5Og@mail.gmail.com>

This is my fill configuration of skyline.yaml, my problem is I can get into
the interface with the admin account and everything works. But when I login
as normal user account and try to do anything it throwing error

{
  "message": "You don't have access to get instances.",
  "status": 401
}

Find attached screenshot.


# cat /etc/skyline/skyline.yaml
default:
  access_token_expire: 3600
  access_token_renew: 1800
  cors_allow_origins: []
  #database_url: sqlite:////tmp/skyline.db
  database_url: mysql://skyline:myskylinedb123 at localhost:3306/skyline
  debug: true
  log_dir: /var/log
  log_file: skyline.log
  prometheus_basic_auth_password: ''
  prometheus_basic_auth_user: ''
  prometheus_enable_basic_auth: false
  prometheus_endpoint: http://localhost:9091
  secret_key: aCtmgbcUqYUy_HNVg5BDXCaeJgJQzHJXwqbXr0Nmb2o
  session_name: session
  ssl_enabled: true
openstack:
  base_domains:
  - heat_user_domain
  default_region: RegionOne
  enforce_new_defaults: true
  extension_mapping:
    floating-ip-port-forwarding: neutron_port_forwarding
    fwaas_v2: neutron_firewall
    qos: neutron_qos
    vpnaas: neutron_vpn
  interface_type: public
  keystone_url: http://10.30.50.10:5000/v3/
  nginx_prefix: /api/openstack
  reclaim_instance_interval: 604800
  service_mapping:
    baremetal: ironic
    compute: nova
    container: zun
    container-infra: magnum
    database: trove
    identity: keystone
    image: glance
    key-manager: barbican
    load-balancer: octavia
    network: neutron
    object-store: swift
    orchestration: heat
    placement: placement
    sharev2: manilav2
    volumev3: cinder
  sso_enabled: false
  sso_protocols:
  - openid
  sso_region: RegionOne
  system_admin_roles:
  - admin
  - system_admin
  system_project: service
  system_project_domain: Default
  system_reader_roles:
  - system_reader
  system_user_domain: Default
  system_user_name: skyline
  system_user_password: 'skyline123'
setting:
  base_settings:
  - flavor_families
  - gpu_models
  - usb_models
  flavor_families:
  - architecture: x86_architecture
    categories:
    - name: general_purpose
      properties: []
    - name: compute_optimized
      properties: []
    - name: memory_optimized
      properties: []
    - name: high_clock_speed
      properties: []
  - architecture: heterogeneous_computing
    categories:
    - name: compute_optimized_type_with_gpu
      properties: []
    - name: visualization_compute_optimized_type_with_gpu
      properties: []
  gpu_models:
  - nvidia_t4
  usb_models:
  - usb_c

On Fri, Sep 8, 2023 at 4:44?PM Satish Patel <satish.txt at gmail.com> wrote:

> Hi,
>
> I have shared all the information in this bug report
> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>
> On Tue, Aug 29, 2023 at 5:09?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello,
>>
>> Can u share me OS and your file configure?
>>
>>
>> Nguyen Huu Khoi
>>
>>
>> On Mon, Aug 28, 2023 at 9:37?PM Satish Patel <satish.txt at gmail.com>
>> wrote:
>>
>>> Zed stable.
>>>
>>> On Mon, Aug 28, 2023 at 10:26?AM Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com> wrote:
>>>
>>>> Which kolla version you deployed.
>>>>
>>>>
>>>> On Mon, Aug 28, 2023, 9:22 PM Satish Patel <satish.txt at gmail.com>
>>>> wrote:
>>>>
>>>>> No kidding, that is the doc I am following line by line and no error
>>>>> at all during installation. Problems start when you try to get into the UI
>>>>> interface and it throws username/password errors. Could you please share
>>>>> your skyline.yml config file (ofc hide your password :) )
>>>>>
>>>>> ~S
>>>>>
>>>>> On Mon, Aug 28, 2023 at 9:47?AM Nguy?n H?u Kh?i <
>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>
>>>>>> No.
>>>>>> I set it seperately.
>>>>>>
>>>>>>
>>>>>> https://docs.openstack.org/skyline-console/latest/install/docker-install-ubuntu.html
>>>>>>
>>>>>> On Mon, Aug 28, 2023, 8:41 PM Satish Patel <satish.txt at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Can you tell me how you set it with kolla-ansible?
>>>>>>>
>>>>>>> Did you set this in globals.yml and just playbook? Trying to
>>>>>>> understand what are the differences between my method and yours :)
>>>>>>> enable_skyline: yes
>>>>>>>
>>>>>>> On Mon, Aug 28, 2023 at 9:15?AM Nguy?n H?u Kh?i <
>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>
>>>>>>>> It is ok with docker. I use it with my exist cloud by kolla ansible.
>>>>>>>>
>>>>>>>> On Mon, Aug 28, 2023, 8:09 PM Satish Patel <satish.txt at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> This is very odd, I am following line to line doc from skyline
>>>>>>>>> official page and its docker container but still getting the same error on
>>>>>>>>> multiple machines. Same time the developer says it's working for them. How
>>>>>>>>> to get help and move forward from here?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Aug 25, 2023 at 12:53?AM Nguy?n H?u Kh?i <
>>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> I got same problem but with mariadb.
>>>>>>>>>> Nguyen Huu Khoi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Aug 8, 2023 at 12:17?PM Satish Patel <
>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Update:
>>>>>>>>>>>
>>>>>>>>>>> After switching DB from sqlite to mysql DB it works. Now admin
>>>>>>>>>>> account works but when I login with _member_ users or normal account and
>>>>>>>>>>> trying to create instance then pop up windows throwing error:
>>>>>>>>>>>
>>>>>>>>>>> {
>>>>>>>>>>>   "message": "You don't have access to get instances.",
>>>>>>>>>>>   "status": 401
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 7, 2023 at 11:51?PM Satish Patel <
>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Skyline Team,
>>>>>>>>>>>>
>>>>>>>>>>>> I found similar issue in BUG Report but no solution yet
>>>>>>>>>>>>
>>>>>>>>>>>> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Aug 7, 2023 at 7:25?PM Satish Patel <
>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try to install skyline UI to replace horizon using doc:
>>>>>>>>>>>>> https://docs.openstack.org/skyline-apiserver/latest/install/docker-install-ubuntu.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Everything went well and I got a login page on
>>>>>>>>>>>>> http://x.x.x.x:9999 also it pulled Region/Domains. When I am
>>>>>>>>>>>>> trying to login with my account, I get an error: Username or Password is
>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am using sqlite DB for skyline as per documents.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No errors in logs command
>>>>>>>>>>>>> $ docker logs skyline
>>>>>>>>>>>>>
>>>>>>>>>>>>> When I use Chrome Developer Tools then it was indicating an
>>>>>>>>>>>>> error in these URLs.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/profile
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/policies
>>>>>>>>>>>>>
>>>>>>>>>>>>> 401 Unauthorized ( {"detail":"no such table: revoked_token"}
>>>>>>>>>>>>> )
>>>>>>>>>>>>>
>>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/36829485/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-09-08 at 5.11.07 PM.png
Type: image/png
Size: 362611 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230908/36829485/attachment-0001.png>

From kjme001 at gmail.com  Sat Sep  9 05:26:43 2023
From: kjme001 at gmail.com (-)
Date: Sat, 9 Sep 2023 07:26:43 +0200
Subject: No valid host was found. There are not enough hosts available
Message-ID: <CAHjb3iF_ZQbwrFW4q--FQ1SYMjtrgNRSjQJyMDEwP_hSj4TT_Q@mail.gmail.com>

I added a new node to the OpenStack cluster and when creating a new
instance I have this error. Maybe someone can tell me what else I can
check? No valid host was found. There are not enough hosts available.

No valid host was found. There are not enough hosts available.
Kod
500

Traceback (most recent call last): File
"/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 1548,
in schedule_and_build_instances host_lists =
self._schedule_instances(context, request_specs[0], File
"/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 908,
in _schedule_instances host_lists =
self.query_client.select_destinations( File
"/usr/lib/python3/dist-packages/nova/scheduler/client/query.py", line
41, in select_destinations return
self.scheduler_rpcapi.select_destinations(context, spec_obj, File
"/usr/lib/python3/dist-packages/nova/scheduler/rpcapi.py", line 160,
in select_destinations return cctxt.call(ctxt, 'select_destinations',
**msg_args) File
"/usr/lib/python3/dist-packages/oslo_messaging/rpc/client.py", line
189, in call result = self.transport._send( File
"/usr/lib/python3/dist-packages/oslo_messaging/transport.py", line
123, in _send return self._driver.send(target, ctxt, message, File
"/usr/lib/python3/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
line 689, in send return self._send(target, ctxt, message,
wait_for_reply, timeout, File
"/usr/lib/python3/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
line 681, in _send raise result
nova.exception_Remote.NoValidHost_Remote: No valid host was found.
There are not enough hosts available. Traceback (most recent call
last): File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/server.py",
line 241, in inner return func(*args, **kwargs) File
"/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 223,
in select_destinations selections = self._select_destinations( File
"/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 250,
in _select_destinations selections = self._schedule( File
"/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 416,
in _schedule self._ensure_sufficient_hosts( File
"/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 455,
in _ensure_sufficient_hosts raise exception.NoValidHost(reason=reason)
nova.exception.NoValidHost: No valid host was found. There are not
enough hosts available.
Utworzono
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230909/aabe4989/attachment.htm>

From satish.txt at gmail.com  Sun Sep 10 03:09:18 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Sat, 9 Sep 2023 23:09:18 -0400
Subject: [kolla-ansible][ovn] availability zone for OVN
Message-ID: <CAPgF-fomCgpUMbJpfx9DyoPiHoW=yYOygk-SptCrx1KxHabR3Q@mail.gmail.com>

Folks,

I am trying to set an availability zone for OVN because skyline UI has a
mandatory requirement to have an availability zone otherwise you are not
allowed to create a network from skyline GUI.

for OVN based deployment only option to set AZ is in ovn-cms-options

# ovs-vsctl set open_vswitch .
external_ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0"

Question:

1. How do I configure in kolla-ansible to override or set ovn-cms-options
on only gateway chassis?
2. How does AZ work in OVN because OVN is anyway distributed as per
documents, What if I just give foobar AZ name to meet Skyline requirement?
Is it going to break anything?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230909/3468b25e/attachment.htm>

From bshephar at redhat.com  Sun Sep 10 09:44:24 2023
From: bshephar at redhat.com (Brendan Shephard)
Date: Sun, 10 Sep 2023 19:44:24 +1000
Subject: No valid host was found. There are not enough hosts available
In-Reply-To: <CAHjb3iF_ZQbwrFW4q--FQ1SYMjtrgNRSjQJyMDEwP_hSj4TT_Q@mail.gmail.com>
References: <CAHjb3iF_ZQbwrFW4q--FQ1SYMjtrgNRSjQJyMDEwP_hSj4TT_Q@mail.gmail.com>
Message-ID: <A341B300-42C4-437A-A167-B689C08A2CB6@redhat.com>

Hey,

This is a scheduling issue. It means that Nova scheduler was unable to find any nodes matching the requirements for your VM.

You can enable debug in nova.conf and re-try. The scheduler debug logs will tell you which filter isn?t returning any hosts.

Some helpful info for you here:
https://stackoverflow.com/a/50447850?
NoValidHost: No valid host was found. There are not enough hosts available
stackoverflow.com


Regards,

Brendan Shephard
Senior Software Engineer
Red Hat Australia



> On 9 Sep 2023, at 3:26?pm, - <kjme001 at gmail.com> wrote:
> 
> I added a new node to the OpenStack cluster and when creating a new instance I have this error. Maybe someone can tell me what else I can check? No valid host was found. There are not enough hosts available.
> 
> No valid host was found. There are not enough hosts available.
> Kod
> 500
> 
> Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 1548, in schedule_and_build_instances host_lists = self._schedule_instances(context, request_specs[0], File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 908, in _schedule_instances host_lists = self.query_client.select_destinations( File "/usr/lib/python3/dist-packages/nova/scheduler/client/query.py", line 41, in select_destinations return self.scheduler_rpcapi.select_destinations(context, spec_obj, File "/usr/lib/python3/dist-packages/nova/scheduler/rpcapi.py", line 160, in select_destinations return cctxt.call(ctxt, 'select_destinations', **msg_args) File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/client.py", line 189, in call result = self.transport._send( File "/usr/lib/python3/dist-packages/oslo_messaging/transport.py", line 123, in _send return self._driver.send(target, ctxt, message, File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 689, in send return self._send(target, ctxt, message, wait_for_reply, timeout, File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 681, in _send raise result nova.exception_Remote.NoValidHost_Remote: No valid host was found. There are not enough hosts available. Traceback (most recent call last): File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/server.py", line 241, in inner return func(*args, **kwargs) File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 223, in select_destinations selections = self._select_destinations( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 250, in _select_destinations selections = self._schedule( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 416, in _schedule self._ensure_sufficient_hosts( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 455, in _ensure_sufficient_hosts raise exception.NoValidHost(reason=reason) nova.exception.NoValidHost: No valid host was found. There are not enough hosts available.
> Utworzono
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230910/d666a22e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apple-touch-icon at 2.png
Type: image/png
Size: 6562 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230910/d666a22e/attachment-0001.png>

From lucasagomes at gmail.com  Sun Sep 10 13:51:42 2023
From: lucasagomes at gmail.com (Lucas Alvares Gomes)
Date: Sun, 10 Sep 2023 14:51:42 +0100
Subject: [kolla-ansible][ovn] availability zone for OVN
In-Reply-To: <CAPgF-fomCgpUMbJpfx9DyoPiHoW=yYOygk-SptCrx1KxHabR3Q@mail.gmail.com>
References: <CAPgF-fomCgpUMbJpfx9DyoPiHoW=yYOygk-SptCrx1KxHabR3Q@mail.gmail.com>
Message-ID: <CAB1EZBoyLi5Z7d+QP6srr0HcTeOp6z_xHnv_MODq5x-CHhB8Vw@mail.gmail.com>

On Sun, Sep 10, 2023 at 4:13?AM Satish Patel <satish.txt at gmail.com> wrote:
>
> Folks,
>
> I am trying to set an availability zone for OVN because skyline UI has a mandatory requirement to have an availability zone otherwise you are not allowed to create a network from skyline GUI.
>
> for OVN based deployment only option to set AZ is in ovn-cms-options
>
> # ovs-vsctl set open_vswitch . external_ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0"
>
> Question:
>
> 1. How do I configure in kolla-ansible to override or set ovn-cms-options on only gateway chassis?
> 2. How does AZ work in OVN because OVN is anyway distributed as per documents, What if I just give foobar AZ name to meet Skyline requirement? Is it going to break anything?

Answering 2.

There are two types of availability zones in Neutron: Routers and Networks.

For Routers, ML2/OVN will schedule the gateway router ports onto the
nodes belonging to the availability zones provided by the
--availability-zone-hint parameter, for example:

$ openstack router create --availability-zone-hint az-0
--availability-zone-hint az-1 router-0

For Networks. Since DHCP is distributed in ML2/OVN as you pointed out
we do not care about scheduling DHCP agents (like ML2/OVS). But there
are few cases for Network AZ in ML2/OVN that are related to external
ports [0], these are ports that live on a different host than the
instance to address use cases such as SR-IOV and Baremetal with
ML2/OVN.

You can read more ML2/OVN AZs here:
https://docs.openstack.org/neutron/latest/admin/ovn/availability_zones.html

[0] https://docs.openstack.org/neutron/latest/admin/ovn/external_ports.html

Cheers,
Lucas


From hanoi952022 at gmail.com  Sun Sep 10 08:23:09 2023
From: hanoi952022 at gmail.com (Ha Noi)
Date: Sun, 10 Sep 2023 15:23:09 +0700
Subject: [openstack][neutron][openvswitch] Openvswitch Packet loss when
 high throughput (pps)
In-Reply-To: <1273520546bf8174f04012ef6c442439e9dd84da.camel@redhat.com>
References: <CAPTyaN-e2ug7SjtKQQ2y4SXFXrKw4h94wRg2U2ACW5=N7EyMng@mail.gmail.com>
 <CAPgF-fp7F2gpiC95jbrmgigOw0pex_i0YzLPjZ=Z2MSH38-D3w@mail.gmail.com>
 <CAPTyaN9FOsnkWNsOR8L+NEwOu7xa56V_2jFs44y2go-e++MPBQ@mail.gmail.com>
 <CAPgF-foxMky3y=uSp5KSdNbXMkPx9Txx+p-aout5Zzy7M5=-DQ@mail.gmail.com>
 <0278613d4d6f217482014c08e50cfbbcf4acc5c6.camel@redhat.com>
 <CAPTyaN-s_0kuAVSvaaOkQYmhTpyjV1vqvfW2ki8XwEf8XWc4sA@mail.gmail.com>
 <CAPgF-foy9QLVM=mVp5_SUTLgnpXdNgPpmQp+Y476ynwf1Ap+gw@mail.gmail.com>
 <CAPTyaN9Coat8UB-hLKP=0nKkDzPhyX_w-cjPODTmyQYgK0fwFQ@mail.gmail.com>
 <CAPgF-foXR2r524xHKoZEzxHga824zgFuM+MhdXQXCen7n0wW9g@mail.gmail.com>
 <CAPTyaN_Ni_TnNuxgtK5C8nDL2v9J2S9uj3i-g_EaWk62VWPJjA@mail.gmail.com>
 <CAPgF-fqJbS=HitSiFbZF4PW_OYcFCnqntuRM7nkZQHVu6wqe3A@mail.gmail.com>
 <CAPTyaN-5P1uCXnz9i-WJ5A+hGRemgfZihGthubJz=wO7qDnCgA@mail.gmail.com>
 <CAPgF-fqWW+SC6aKM6wSM+CRXXhb_MtdXojJh08cg3uAhKpxa-g@mail.gmail.com>
 <CAPTyaN-5o1M-YBA5TY7QwrZT1PCGq7Nv06FXJTwpSTsTCgYe1Q@mail.gmail.com>
 <CAPgF-fqCx4Yh8wp8SrfNoDtf_CFzJzZ-k2URFMB0nB+rQSgtFA@mail.gmail.com>
 <1273520546bf8174f04012ef6c442439e9dd84da.camel@redhat.com>
Message-ID: <CAPTyaN8LtqRyiOa1W8izL9Y25SxYraG5TWs20+OYmdZ3PcU1Cg@mail.gmail.com>

Thanks Smooney,

I'm trying to test performance between 2 VMs using DPDK. And the high
latency does not appear any more. But the packet is still lost.

I will tune my system to get the highest throughput.

thanks you guys

On Fri, Sep 8, 2023 at 9:20?PM <smooney at redhat.com> wrote:

> On Thu, 2023-09-07 at 22:05 -0400, Satish Patel wrote:
> > Do one thing, use test-pmd base benchmark and see because test-pmd
> > application is DPDK aware. with test-pmd you will have a 1000% better
> > performance :)
>
> actully test-pmd is not DPDK aware
> its a dpdk applciation so it is faster because it remove the overhead of
> kernel networking in the guest
> not because it has any dpdk awareness. testpmd cannot tell that ovs-dpdk
> is in use
> form a gust perspecive you cannot tell if your using ovs-dpdk or kernel
> ovs as there is no viable diffence
> in the virtio-net-pci device which  is presented to the guest kernel by
> qemu.
>
> iper3 with a single core cant actully saturate a virtio-net-interface when
> its backed
> by vhost-user/dpdk or something like a macvtap sriov port.
> you can reach line rate with larger packet sizes or multipel cores but
> if you wanted too test small packet io then testpmd, dpdk packetgen  or
> tgen
> are better tools in that regard. they can eaiclly saturate a link into the
> 10s of gibitits per second using
> 64byte packets.
>
> >
> > On Thu, Sep 7, 2023 at 9:59?PM Ha Noi <hanoi952022 at gmail.com> wrote:
> >
> > > I run the performance test using iperf3. But the performance is not
> > > increased as theory. I don't know which configuration is not correct.
> > >
> > > On Fri, Sep 8, 2023 at 8:57?AM Satish Patel <satish.txt at gmail.com>
> wrote:
> > >
> > > > I would say let's run your same benchmark with OVS-DPDK and tell me
> if
> > > > you see better performance. I doubt you will see significant
> performance
> > > > boot but lets see. Please prove me wrong :)
> > > >
> > > > On Thu, Sep 7, 2023 at 9:45?PM Ha Noi <hanoi952022 at gmail.com> wrote:
> > > >
> > > > > Hi Satish,
> > > > >
> > > > > Actually, the guess interface is not using tap anymore.
> > > > >
> > > > >     <interface type='vhostuser'>
> > > > >       <mac address='fa:16:3e:76:77:dd'/>
> > > > >       <source type='unix'
> path='/var/run/openvswitch/vhu3766ee8a-86'
> > > > > mode='server'/>
> > > > >       <target dev='vhu3766ee8a-86'/>
> > > > >       <model type='virtio'/>
> > > > >       <alias name='net0'/>
> > > > >       <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
> > > > > function='0x0'/>
> > > > >     </interface>
> > > > >
> > > > > It's totally bypass the kernel stack ?
> yep dpdk is userspace networkign and it gets its performace boost form that
> so the data is "trasnproted" by doding a direct mmap of the virtio ring
> buffers
> between the DPDK pool mode driver and the qemu process.
>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 8, 2023 at 5:02?AM Satish Patel <satish.txt at gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I did test OVS-DPDK and it helps offload the packet process on
> compute
> > > > > > nodes, But what about VMs it will still use a tap interface to
> attach from
> > > > > > compute to vm and bottleneck will be in vm. I strongly believe
> that we have
> > > > > > to run DPDK based guest to pass through the kernel stack.
> > > > > >
> > > > > > I love to hear from other people if I am missing something here.
> > > > > >
> > > > > > On Thu, Sep 7, 2023 at 5:27?PM Ha Noi <hanoi952022 at gmail.com>
> wrote:
> > > > > >
> > > > > > > Oh. I heard from someone on the reddit said that Ovs-dpdk is
> > > > > > > transparent with user?
> > > > > > >
> > > > > > > So It?s not correct?
> > > > > > >
> > > > > > > On Thu, 7 Sep 2023 at 22:13 Satish Patel <satish.txt at gmail.com>
> wrote:
> > > > > > >
> > > > > > > > Because DPDK required DPDK support inside guest VM. It's not
> > > > > > > > suitable for general purpose workload. You need your guest
> VM network to
> > > > > > > > support DPDK to get 100% throughput.
> > > > > > > >
> > > > > > > > On Thu, Sep 7, 2023 at 8:06?AM Ha Noi <hanoi952022 at gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > > Hi Satish,
> > > > > > > > >
> > > > > > > > > Why dont you use DPDK?
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > >
> > > > > > > > > On Thu, 7 Sep 2023 at 19:03 Satish Patel <
> satish.txt at gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I totally agreed with Sean on all his points but trust
> me, I have
> > > > > > > > > > tried everything possible to tune OS, Network stack,
> multi-queue, NUMA, CPU
> > > > > > > > > > pinning and name it.. but I didn't get any significant
> improvement. You may
> > > > > > > > > > gain 2 to 5% gain with all those tweek. I am running the
> entire workload on
> > > > > > > > > > sriov and life is happy except no LACP bonding.
> > > > > > > > > >
> > > > > > > > > > I am very interesting is this project
> > > > > > > > > >
> https://docs.openvswitch.org/en/latest/intro/install/afxdp/
> > > > > > > > > >
> > > > > > > > > > On Thu, Sep 7, 2023 at 6:07?AM Ha Noi <
> hanoi952022 at gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Dear Smoney,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Sep 7, 2023 at 12:41?AM <smooney at redhat.com>
> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On Wed, 2023-09-06 at 11:43 -0400, Satish Patel
> wrote:
> > > > > > > > > > > > > Damn! We have noticed the same issue around 40k to
> 55k PPS.
> > > > > > > > > > > > Trust me
> > > > > > > > > > > > > nothing is wrong in your config. This is just a
> limitation of
> > > > > > > > > > > > the software
> > > > > > > > > > > > > stack and kernel itself.
> > > > > > > > > > > > its partly determined by your cpu frequency.
> > > > > > > > > > > > kernel ovs of yesteryear could handel about 1mpps
> total on a ~4GHZ
> > > > > > > > > > > > cpu. with per port troughpuyt being lower dependin
> on what
> > > > > > > > > > > > qos/firewall
> > > > > > > > > > > > rules that were apllied.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > My CPU frequency is 3Ghz and using CPU Intel Gold 2nd
> generation.
> > > > > > > > > > > I think the problem is tuning in the compute node
> inside. But I cannot find
> > > > > > > > > > > any guide or best practices for it.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > moving form iptables firewall to ovs firewall can
> help to some
> > > > > > > > > > > > degree
> > > > > > > > > > > > but your partly trading connection setup time for
> statead state
> > > > > > > > > > > > troughput
> > > > > > > > > > > > with the overhead of the connection tracker in ovs.
> > > > > > > > > > > >
> > > > > > > > > > > > using stateless security groups can help
> > > > > > > > > > > >
> > > > > > > > > > > > we also recently fixed a regression cause by changes
> in newer
> > > > > > > > > > > > versions of ovs.
> > > > > > > > > > > > this was notable in goign form rhel 8 to rhel 9
> where litrally it
> > > > > > > > > > > > reduced
> > > > > > > > > > > > small packet performce to 1/10th and jumboframes to
> about 1/2
> > > > > > > > > > > > on master we have a config option that will set the
> default qos
> > > > > > > > > > > > on a port to linux-noop
> > > > > > > > > > > >
> > > > > > > > > > > >
> https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L106-L125
> > > > > > > > > > > >
> > > > > > > > > > > > the backports are propsoed upstream
> > > > > > > > > > > >
> https://review.opendev.org/q/Id9ef7074634a0f23d67a4401fa8fca363b51bb43
> > > > > > > > > > > > and we have backported this downstream to adress
> that performance
> > > > > > > > > > > > regression.
> > > > > > > > > > > > the upstram backport is semi stalled just ebcasue we
> wanted to
> > > > > > > > > > > > disucss if we shoudl make ti opt in
> > > > > > > > > > > > by default upstream while backporting but it might
> be helpful for
> > > > > > > > > > > > you if this is related to yoru current
> > > > > > > > > > > > issues.
> > > > > > > > > > > >
> > > > > > > > > > > > 40-55 kpps is kind of low for kernel ovs but if you
> have a low
> > > > > > > > > > > > clockrate cpu, hybrid_plug + incorrect qos
> > > > > > > > > > > > then i could see you hitting such a bottelneck.
> > > > > > > > > > > >
> > > > > > > > > > > > one workaround by the way without the os-vif
> workaround
> > > > > > > > > > > > backported is to set
> > > > > > > > > > > > /proc/sys/net/core/default_qdisc to not apply any
> qos or a low
> > > > > > > > > > > > overhead qos type
> > > > > > > > > > > > i.e. sudo sysctl -w net.core.default_qdisc=pfifo_fast
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > that may or may not help but i would ensure that
> your are not
> > > > > > > > > > > > usign somting like fqdel or cake
> > > > > > > > > > > > for net.core.default_qdisc and if you are try
> changing it to
> > > > > > > > > > > > pfifo_fast and see if that helps.
> > > > > > > > > > > >
> > > > > > > > > > > > there isnet much you can do about the cpu clock rate
> but ^ is
> > > > > > > > > > > > somethign you can try for free
> > > > > > > > > > > > note it wont actully take effect on an exsitng vm if
> you jsut
> > > > > > > > > > > > change the default but you can use
> > > > > > > > > > > > tc to also chagne the qdisk for testing. hard
> rebooting the vm
> > > > > > > > > > > > shoudl also make the default take effect.
> > > > > > > > > > > >
> > > > > > > > > > > > the only other advice i can give assuming kernel ovs
> is the only
> > > > > > > > > > > > option you have is
> > > > > > > > > > > >
> > > > > > > > > > > > to look at
> > > > > > > > > > > >
> > > > > > > > > > > >
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.rx_queue_size
> > > > > > > > > > > >
> > > > > > > > > > > >
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.tx_queue_size
> > > > > > > > > > > > and
> > > > > > > > > > > >
> > > > > > > > > > > >
> https://docs.openstack.org/nova/latest/configuration/extra-specs.html#hw:vif_multiqueue_enabled
> > > > > > > > > > > >
> > > > > > > > > > > > if the bottelneck is actully in qemu or the guest
> kernel rather
> > > > > > > > > > > > then ovs adjusting the rx/tx queue size and
> > > > > > > > > > > > using multi queue can help. it will have no effect
> if ovs is the
> > > > > > > > > > > > bottel neck.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > I have set this option to 1024, and enable multiqueue
> as well. But
> > > > > > > > > > > it did not help.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Sep 6, 2023 at 9:21?AM Ha Noi <
> hanoi952022 at gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Satish,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Actually, our customer get this issue when the
> tx/rx above
> > > > > > > > > > > > only 40k pps.
> > > > > > > > > > > > > > So what is the threshold of this throughput for
> OvS?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks and regards
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, 6 Sep 2023 at 20:19 Satish Patel <
> > > > > > > > > > > > satish.txt at gmail.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This is normal because OVS or LinuxBridge wire
> up VMs using
> > > > > > > > > > > > TAP interface
> > > > > > > > > > > > > > > which runs on kernel space and that drives
> higher interrupt
> > > > > > > > > > > > and that makes
> > > > > > > > > > > > > > > the kernel so busy working on handling
> packets. Standard
> > > > > > > > > > > > OVS/LinuxBridge
> > > > > > > > > > > > > > > are not meant for higher PPS.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you want to handle higher PPS then look for
> DPDK or
> > > > > > > > > > > > SRIOV deployment.
> > > > > > > > > > > > > > > ( We are running everything in SRIOV because
> of high PPS
> > > > > > > > > > > > requirement)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Sep 5, 2023 at 11:11?AM Ha Noi <
> > > > > > > > > > > > hanoi952022 at gmail.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi everyone,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm using Openstack Train and Openvswitch
> for ML2 driver
> > > > > > > > > > > > and GRE for
> > > > > > > > > > > > > > > > tunnel type. I tested our network
> performance between two
> > > > > > > > > > > > VMs and suffer
> > > > > > > > > > > > > > > > packet loss as below.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > VM1: IP: 10.20.1.206
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > VM2: IP: 10.20.1.154 <https://10.20.1.154/24
> >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > VM3: IP: 10.20.1.72
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Using iperf3 to testing performance between
> VM1 and VM2.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Run iperf3 client and server on both VMs.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On VM2: iperf3 -t 10000 -b 130M -l 442 -P 6
> -u -c
> > > > > > > > > > > > 10.20.1.206
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On VM1: iperf3 -t 10000 -b 130M -l 442 -P 6
> -u -c
> > > > > > > > > > > > 10.20.1.154
> > > > > > > > > > > > > > > > <https://10.20.1.154/24>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Using VM3 ping into VM1, then the packet is
> lost and the
> > > > > > > > > > > > latency is
> > > > > > > > > > > > > > > > quite high.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > ping -i 0.1 10.20.1.206
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > PING 10.20.1.206 (10.20.1.206) 56(84) bytes
> of data.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=1
> ttl=64 time=7.70 ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=2
> ttl=64 time=6.90 ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=3
> ttl=64 time=7.71 ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=4
> ttl=64 time=7.98 ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=6
> ttl=64 time=8.58 ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=7
> ttl=64 time=8.34 ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=8
> ttl=64 time=8.09 ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=10
> ttl=64 time=4.57
> > > > > > > > > > > > ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=11
> ttl=64 time=8.74
> > > > > > > > > > > > ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=12
> ttl=64 time=9.37
> > > > > > > > > > > > ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=14
> ttl=64 time=9.59
> > > > > > > > > > > > ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=15
> ttl=64 time=7.97
> > > > > > > > > > > > ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=16
> ttl=64 time=8.72
> > > > > > > > > > > > ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 64 bytes from 10.20.1.206: icmp_seq=17
> ttl=64 time=9.23
> > > > > > > > > > > > ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > ^C
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --- 10.20.1.206 ping statistics ---
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 34 packets transmitted, 28 received,
> 17.6471% packet
> > > > > > > > > > > > loss, time 3328ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > rtt min/avg/max/mdev =
> 1.396/6.266/9.590/2.805 ms
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Does any one get this issue ?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Please help me. Thanks
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230910/9933c719/attachment-0001.htm>

From gmann at ghanshyammann.com  Mon Sep 11 03:03:23 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Sun, 10 Sep 2023 20:03:23 -0700
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and
 maintainers
In-Reply-To: <CAL_crJTTn2=y5_6rg2ODPWb3Rvc=BvOt=MeQ2F7FosL9YfdWWg@mail.gmail.com>
References: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
 <188ea6f2a53.ee65931886747.6600003948918544663@ghanshyammann.com>
 <CAL_crJTTn2=y5_6rg2ODPWb3Rvc=BvOt=MeQ2F7FosL9YfdWWg@mail.gmail.com>
Message-ID: <18a8231992c.b2b8601b117458.1449700563057999548@ghanshyammann.com>

 ---- On Fri, 08 Sep 2023 05:19:13 -0700  Takashi Kajinami  wrote --- 
 > Let me bump this old thread because we still need some follow-up about the retirement of os-win.
 > I noticed that some projects have not yet deprecated the implementations dependent on os-win.I submitted a few patches to make these implementations deprecated so that we can smoothly remove thesein the future.?https://review.opendev.org/c/openstack/cinder/+/894237?https://review.opendev.org/c/openstack/glance/+/894236?https://review.opendev.org/c/openstack/ceilometer/+/894296It'd be nice if the relevant teams can review these.
 > 
 > My remaining question is whether we should mark all implementations for Windows support, which are not directlydependent on os-win[1]. Technically we can go through individual projects and add warning logs and release notesabout the deprecation. However I'm not too sure if that's worth the effort. If we can agree that we remove supportfor running OpenStack on Windows Operating System at a specific release, then I tend to leave the ones independentfrom os-win, unless it has any impact on user-facing items like config options[1].
 > I'd like to hear any thoughts about this plan, as well as any target release to remove Windows "host" support globallyfrom OpenStack (maybe after 2024.1 release ?).

Thanks for marking a few of the Windows support things as deprecated. This is the right direction for at least where it
depends on os-win. I have started completing the os-win retirement and deps[1]. But we need to add a deprecation
warning in one cycle and then remove it in a later one (like you are doing in the mentioned changes). We did the
same in the Nova Hyper-V driver, which was marked deprecated in the 2023.1 cycles, and I am proposing it to be
removed in the next cycle, 2024.1[2].

For the Windows feature other than os-win dependencies, it is up to the projects, and if they can still
support and test those without 3rd party CI, then it is okay to keep it. This applies to any other distro-specific
features also where they might be supported by a few projects but not all. But they should go through the
deprecation phase warning even they are not tested so that users get the notification. 

[1] https://review.opendev.org/q/+topic:retire-winstackers
[2] https://review.opendev.org/c/openstack/nova/+/894466

-gmann

 > 
 > [1] Some examples?https://github.com/openstack/ceilometer/blob/d31d4ed3574a5d19fe4b09ab2c227dba64da170a/ceilometer/cmd/polling.py#L95-L96?https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py#L624-L625
 > [2] event_log option in oslo.log is one good example https://review.opendev.org/c/openstack/oslo.log/+/894235
 > On Sat, Jun 24, 2023 at 7:50?AM Ghanshyam Mann gmann at ghanshyammann.com> wrote:
 > As there is no volunteer to maintain this project, I have proposed the retirement
 > 
 > - https://review.opendev.org/c/openstack/governance/+/886880
 > 
 > -gmann
 > 
 > ?---- On Thu, 13 Apr 2023 07:54:12 -0700? James Page? wrote --- 
 > ?> Hi All
 > ?> 
 > ?> As announced by Lucian last November (see [0]) Cloudbase Solutions are no longer in a position to maintain support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support across a number of OpenStack projects.
 > ?> This situation has resulted in the Winstackers project becoming PTL-less for the 2023.2 cycle with no volunteers responding to the TC's call to fill this role and take this feature in OpenStack forward (see [1]).
 > ?> This is the final call for any maintainers to step forward if this feature is important to them in OpenStack.
 > ?> The last user survey in 2022 indicated that 2% of respondents were running on Hyper-V so this might be important enough to warrant a commitment from someone operating OpenStack on Windows to maintain these features going forward.
 > ?> Here is a reminder from Lucian's original email on the full list of projects which are impacted in some way:?* nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver* os-win - common Windows library for Openstack* neutron hyperv ml2 plugin and agent* ovs on Windows and neutron ovs agent support* cinder drivers - SMB and Windows iSCSI* os-brick Windows connectors - iSCSI, FC, SMB, RBD* ceilometer Windows poller* manila Windows driver* glance Windows support* freerdp gateway
 > ?> The lack of 3rd party CI for testing all of this really needs to be addressed as well.
 > ?> If no maintainers are forthcoming between now and the next PTG in June the TC will need to officially retire the project and start the process of removing support for Windows across the various projects that support this operating system in some way - either directly or through the use of os-win.
 > ?> For clarity this call refers to the use of the Hyper-V virtualisation driver and associated Windows server components to provide WIndows based OpenStack Hypervisors and does not relate to the ability to run Windows images as guests on OpenStack.
 > ?> Regards
 > ?> James
 > ?> [0]?https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html[1]?https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032888.html
 > 
 > 


From nguyenhuukhoinw at gmail.com  Mon Sep 11 03:33:45 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Mon, 11 Sep 2023 10:33:45 +0700
Subject: [Skyline] error username or password incorrect
In-Reply-To: <CAPgF-fowoLU-p5wSYQvrd=Nbm-tzcMmgxFCJLUW9fKkUaJ-JVQ@mail.gmail.com>
References: <CAPgF-fqgk=zFdetgrT+kr1tiQevNxwHVT8tgyQ+88w4wR0qU9g@mail.gmail.com>
 <CAPgF-fqo4Tev15oeObkJBq-f-h3M4VKy1JsZY7ZHXfFHpDpcVg@mail.gmail.com>
 <CAPgF-fo8wX-2go2wKQ6n1ZL_MLYXhR7K61Z7LsQmnRjb0dvcVA@mail.gmail.com>
 <CABAODRcbmAZ7m+A=ye2MsKaCUhZTWzksPcYfMDB36xDWagQBWg@mail.gmail.com>
 <CAPgF-fpGXDMD9+1vFJKSQFSRb3xskhBvsUpLPX1N0fRQYLz8NQ@mail.gmail.com>
 <CABAODReHKzqNeLN+JY_WPwtHkebS1E5QhwUEdE2aUtbGt_DEUQ@mail.gmail.com>
 <CAPgF-foxeMDoRBdD1oi7d2tynVi3cNO7SJu-p-yyC7tAH9u+qw@mail.gmail.com>
 <CABAODRfJb1eaQ=7WDaKQs34dj6jrtU7tD=DvYADUOX5rOU5eBQ@mail.gmail.com>
 <CAPgF-frY==mp=81YV_LtjmMvaqmCVkz+JmfGJLwOq5iGx+vr5A@mail.gmail.com>
 <CABAODRdOogiHNo2xZ7QiYRQeWR2aPHP7zas=7WrWHG6jHWWaMA@mail.gmail.com>
 <CAPgF-fqMPDB3KMQLvJQ1y6rtXuQtmEVBaa7mnE0T3f3Q9EKBRw@mail.gmail.com>
 <CABAODRfq-jFRJzaNbypy3rT_vhUV6DQFVpmjL-hAsLRj=RPTgA@mail.gmail.com>
 <CAPgF-fp2Wh=vye3wMRdJj2pvWY4TkmBMw3iGFO034rKi=4C+qQ@mail.gmail.com>
 <CAPgF-fpRNV-5Y65syrRNJ1VT0yg3XP_1oNo6nuUp3w1pxuH5Og@mail.gmail.com>
 <CAPgF-fpfYqH5dqfyU=C0y_7dfbHsv7KKSbe0FNdmipRgZOV96g@mail.gmail.com>
 <CAPgF-fowoLU-p5wSYQvrd=Nbm-tzcMmgxFCJLUW9fKkUaJ-JVQ@mail.gmail.com>
Message-ID: <CABAODRfW1azgnadLvWdRP1YVNc3LM5oE4Vqbg3W7hU3JOBcX6g@mail.gmail.com>

Hello.
I met the same problem with docker, I related to default project.
Nguyen Huu Khoi


On Sat, Sep 9, 2023 at 4:33?AM Satish Patel <satish.txt at gmail.com> wrote:

> I found my issue and reported here
>
> https://bugs.launchpad.net/skyline-apiserver/+bug/2034976
>
> On Fri, Sep 8, 2023 at 5:17?PM Satish Patel <satish.txt at gmail.com> wrote:
>
>> I found similar bug here
>> https://bugs.launchpad.net/skyline-apiserver/+bug/1942284
>>
>> On Fri, Sep 8, 2023 at 5:11?PM Satish Patel <satish.txt at gmail.com> wrote:
>>
>>> This is my fill configuration of skyline.yaml, my problem is I can get
>>> into the interface with the admin account and everything works. But when I
>>> login as normal user account and try to do anything it throwing error
>>>
>>> {
>>>   "message": "You don't have access to get instances.",
>>>   "status": 401
>>> }
>>>
>>> Find attached screenshot.
>>>
>>>
>>> # cat /etc/skyline/skyline.yaml
>>> default:
>>>   access_token_expire: 3600
>>>   access_token_renew: 1800
>>>   cors_allow_origins: []
>>>   #database_url: sqlite:////tmp/skyline.db
>>>   database_url: mysql://skyline:myskylinedb123 at localhost:3306/skyline
>>>   debug: true
>>>   log_dir: /var/log
>>>   log_file: skyline.log
>>>   prometheus_basic_auth_password: ''
>>>   prometheus_basic_auth_user: ''
>>>   prometheus_enable_basic_auth: false
>>>   prometheus_endpoint: http://localhost:9091
>>>   secret_key: aCtmgbcUqYUy_HNVg5BDXCaeJgJQzHJXwqbXr0Nmb2o
>>>   session_name: session
>>>   ssl_enabled: true
>>> openstack:
>>>   base_domains:
>>>   - heat_user_domain
>>>   default_region: RegionOne
>>>   enforce_new_defaults: true
>>>   extension_mapping:
>>>     floating-ip-port-forwarding: neutron_port_forwarding
>>>     fwaas_v2: neutron_firewall
>>>     qos: neutron_qos
>>>     vpnaas: neutron_vpn
>>>   interface_type: public
>>>   keystone_url: http://10.30.50.10:5000/v3/
>>>   nginx_prefix: /api/openstack
>>>   reclaim_instance_interval: 604800
>>>   service_mapping:
>>>     baremetal: ironic
>>>     compute: nova
>>>     container: zun
>>>     container-infra: magnum
>>>     database: trove
>>>     identity: keystone
>>>     image: glance
>>>     key-manager: barbican
>>>     load-balancer: octavia
>>>     network: neutron
>>>     object-store: swift
>>>     orchestration: heat
>>>     placement: placement
>>>     sharev2: manilav2
>>>     volumev3: cinder
>>>   sso_enabled: false
>>>   sso_protocols:
>>>   - openid
>>>   sso_region: RegionOne
>>>   system_admin_roles:
>>>   - admin
>>>   - system_admin
>>>   system_project: service
>>>   system_project_domain: Default
>>>   system_reader_roles:
>>>   - system_reader
>>>   system_user_domain: Default
>>>   system_user_name: skyline
>>>   system_user_password: 'skyline123'
>>> setting:
>>>   base_settings:
>>>   - flavor_families
>>>   - gpu_models
>>>   - usb_models
>>>   flavor_families:
>>>   - architecture: x86_architecture
>>>     categories:
>>>     - name: general_purpose
>>>       properties: []
>>>     - name: compute_optimized
>>>       properties: []
>>>     - name: memory_optimized
>>>       properties: []
>>>     - name: high_clock_speed
>>>       properties: []
>>>   - architecture: heterogeneous_computing
>>>     categories:
>>>     - name: compute_optimized_type_with_gpu
>>>       properties: []
>>>     - name: visualization_compute_optimized_type_with_gpu
>>>       properties: []
>>>   gpu_models:
>>>   - nvidia_t4
>>>   usb_models:
>>>   - usb_c
>>>
>>> On Fri, Sep 8, 2023 at 4:44?PM Satish Patel <satish.txt at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have shared all the information in this bug report
>>>> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>>>>
>>>> On Tue, Aug 29, 2023 at 5:09?AM Nguy?n H?u Kh?i <
>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Can u share me OS and your file configure?
>>>>>
>>>>>
>>>>> Nguyen Huu Khoi
>>>>>
>>>>>
>>>>> On Mon, Aug 28, 2023 at 9:37?PM Satish Patel <satish.txt at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Zed stable.
>>>>>>
>>>>>> On Mon, Aug 28, 2023 at 10:26?AM Nguy?n H?u Kh?i <
>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>
>>>>>>> Which kolla version you deployed.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 28, 2023, 9:22 PM Satish Patel <satish.txt at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> No kidding, that is the doc I am following line by line and no
>>>>>>>> error at all during installation. Problems start when you try to get into
>>>>>>>> the UI interface and it throws username/password errors. Could you please
>>>>>>>> share your skyline.yml config file (ofc hide your password :) )
>>>>>>>>
>>>>>>>> ~S
>>>>>>>>
>>>>>>>> On Mon, Aug 28, 2023 at 9:47?AM Nguy?n H?u Kh?i <
>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> No.
>>>>>>>>> I set it seperately.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://docs.openstack.org/skyline-console/latest/install/docker-install-ubuntu.html
>>>>>>>>>
>>>>>>>>> On Mon, Aug 28, 2023, 8:41 PM Satish Patel <satish.txt at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Can you tell me how you set it with kolla-ansible?
>>>>>>>>>>
>>>>>>>>>> Did you set this in globals.yml and just playbook? Trying to
>>>>>>>>>> understand what are the differences between my method and yours :)
>>>>>>>>>> enable_skyline: yes
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 28, 2023 at 9:15?AM Nguy?n H?u Kh?i <
>>>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> It is ok with docker. I use it with my exist cloud by kolla
>>>>>>>>>>> ansible.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 28, 2023, 8:09 PM Satish Patel <satish.txt at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> This is very odd, I am following line to line doc from skyline
>>>>>>>>>>>> official page and its docker container but still getting the same error on
>>>>>>>>>>>> multiple machines. Same time the developer says it's working for them. How
>>>>>>>>>>>> to get help and move forward from here?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Aug 25, 2023 at 12:53?AM Nguy?n H?u Kh?i <
>>>>>>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> I got same problem but with mariadb.
>>>>>>>>>>>>> Nguyen Huu Khoi
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Aug 8, 2023 at 12:17?PM Satish Patel <
>>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Update:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After switching DB from sqlite to mysql DB it works. Now
>>>>>>>>>>>>>> admin account works but when I login with _member_ users or normal account
>>>>>>>>>>>>>> and trying to create instance then pop up windows throwing error:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>   "message": "You don't have access to get instances.",
>>>>>>>>>>>>>>   "status": 401
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Aug 7, 2023 at 11:51?PM Satish Patel <
>>>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Skyline Team,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I found similar issue in BUG Report but no solution yet
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://bugs.launchpad.net/skyline-apiserver/+bug/2025755
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Aug 7, 2023 at 7:25?PM Satish Patel <
>>>>>>>>>>>>>>> satish.txt at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Try to install skyline UI to replace horizon using doc:
>>>>>>>>>>>>>>>> https://docs.openstack.org/skyline-apiserver/latest/install/docker-install-ubuntu.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Everything went well and I got a login page on
>>>>>>>>>>>>>>>> http://x.x.x.x:9999 also it pulled Region/Domains. When I
>>>>>>>>>>>>>>>> am trying to login with my account, I get an error: Username or Password is
>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am using sqlite DB for skyline as per documents.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No errors in logs command
>>>>>>>>>>>>>>>> $ docker logs skyline
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When I use Chrome Developer Tools then it was indicating an
>>>>>>>>>>>>>>>> error in these URLs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/profile
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://openstack.example.com:9999/api/openstack/skyline/api/v1/policies
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 401 Unauthorized ( {"detail":"no such table:
>>>>>>>>>>>>>>>> revoked_token"} )
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230911/3788fa4c/attachment-0001.htm>

From ykarel at redhat.com  Mon Sep 11 07:19:46 2023
From: ykarel at redhat.com (Yatin Karel)
Date: Mon, 11 Sep 2023 12:49:46 +0530
Subject: [neutron] Bug Deputy Report September 4 - September 10
Message-ID: <CAPU8nTEBfFM9xvYJyne1mX-Bcocpfb4mkVf8Dgs7G7Uj23xWXA@mail.gmail.com>

Hi Team,

Below is the bug deputy report for last week:-

High
------
- https://bugs.launchpad.net/neutron/+bug/2033887 [OVN][Trunk] The cold
migration process is broken since patch 882581
Fix Proposed: https://review.opendev.org/q/topic:bug%252F2018289
Assigned to Rodolfo

- https://bugs.launchpad.net/neutron/+bug/2033932 Add support for OVN
MAC_Binding aging
  Fix Proposed: https://review.opendev.org/c/openstack/neutron/+/893575
  Assigned to Terry

- https://bugs.launchpad.net/neutron/+bug/2034522 Fake members
operating_status ONLINE
  Fix Proposed:
https://review.opendev.org/c/openstack/ovn-octavia-provider/+/893839
  Assigned to Fernando


Medium
----------
- https://bugs.launchpad.net/neutron/+bug/2034589 [FT][OVN]
"ovsdb_connection.stop()" failing during the test cleanup process
 Unassigned


Undecided
--------------
- https://bugs.launchpad.net/neutron/+bug/2034761 test discovery fail with
latest neutron-lib
  Marked as Invalid as it was due to version mismatch of neutron-lib and
neutron
- https://bugs.launchpad.net/neutron/+bug/2034684 UEFI (edk2/ovmf) network
boot with OVN fail because no DHCP release reply
   Looks like issue only against Core OVN, asked reporter for it


Thanks and Regards
Yatin Karel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230911/94b8c056/attachment.htm>

From smooney at redhat.com  Mon Sep 11 08:53:33 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Mon, 11 Sep 2023 09:53:33 +0100
Subject: [kolla-ansible][ovn] availability zone for OVN
In-Reply-To: <CAB1EZBoyLi5Z7d+QP6srr0HcTeOp6z_xHnv_MODq5x-CHhB8Vw@mail.gmail.com>
References: <CAPgF-fomCgpUMbJpfx9DyoPiHoW=yYOygk-SptCrx1KxHabR3Q@mail.gmail.com>
 <CAB1EZBoyLi5Z7d+QP6srr0HcTeOp6z_xHnv_MODq5x-CHhB8Vw@mail.gmail.com>
Message-ID: <fc9e69232bd5516b41a083bc3829ba001efefc28.camel@redhat.com>

On Sun, 2023-09-10 at 14:51 +0100, Lucas Alvares Gomes wrote:
> On Sun, Sep 10, 2023 at 4:13?AM Satish Patel <satish.txt at gmail.com> wrote:
> > 
> > Folks,
> > 
> > I am trying to set an availability zone for OVN because skyline UI has a mandatory requirement to have an
> > availability zone otherwise you are not allowed to create a network from skyline GUI.
one thing that skiline and admin s to a lesser degree need to be aware of is that nova AZ, Neutron AZ and cinder AZ
are generally not related to each other. you as an admin can align them but a enduser should not assume that
when creating a vm with a netwok and a voluem that the name of the AZ for all 3 should be the same.
AZs are also optional in all 3 servics that support them. nova invents a fake AZ called "nova" and puts all host
that dont otherwise have an az in it but its considerd a bug to explictly request the nova az.
we have debated makeing that a hard error in future api version although currently we do know that some people do
reueqst the defautl nova az even though we document that you should not.
https://docs.openstack.org/nova/latest/admin/availability-zones.html
"""
The use of the default availability zone name in requests can be very error-prone. Since the user can see the list of
availability zones, they have no way to know whether the default availability zone name (currently nova) is provided
because a host belongs to an aggregate whose AZ metadata key is set to nova, or because there is at least one host not
belonging to any aggregate. Consequently, it is highly recommended for users to never ever ask for booting an instance
by specifying an explicit AZ named nova and for operators to never set the AZ metadata for an aggregate to nova. This
can result is some problems due to the fact that the instance AZ information is explicitly attached to nova which could
break further move operations when either the host is moved to another aggregate or when the user would like to migrate
the instance.
"""

i raise this because i would consider it a bug form a nova point of view if skyline forced you to specyify
an az when booting a vm. i would also consider it a bug in skyline if it forced the same on neutron or cinder
since they are an optional feature. even if its common to configure them the skyline ui should not force you to select
one.


> > 
> > for OVN based deployment only option to set AZ is in ovn-cms-options
> > 
> > # ovs-vsctl set open_vswitch . external_ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0"
> > 
> > Question:
> > 
> > 1. How do I configure in kolla-ansible to override or set ovn-cms-options on only gateway chassis?
> > 2. How does AZ work in OVN because OVN is anyway distributed as per documents, What if I just give foobar AZ name to
> > meet Skyline requirement? Is it going to break anything?
> 
> Answering 2.
> 
> There are two types of availability zones in Neutron: Routers and Networks.
> 
> For Routers, ML2/OVN will schedule the gateway router ports onto the
> nodes belonging to the availability zones provided by the
> --availability-zone-hint parameter, for example:
> 
> $ openstack router create --availability-zone-hint az-0
> --availability-zone-hint az-1 router-0
> 
> For Networks. Since DHCP is distributed in ML2/OVN as you pointed out
> we do not care about scheduling DHCP agents (like ML2/OVS). But there
> are few cases for Network AZ in ML2/OVN that are related to external
> ports [0], these are ports that live on a different host than the
> instance to address use cases such as SR-IOV and Baremetal with
> ML2/OVN.
> 
> You can read more ML2/OVN AZs here:
> https://docs.openstack.org/neutron/latest/admin/ovn/availability_zones.html
> 
> [0] https://docs.openstack.org/neutron/latest/admin/ovn/external_ports.html
> 
> Cheers,
> Lucas
> 



From smooney at redhat.com  Mon Sep 11 08:59:27 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Mon, 11 Sep 2023 09:59:27 +0100
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and
 maintainers
In-Reply-To: <18a8231992c.b2b8601b117458.1449700563057999548@ghanshyammann.com>
References: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
 <188ea6f2a53.ee65931886747.6600003948918544663@ghanshyammann.com>
 <CAL_crJTTn2=y5_6rg2ODPWb3Rvc=BvOt=MeQ2F7FosL9YfdWWg@mail.gmail.com>
 <18a8231992c.b2b8601b117458.1449700563057999548@ghanshyammann.com>
Message-ID: <582161586dfebca1b43576a837244a1f0846e0b7.camel@redhat.com>

On Sun, 2023-09-10 at 20:03 -0700, Ghanshyam Mann wrote:
> ?---- On Fri, 08 Sep 2023 05:19:13 -0700? Takashi Kajinami? wrote --- 
> ?> Let me bump this old thread because we still need some follow-up about the retirement of os-win.
> ?> I noticed that some projects have not yet deprecated the implementations dependent on os-win.I submitted a few
> patches to make these implementations deprecated so that we can smoothly remove thesein the
> future.?https://review.opendev.org/c/openstack/cinder/+/894237?
> https://review.opendev.org/c/openstack/glance/+/894236?https://review.opendev.org/c/openstack/ceilometer/+/894296It'd?
> be nice if the relevant teams can review these.
> ?> 
> ?> My remaining question is whether we should mark all implementations for Windows support, which are not
> directlydependent on os-win[1]. Technically we can go through individual projects and add warning logs and release
> notesabout the deprecation. However I'm not too sure if that's worth the effort. If we can agree that we remove
> supportfor running OpenStack on Windows Operating System at a specific release, then I tend to leave the ones
> independentfrom os-win, unless it has any impact on user-facing items like config options[1].
> ?> I'd like to hear any thoughts about this plan, as well as any target release to remove Windows "host" support
> globallyfrom OpenStack (maybe after 2024.1 release ?).
> 
> Thanks for marking a few of the Windows support things as deprecated. This is the right direction for at least where
> it
> depends on os-win. I have started completing the os-win retirement and deps[1]. But we need to add a deprecation
> warning in one cycle and then remove it in a later one (like you are doing in the mentioned changes). We did the
> same in the Nova Hyper-V driver, which was marked deprecated in the 2023.1 cycles, and I am proposing it to be
> removed in the next cycle, 2024.1[2].
you bet me too it
there are already two other nova cores (myself and one other) that also planned to do this after confirming with the
wider team at the next ptg so this is highly likely to proceed early in the 2024.1 cycle.
my goal in this regard would be to land the removal of both the hyperv and vmware driver before milestone one
and perhaps even before the ptg if there is no object to it in our irc team meeting.

i was waiting for RC-1 to be cut and the dust to settle before brign this up to discuss but it seams at least 3 fo the
nova core team feel this is thr correct direction to take now.
> 
> For the Windows feature other than os-win dependencies, it is up to the projects, and if they can still
> support and test those without 3rd party CI, then it is okay to keep it. This applies to any other distro-specific
> features also where they might be supported by a few projects but not all. But they should go through the
> deprecation phase warning even they are not tested so that users get the notification. 
> 
> [1] https://review.opendev.org/q/+topic:retire-winstackers
> [2] https://review.opendev.org/c/openstack/nova/+/894466
> 
> -gmann
> 
> ?> 
> ?> [1] Some
> examples?https://github.com/openstack/ceilometer/blob/d31d4ed3574a5d19fe4b09ab2c227dba64da170a/ceilometer/cmd/polling.
> py#L95-L96?https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py#L624-L625
> ?> [2] event_log option in oslo.log is one good example https://review.opendev.org/c/openstack/oslo.log/+/894235
> ?> On Sat, Jun 24, 2023 at 7:50?AM Ghanshyam Mann gmann at ghanshyammann.com> wrote:
> ?> As there is no volunteer to maintain this project, I have proposed the retirement
> ?> 
> ?> - https://review.opendev.org/c/openstack/governance/+/886880
> ?> 
> ?> -gmann
> ?> 
> ?> ?---- On Thu, 13 Apr 2023 07:54:12 -0700? James Page? wrote --- 
> ?> ?> Hi All
> ?> ?> 
> ?> ?> As announced by Lucian last November (see [0]) Cloudbase Solutions are no longer in a position to maintain
> support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support
> across a number of OpenStack projects.
> ?> ?> This situation has resulted in the Winstackers project becoming PTL-less for the 2023.2 cycle with no volunteers
> responding to the TC's call to fill this role and take this feature in OpenStack forward (see [1]).
> ?> ?> This is the final call for any maintainers to step forward if this feature is important to them in OpenStack.
> ?> ?> The last user survey in 2022 indicated that 2% of respondents were running on Hyper-V so this might be important
> enough to warrant a commitment from someone operating OpenStack on Windows to maintain these features going forward.
> ?> ?> Here is a reminder from Lucian's original email on the full list of projects which are impacted in some way:?*
> nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver* os-win - common Windows library for Openstack*
> neutron hyperv ml2 plugin and agent* ovs on Windows and neutron ovs agent support* cinder drivers - SMB and Windows
> iSCSI* os-brick Windows connectors - iSCSI, FC, SMB, RBD* ceilometer Windows poller* manila Windows driver* glance
> Windows support* freerdp gateway
> ?> ?> The lack of 3rd party CI for testing all of this really needs to be addressed as well.
> ?> ?> If no maintainers are forthcoming between now and the next PTG in June the TC will need to officially retire the
> project and start the process of removing support for Windows across the various projects that support this operating
> system in some way - either directly or through the use of os-win.
> ?> ?> For clarity this call refers to the use of the Hyper-V virtualisation driver and associated Windows server
> components to provide WIndows based OpenStack Hypervisors and does not relate to the ability to run Windows images as
> guests on OpenStack.
> ?> ?> Regards
> ?> ?> James
> ?> ?>
> [0]?https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html[1]?https://lists.openstack.org/p
> ipermail/openstack-discuss/2023-March/032888.html
> ?> 
> ?> 
> 



From sylvain.bauza at gmail.com  Mon Sep 11 09:35:03 2023
From: sylvain.bauza at gmail.com (Sylvain Bauza)
Date: Mon, 11 Sep 2023 11:35:03 +0200
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and
 maintainers
In-Reply-To: <582161586dfebca1b43576a837244a1f0846e0b7.camel@redhat.com>
References: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
 <188ea6f2a53.ee65931886747.6600003948918544663@ghanshyammann.com>
 <CAL_crJTTn2=y5_6rg2ODPWb3Rvc=BvOt=MeQ2F7FosL9YfdWWg@mail.gmail.com>
 <18a8231992c.b2b8601b117458.1449700563057999548@ghanshyammann.com>
 <582161586dfebca1b43576a837244a1f0846e0b7.camel@redhat.com>
Message-ID: <CANWE-Ck6K-HeXQSNubjQYH5yDubqdqCy_TaVMUi_K=ur6eAPiw@mail.gmail.com>

Le lun. 11 sept. 2023 ? 11:03, <smooney at redhat.com> a ?crit :

> On Sun, 2023-09-10 at 20:03 -0700, Ghanshyam Mann wrote:
> >  ---- On Fri, 08 Sep 2023 05:19:13 -0700  Takashi Kajinami  wrote ---
> >  > Let me bump this old thread because we still need some follow-up
> about the retirement of os-win.
> >  > I noticed that some projects have not yet deprecated the
> implementations dependent on os-win.I submitted a few
> > patches to make these implementations deprecated so that we can smoothly
> remove thesein the
> > future. https://review.opendev.org/c/openstack/cinder/+/894237
> > https://review.opendev.org/c/openstack/glance/+/894236
> https://review.opendev.org/c/openstack/ceilometer/+/894296It'd
> > be nice if the relevant teams can review these.
> >  >
> >  > My remaining question is whether we should mark all implementations
> for Windows support, which are not
> > directlydependent on os-win[1]. Technically we can go through individual
> projects and add warning logs and release
> > notesabout the deprecation. However I'm not too sure if that's worth the
> effort. If we can agree that we remove
> > supportfor running OpenStack on Windows Operating System at a specific
> release, then I tend to leave the ones
> > independentfrom os-win, unless it has any impact on user-facing items
> like config options[1].
> >  > I'd like to hear any thoughts about this plan, as well as any target
> release to remove Windows "host" support
> > globallyfrom OpenStack (maybe after 2024.1 release ?).
> >
> > Thanks for marking a few of the Windows support things as deprecated.
> This is the right direction for at least where
> > it
> > depends on os-win. I have started completing the os-win retirement and
> deps[1]. But we need to add a deprecation
> > warning in one cycle and then remove it in a later one (like you are
> doing in the mentioned changes). We did the
> > same in the Nova Hyper-V driver, which was marked deprecated in the
> 2023.1 cycles, and I am proposing it to be
> > removed in the next cycle, 2024.1[2].
> you bet me too it
> there are already two other nova cores (myself and one other) that also
> planned to do this after confirming with the
> wider team at the next ptg so this is highly likely to proceed early in
> the 2024.1 cycle.
> my goal in this regard would be to land the removal of both the hyperv and
> vmware driver before milestone one
> and perhaps even before the ptg if there is no object to it in our irc
> team meeting.
>
> i was waiting for RC-1 to be cut and the dust to settle before brign this
> up to discuss but it seams at least 3 fo the
> nova core team feel this is thr correct direction to take now.
>


What you just said. IIRC, we kinda agreed on the PTG to try to avoid as
much as possible any deprecations during the 2023.2 Bobcat release, which
is a non-SLURP release, as it would be skipped by operators fast-jumping to
2024.1, unless someone would forward-port the deprecation note to Caracal,
hence putting the burden on someone's shoulder.

Reinstanting my personal take then, which is, as a Nova PTL, I'm not 100%
happy with taking my burden.
Please, please, let's wait for 4 days and nothing or nooone will then get
hurt :-)

>
> > For the Windows feature other than os-win dependencies, it is up to the
> projects, and if they can still
> > support and test those without 3rd party CI, then it is okay to keep it.
> This applies to any other distro-specific
> > features also where they might be supported by a few projects but not
> all. But they should go through the
> > deprecation phase warning even they are not tested so that users get the
> notification.
> >
> > [1] https://review.opendev.org/q/+topic:retire-winstackers
> > [2] https://review.opendev.org/c/openstack/nova/+/894466
> >
> > -gmann
> >
> >  >
> >  > [1] Some
> > examples
> https://github.com/openstack/ceilometer/blob/d31d4ed3574a5d19fe4b09ab2c227dba64da170a/ceilometer/cmd/polling
> .
> > py#L95-L96
> https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py#L624-L625
> >  > [2] event_log option in oslo.log is one good example
> https://review.opendev.org/c/openstack/oslo.log/+/894235
> >  > On Sat, Jun 24, 2023 at 7:50?AM Ghanshyam Mann
> gmann at ghanshyammann.com> wrote:
> >  > As there is no volunteer to maintain this project, I have proposed
> the retirement
> >  >
> >  > - https://review.opendev.org/c/openstack/governance/+/886880
> >  >
> >  > -gmann
> >  >
> >  >  ---- On Thu, 13 Apr 2023 07:54:12 -0700  James Page  wrote ---
> >  >  > Hi All
> >  >  >
> >  >  > As announced by Lucian last November (see [0]) Cloudbase Solutions
> are no longer in a position to maintain
> > support for running OpenStack on Windows and have also ceased operation
> of their 3rd party CI for the windows support
> > across a number of OpenStack projects.
> >  >  > This situation has resulted in the Winstackers project becoming
> PTL-less for the 2023.2 cycle with no volunteers
> > responding to the TC's call to fill this role and take this feature in
> OpenStack forward (see [1]).
> >  >  > This is the final call for any maintainers to step forward if this
> feature is important to them in OpenStack.
> >  >  > The last user survey in 2022 indicated that 2% of respondents were
> running on Hyper-V so this might be important
> > enough to warrant a commitment from someone operating OpenStack on
> Windows to maintain these features going forward.
> >  >  > Here is a reminder from Lucian's original email on the full list
> of projects which are impacted in some way: *
> > nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver*
> os-win - common Windows library for Openstack*
> > neutron hyperv ml2 plugin and agent* ovs on Windows and neutron ovs
> agent support* cinder drivers - SMB and Windows
> > iSCSI* os-brick Windows connectors - iSCSI, FC, SMB, RBD* ceilometer
> Windows poller* manila Windows driver* glance
> > Windows support* freerdp gateway
> >  >  > The lack of 3rd party CI for testing all of this really needs to
> be addressed as well.
> >  >  > If no maintainers are forthcoming between now and the next PTG in
> June the TC will need to officially retire the
> > project and start the process of removing support for Windows across the
> various projects that support this operating
> > system in some way - either directly or through the use of os-win.
> >  >  > For clarity this call refers to the use of the Hyper-V
> virtualisation driver and associated Windows server
> > components to provide WIndows based OpenStack Hypervisors and does not
> relate to the ability to run Windows images as
> > guests on OpenStack.
> >  >  > Regards
> >  >  > James
> >  >  >
> > [0]
> https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html[1]
>  https://lists.openstack.org/p
> > ipermail/openstack-discuss/2023-March/032888.html
> >  >
> >  >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230911/c7b8b8a1/attachment.htm>

From tkajinam at redhat.com  Mon Sep 11 09:52:43 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Mon, 11 Sep 2023 18:52:43 +0900
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and
 maintainers
In-Reply-To: <CANWE-Ck6K-HeXQSNubjQYH5yDubqdqCy_TaVMUi_K=ur6eAPiw@mail.gmail.com>
References: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
 <188ea6f2a53.ee65931886747.6600003948918544663@ghanshyammann.com>
 <CAL_crJTTn2=y5_6rg2ODPWb3Rvc=BvOt=MeQ2F7FosL9YfdWWg@mail.gmail.com>
 <18a8231992c.b2b8601b117458.1449700563057999548@ghanshyammann.com>
 <582161586dfebca1b43576a837244a1f0846e0b7.camel@redhat.com>
 <CANWE-Ck6K-HeXQSNubjQYH5yDubqdqCy_TaVMUi_K=ur6eAPiw@mail.gmail.com>
Message-ID: <CAL_crJRrVADNMZ=t7MQtzfZyYGwmoEArzB5c_ZLzHRzOJnaqTQ@mail.gmail.com>

> > > For the Windows feature other than os-win dependencies, it is up to
the projects, and if they can still
> > > support and test those without 3rd party CI, then it is okay to keep
it. This applies to any other distro-specific
> > > features also where they might be supported by a few projects but not
all. But they should go through the
> > > deprecation phase warning even they are not tested so that users get
the notification.
> > >
I'm worried about "might be supported by a few projects" approach here,
because that would eventually
block deprecating/removing Windows support from oslo. We now have some
features like eventlog[1] or
some logics to support Windows[2]. Should we keep these until all projects
declare deprecation and removal
of Windows support ? Based on my past experiences, some of our projects
have been inactive for a while
and haven't been aligned with this kind of global changes being made. So I
feel like this would eventually
mean we can't remove these implementations from oslo really.
I'd rather prefer seeing common agreement across all projects, and set the
expected timeline so that we can
drop unmaintained codes.

[1] https://review.opendev.org/c/openstack/oslo.log/+/894235
[2]
https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/processutils.py#L46-L53

> > my goal in this regard would be to land the removal of both the hyperv
and vmware driver before milestone one
> > and perhaps even before the ptg if there is no object to it in our irc
team meeting.
(this is off topic)
I'm wondering if removal of vmware drivers means that we should consider
deprecating and removing vmware drivers
in glance and cinder, as these drivers are meant to be used with vmware
virt drivers.

> What you just said. IIRC, we kinda agreed on the PTG to try to avoid as
much as possible any deprecations during
> the 2023.2 Bobcat release, which is a non-SLURP release, as it would be
skipped by operators fast-jumping to 2024.1,
> unless someone would forward-port the deprecation note to Caracal, hence
putting the burden on someone's shoulder.
My understanding was that we can deprecate features at 2023.2, as long as
we don't remove these at 2024.1,
(removal should be done at 2024.2 or later), though I agree that
deprecating features at 2023.2 are not much
useful because the removal timeline can't be changed even if we deprecate
features "early".


On Mon, Sep 11, 2023 at 6:35?PM Sylvain Bauza <sylvain.bauza at gmail.com>
wrote:

>
>
> Le lun. 11 sept. 2023 ? 11:03, <smooney at redhat.com> a ?crit :
>
>> On Sun, 2023-09-10 at 20:03 -0700, Ghanshyam Mann wrote:
>> >  ---- On Fri, 08 Sep 2023 05:19:13 -0700  Takashi Kajinami  wrote ---
>> >  > Let me bump this old thread because we still need some follow-up
>> about the retirement of os-win.
>> >  > I noticed that some projects have not yet deprecated the
>> implementations dependent on os-win.I submitted a few
>> > patches to make these implementations deprecated so that we can
>> smoothly remove thesein the
>> > future. https://review.opendev.org/c/openstack/cinder/+/894237
>> > https://review.opendev.org/c/openstack/glance/+/894236
>> https://review.opendev.org/c/openstack/ceilometer/+/894296It'd
>> > be nice if the relevant teams can review these.
>> >  >
>> >  > My remaining question is whether we should mark all implementations
>> for Windows support, which are not
>> > directlydependent on os-win[1]. Technically we can go through
>> individual projects and add warning logs and release
>> > notesabout the deprecation. However I'm not too sure if that's worth
>> the effort. If we can agree that we remove
>> > supportfor running OpenStack on Windows Operating System at a specific
>> release, then I tend to leave the ones
>> > independentfrom os-win, unless it has any impact on user-facing items
>> like config options[1].
>> >  > I'd like to hear any thoughts about this plan, as well as any target
>> release to remove Windows "host" support
>> > globallyfrom OpenStack (maybe after 2024.1 release ?).
>> >
>> > Thanks for marking a few of the Windows support things as deprecated.
>> This is the right direction for at least where
>> > it
>> > depends on os-win. I have started completing the os-win retirement and
>> deps[1]. But we need to add a deprecation
>> > warning in one cycle and then remove it in a later one (like you are
>> doing in the mentioned changes). We did the
>> > same in the Nova Hyper-V driver, which was marked deprecated in the
>> 2023.1 cycles, and I am proposing it to be
>> > removed in the next cycle, 2024.1[2].
>> you bet me too it
>> there are already two other nova cores (myself and one other) that also
>> planned to do this after confirming with the
>> wider team at the next ptg so this is highly likely to proceed early in
>> the 2024.1 cycle.
>> my goal in this regard would be to land the removal of both the hyperv
>> and vmware driver before milestone one
>> and perhaps even before the ptg if there is no object to it in our irc
>> team meeting.
>>
>> i was waiting for RC-1 to be cut and the dust to settle before brign this
>> up to discuss but it seams at least 3 fo the
>> nova core team feel this is thr correct direction to take now.
>>
>
>
> What you just said. IIRC, we kinda agreed on the PTG to try to avoid as
> much as possible any deprecations during the 2023.2 Bobcat release, which
> is a non-SLURP release, as it would be skipped by operators fast-jumping to
> 2024.1, unless someone would forward-port the deprecation note to Caracal,
> hence putting the burden on someone's shoulder.
>
> Reinstanting my personal take then, which is, as a Nova PTL, I'm not 100%
> happy with taking my burden.
> Please, please, let's wait for 4 days and nothing or nooone will then get
> hurt :-)
>
> >
>> > For the Windows feature other than os-win dependencies, it is up to the
>> projects, and if they can still
>> > support and test those without 3rd party CI, then it is okay to keep
>> it. This applies to any other distro-specific
>> > features also where they might be supported by a few projects but not
>> all. But they should go through the
>> > deprecation phase warning even they are not tested so that users get
>> the notification.
>> >
>> > [1] https://review.opendev.org/q/+topic:retire-winstackers
>> > [2] https://review.opendev.org/c/openstack/nova/+/894466
>> >
>> > -gmann
>> >
>> >  >
>> >  > [1] Some
>> > examples
>> https://github.com/openstack/ceilometer/blob/d31d4ed3574a5d19fe4b09ab2c227dba64da170a/ceilometer/cmd/polling
>> .
>> > py#L95-L96
>> https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py#L624-L625
>> >  > [2] event_log option in oslo.log is one good example
>> https://review.opendev.org/c/openstack/oslo.log/+/894235
>> >  > On Sat, Jun 24, 2023 at 7:50?AM Ghanshyam Mann
>> gmann at ghanshyammann.com> wrote:
>> >  > As there is no volunteer to maintain this project, I have proposed
>> the retirement
>> >  >
>> >  > - https://review.opendev.org/c/openstack/governance/+/886880
>> >  >
>> >  > -gmann
>> >  >
>> >  >  ---- On Thu, 13 Apr 2023 07:54:12 -0700  James Page  wrote ---
>> >  >  > Hi All
>> >  >  >
>> >  >  > As announced by Lucian last November (see [0]) Cloudbase
>> Solutions are no longer in a position to maintain
>> > support for running OpenStack on Windows and have also ceased operation
>> of their 3rd party CI for the windows support
>> > across a number of OpenStack projects.
>> >  >  > This situation has resulted in the Winstackers project becoming
>> PTL-less for the 2023.2 cycle with no volunteers
>> > responding to the TC's call to fill this role and take this feature in
>> OpenStack forward (see [1]).
>> >  >  > This is the final call for any maintainers to step forward if
>> this feature is important to them in OpenStack.
>> >  >  > The last user survey in 2022 indicated that 2% of respondents
>> were running on Hyper-V so this might be important
>> > enough to warrant a commitment from someone operating OpenStack on
>> Windows to maintain these features going forward.
>> >  >  > Here is a reminder from Lucian's original email on the full list
>> of projects which are impacted in some way: *
>> > nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver*
>> os-win - common Windows library for Openstack*
>> > neutron hyperv ml2 plugin and agent* ovs on Windows and neutron ovs
>> agent support* cinder drivers - SMB and Windows
>> > iSCSI* os-brick Windows connectors - iSCSI, FC, SMB, RBD* ceilometer
>> Windows poller* manila Windows driver* glance
>> > Windows support* freerdp gateway
>> >  >  > The lack of 3rd party CI for testing all of this really needs to
>> be addressed as well.
>> >  >  > If no maintainers are forthcoming between now and the next PTG in
>> June the TC will need to officially retire the
>> > project and start the process of removing support for Windows across
>> the various projects that support this operating
>> > system in some way - either directly or through the use of os-win.
>> >  >  > For clarity this call refers to the use of the Hyper-V
>> virtualisation driver and associated Windows server
>> > components to provide WIndows based OpenStack Hypervisors and does not
>> relate to the ability to run Windows images as
>> > guests on OpenStack.
>> >  >  > Regards
>> >  >  > James
>> >  >  >
>> > [0]
>> https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html[1]
>>  https://lists.openstack.org/p
>> > ipermail/openstack-discuss/2023-March/032888.html
>> >  >
>> >  >
>> >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230911/fe336ce5/attachment-0001.htm>

From gmann at ghanshyammann.com  Mon Sep 11 16:58:09 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 11 Sep 2023 09:58:09 -0700
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and
 maintainers
In-Reply-To: <CANWE-Ck6K-HeXQSNubjQYH5yDubqdqCy_TaVMUi_K=ur6eAPiw@mail.gmail.com>
References: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
 <188ea6f2a53.ee65931886747.6600003948918544663@ghanshyammann.com>
 <CAL_crJTTn2=y5_6rg2ODPWb3Rvc=BvOt=MeQ2F7FosL9YfdWWg@mail.gmail.com>
 <18a8231992c.b2b8601b117458.1449700563057999548@ghanshyammann.com>
 <582161586dfebca1b43576a837244a1f0846e0b7.camel@redhat.com>
 <CANWE-Ck6K-HeXQSNubjQYH5yDubqdqCy_TaVMUi_K=ur6eAPiw@mail.gmail.com>
Message-ID: <18a852ddb68.c31854af213429.4828409396795574479@ghanshyammann.com>

 ---- On Mon, 11 Sep 2023 02:35:03 -0700  Sylvain Bauza  wrote --- 
 > 
 > 
 > Le?lun. 11 sept. 2023 ??11:03, smooney at redhat.com> a ?crit?:
 > On Sun, 2023-09-10 at 20:03 -0700, Ghanshyam Mann wrote:
 > > ?---- On Fri, 08 Sep 2023 05:19:13 -0700? Takashi Kajinami? wrote --- 
 > > ?> Let me bump this old thread because we still need some follow-up about the retirement of os-win.
 > > ?> I noticed that some projects have not yet deprecated the implementations dependent on os-win.I submitted a few
 > > patches to make these implementations deprecated so that we can smoothly remove thesein the
 > > future.?https://review.opendev.org/c/openstack/cinder/+/894237?
 > > https://review.opendev.org/c/openstack/glance/+/894236?https://review.opendev.org/c/openstack/ceilometer/+/894296It'd?
 > > be nice if the relevant teams can review these.
 > > ?> 
 > > ?> My remaining question is whether we should mark all implementations for Windows support, which are not
 > > directlydependent on os-win[1]. Technically we can go through individual projects and add warning logs and release
 > > notesabout the deprecation. However I'm not too sure if that's worth the effort. If we can agree that we remove
 > > supportfor running OpenStack on Windows Operating System at a specific release, then I tend to leave the ones
 > > independentfrom os-win, unless it has any impact on user-facing items like config options[1].
 > > ?> I'd like to hear any thoughts about this plan, as well as any target release to remove Windows "host" support
 > > globallyfrom OpenStack (maybe after 2024.1 release ?).
 > > 
 > > Thanks for marking a few of the Windows support things as deprecated. This is the right direction for at least where
 > > it
 > > depends on os-win. I have started completing the os-win retirement and deps[1]. But we need to add a deprecation
 > > warning in one cycle and then remove it in a later one (like you are doing in the mentioned changes). We did the
 > > same in the Nova Hyper-V driver, which was marked deprecated in the 2023.1 cycles, and I am proposing it to be
 > > removed in the next cycle, 2024.1[2].
 > you bet me too it
 > there are already two other nova cores (myself and one other) that also planned to do this after confirming with the
 > wider team at the next ptg so this is highly likely to proceed early in the 2024.1 cycle.
 > my goal in this regard would be to land the removal of both the hyperv and vmware driver before milestone one
 > and perhaps even before the ptg if there is no object to it in our irc team meeting.
 > 
 > i was waiting for RC-1 to be cut and the dust to settle before brign this up to discuss but it seams at least 3 fo the
 > nova core team feel this is thr correct direction to take now.
 > 
 > 
 > What you just said. IIRC, we kinda agreed on the PTG to try to avoid as much as possible any deprecations during the 2023.2 Bobcat release, which is a non-SLURP release, as it would be skipped by operators fast-jumping to 2024.1, unless someone would forward-port the deprecation note to Caracal, hence putting the burden on someone's shoulder.
 > Reinstanting my personal take then, which is, as a Nova PTL, I'm not 100% happy with taking my burden.Please, please, let's wait for 4 days and nothing or nooone will then get hurt :-)?

Yes, there is no plan to remove the things in 2023.2 even that is why I waited to remove the os-win
content etc. I have kept hyper-V removal commit as -W and to wait for the 2023.2 release and to
discuss it in PTG first.

-gmann


 > > 
 > > For the Windows feature other than os-win dependencies, it is up to the projects, and if they can still
 > > support and test those without 3rd party CI, then it is okay to keep it. This applies to any other distro-specific
 > > features also where they might be supported by a few projects but not all. But they should go through the
 > > deprecation phase warning even they are not tested so that users get the notification. 
 > > 
 > > [1] https://review.opendev.org/q/+topic:retire-winstackers
 > > [2] https://review.opendev.org/c/openstack/nova/+/894466
 > > 
 > > -gmann
 > > 
 > > ?> 
 > > ?> [1] Some
 > > examples?https://github.com/openstack/ceilometer/blob/d31d4ed3574a5d19fe4b09ab2c227dba64da170a/ceilometer/cmd/polling.
 > > py#L95-L96?https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py#L624-L625
 > > ?> [2] event_log option in oslo.log is one good example https://review.opendev.org/c/openstack/oslo.log/+/894235
 > > ?> On Sat, Jun 24, 2023 at 7:50?AM Ghanshyam Mann gmann at ghanshyammann.com> wrote:
 > > ?> As there is no volunteer to maintain this project, I have proposed the retirement
 > > ?> 
 > > ?> - https://review.opendev.org/c/openstack/governance/+/886880
 > > ?> 
 > > ?> -gmann
 > > ?> 
 > > ?> ?---- On Thu, 13 Apr 2023 07:54:12 -0700? James Page? wrote --- 
 > > ?> ?> Hi All
 > > ?> ?> 
 > > ?> ?> As announced by Lucian last November (see [0]) Cloudbase Solutions are no longer in a position to maintain
 > > support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support
 > > across a number of OpenStack projects.
 > > ?> ?> This situation has resulted in the Winstackers project becoming PTL-less for the 2023.2 cycle with no volunteers
 > > responding to the TC's call to fill this role and take this feature in OpenStack forward (see [1]).
 > > ?> ?> This is the final call for any maintainers to step forward if this feature is important to them in OpenStack.
 > > ?> ?> The last user survey in 2022 indicated that 2% of respondents were running on Hyper-V so this might be important
 > > enough to warrant a commitment from someone operating OpenStack on Windows to maintain these features going forward.
 > > ?> ?> Here is a reminder from Lucian's original email on the full list of projects which are impacted in some way:?*
 > > nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver* os-win - common Windows library for Openstack*
 > > neutron hyperv ml2 plugin and agent* ovs on Windows and neutron ovs agent support* cinder drivers - SMB and Windows
 > > iSCSI* os-brick Windows connectors - iSCSI, FC, SMB, RBD* ceilometer Windows poller* manila Windows driver* glance
 > > Windows support* freerdp gateway
 > > ?> ?> The lack of 3rd party CI for testing all of this really needs to be addressed as well.
 > > ?> ?> If no maintainers are forthcoming between now and the next PTG in June the TC will need to officially retire the
 > > project and start the process of removing support for Windows across the various projects that support this operating
 > > system in some way - either directly or through the use of os-win.
 > > ?> ?> For clarity this call refers to the use of the Hyper-V virtualisation driver and associated Windows server
 > > components to provide WIndows based OpenStack Hypervisors and does not relate to the ability to run Windows images as
 > > guests on OpenStack.
 > > ?> ?> Regards
 > > ?> ?> James
 > > ?> ?>
 > > [0]?https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html[1]?https://lists.openstack.org/p
 > > ipermail/openstack-discuss/2023-March/032888.html
 > > ?> 
 > > ?> 
 > > 
 > 
 > 
 > 


From gmann at ghanshyammann.com  Mon Sep 11 17:03:36 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 11 Sep 2023 10:03:36 -0700
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and
 maintainers
In-Reply-To: <CAL_crJRrVADNMZ=t7MQtzfZyYGwmoEArzB5c_ZLzHRzOJnaqTQ@mail.gmail.com>
References: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
 <188ea6f2a53.ee65931886747.6600003948918544663@ghanshyammann.com>
 <CAL_crJTTn2=y5_6rg2ODPWb3Rvc=BvOt=MeQ2F7FosL9YfdWWg@mail.gmail.com>
 <18a8231992c.b2b8601b117458.1449700563057999548@ghanshyammann.com>
 <582161586dfebca1b43576a837244a1f0846e0b7.camel@redhat.com>
 <CANWE-Ck6K-HeXQSNubjQYH5yDubqdqCy_TaVMUi_K=ur6eAPiw@mail.gmail.com>
 <CAL_crJRrVADNMZ=t7MQtzfZyYGwmoEArzB5c_ZLzHRzOJnaqTQ@mail.gmail.com>
Message-ID: <18a8532d84e.d2fc1ddc213774.3752711536494387942@ghanshyammann.com>

 ---- On Mon, 11 Sep 2023 02:52:43 -0700  Takashi Kajinami  wrote --- 
 > 
 > > > > For the Windows feature other than os-win dependencies, it is up to the projects, and if they can still
 > > > > support and test those without 3rd party CI, then it is okay to keep it. This applies to any other distro-specific
 > > > > features also where they might be supported by a few projects but not all. But they should go through the
 > > > > deprecation phase warning even they are not tested so that users get the notification. 
 > > > > 
 > I'm worried about "might be supported by a few projects" approach here, because that would eventuallyblock deprecating/removing Windows support from oslo. We now have some features like eventlog[1] orsome logics to support Windows[2]. Should we keep these until all projects declare deprecation and removalof Windows support ? Based on my past experiences, some of our projects have been inactive for a whileand haven't been aligned with this kind of global changes being made. So I feel like this would eventuallymean we can't remove these implementations from oslo really.

Honestlysaying , removing it from oslo at the end is the best approach. We can see if any project not active
or even do not know about their windows support then we can discuss with them otherwise let's project
deprecate and remove the things first and then from lib.

 > I'd rather prefer seeing common agreement across all projects, and set the expected timeline so that we candrop unmaintained codes.
 > 
 > [1] https://review.opendev.org/c/openstack/oslo.log/+/894235[2] https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/processutils.py#L46-L53
 > > > my goal in this regard would be to land the removal of both the hyperv and vmware driver before milestone one
 > > > and perhaps even before the ptg if there is no object to it in our irc team meeting.(this is off topic)I'm wondering if removal of vmware drivers means that we should consider deprecating and removing vmware driversin glance and cinder, as these drivers are meant to be used with vmware virt drivers.
 > > What you just said. IIRC, we kinda agreed on the PTG to try to avoid as much as possible any deprecations during> the 2023.2 Bobcat release, which is a non-SLURP release, as it would be skipped by operators fast-jumping to 2024.1,> unless someone would forward-port the deprecation note to Caracal, hence putting the burden on someone's shoulder.My understanding was that we can deprecate features at 2023.2, as long as we don't remove these at 2024.1, 
 > (removal should be done at 2024.2 or later), though I agree that deprecating features at 2023.2 are not muchuseful because the removal timeline can't be changed even if we deprecate features "early".

Yes, basic idea is to have deprecation warning for at least one SLURP release. If any project deprecating it
in 2023.2 then they need to wait till 2024.1 release for removal. For example, Nova deprecated Hyper-V driver
in 2023.1 (SLURP release) and should be good to remove it in next SLURP release which will be next cycle 2024.1

-gmann


 > 
 > On Mon, Sep 11, 2023 at 6:35?PM Sylvain Bauza sylvain.bauza at gmail.com> wrote:
 > 
 > 
 > Le?lun. 11 sept. 2023 ??11:03, smooney at redhat.com> a ?crit?:
 > On Sun, 2023-09-10 at 20:03 -0700, Ghanshyam Mann wrote:
 > > ?---- On Fri, 08 Sep 2023 05:19:13 -0700? Takashi Kajinami? wrote --- 
 > > ?> Let me bump this old thread because we still need some follow-up about the retirement of os-win.
 > > ?> I noticed that some projects have not yet deprecated the implementations dependent on os-win.I submitted a few
 > > patches to make these implementations deprecated so that we can smoothly remove thesein the
 > > future.?https://review.opendev.org/c/openstack/cinder/+/894237?
 > > https://review.opendev.org/c/openstack/glance/+/894236?https://review.opendev.org/c/openstack/ceilometer/+/894296It'd?
 > > be nice if the relevant teams can review these.
 > > ?> 
 > > ?> My remaining question is whether we should mark all implementations for Windows support, which are not
 > > directlydependent on os-win[1]. Technically we can go through individual projects and add warning logs and release
 > > notesabout the deprecation. However I'm not too sure if that's worth the effort. If we can agree that we remove
 > > supportfor running OpenStack on Windows Operating System at a specific release, then I tend to leave the ones
 > > independentfrom os-win, unless it has any impact on user-facing items like config options[1].
 > > ?> I'd like to hear any thoughts about this plan, as well as any target release to remove Windows "host" support
 > > globallyfrom OpenStack (maybe after 2024.1 release ?).
 > > 
 > > Thanks for marking a few of the Windows support things as deprecated. This is the right direction for at least where
 > > it
 > > depends on os-win. I have started completing the os-win retirement and deps[1]. But we need to add a deprecation
 > > warning in one cycle and then remove it in a later one (like you are doing in the mentioned changes). We did the
 > > same in the Nova Hyper-V driver, which was marked deprecated in the 2023.1 cycles, and I am proposing it to be
 > > removed in the next cycle, 2024.1[2].
 > you bet me too it
 > there are already two other nova cores (myself and one other) that also planned to do this after confirming with the
 > wider team at the next ptg so this is highly likely to proceed early in the 2024.1 cycle.
 > my goal in this regard would be to land the removal of both the hyperv and vmware driver before milestone one
 > and perhaps even before the ptg if there is no object to it in our irc team meeting.
 > 
 > i was waiting for RC-1 to be cut and the dust to settle before brign this up to discuss but it seams at least 3 fo the
 > nova core team feel this is thr correct direction to take now.
 > 
 > 
 > What you just said. IIRC, we kinda agreed on the PTG to try to avoid as much as possible any deprecations during the 2023.2 Bobcat release, which is a non-SLURP release, as it would be skipped by operators fast-jumping to 2024.1, unless someone would forward-port the deprecation note to Caracal, hence putting the burden on someone's shoulder.
 > Reinstanting my personal take then, which is, as a Nova PTL, I'm not 100% happy with taking my burden.Please, please, let's wait for 4 days and nothing or nooone will then get hurt :-)?
 > > 
 > > For the Windows feature other than os-win dependencies, it is up to the projects, and if they can still
 > > support and test those without 3rd party CI, then it is okay to keep it. This applies to any other distro-specific
 > > features also where they might be supported by a few projects but not all. But they should go through the
 > > deprecation phase warning even they are not tested so that users get the notification. 
 > > 
 > > [1] https://review.opendev.org/q/+topic:retire-winstackers
 > > [2] https://review.opendev.org/c/openstack/nova/+/894466
 > > 
 > > -gmann
 > > 
 > > ?> 
 > > ?> [1] Some
 > > examples?https://github.com/openstack/ceilometer/blob/d31d4ed3574a5d19fe4b09ab2c227dba64da170a/ceilometer/cmd/polling.
 > > py#L95-L96?https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py#L624-L625
 > > ?> [2] event_log option in oslo.log is one good example https://review.opendev.org/c/openstack/oslo.log/+/894235
 > > ?> On Sat, Jun 24, 2023 at 7:50?AM Ghanshyam Mann gmann at ghanshyammann.com> wrote:
 > > ?> As there is no volunteer to maintain this project, I have proposed the retirement
 > > ?> 
 > > ?> - https://review.opendev.org/c/openstack/governance/+/886880
 > > ?> 
 > > ?> -gmann
 > > ?> 
 > > ?> ?---- On Thu, 13 Apr 2023 07:54:12 -0700? James Page? wrote --- 
 > > ?> ?> Hi All
 > > ?> ?> 
 > > ?> ?> As announced by Lucian last November (see [0]) Cloudbase Solutions are no longer in a position to maintain
 > > support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support
 > > across a number of OpenStack projects.
 > > ?> ?> This situation has resulted in the Winstackers project becoming PTL-less for the 2023.2 cycle with no volunteers
 > > responding to the TC's call to fill this role and take this feature in OpenStack forward (see [1]).
 > > ?> ?> This is the final call for any maintainers to step forward if this feature is important to them in OpenStack.
 > > ?> ?> The last user survey in 2022 indicated that 2% of respondents were running on Hyper-V so this might be important
 > > enough to warrant a commitment from someone operating OpenStack on Windows to maintain these features going forward.
 > > ?> ?> Here is a reminder from Lucian's original email on the full list of projects which are impacted in some way:?*
 > > nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver* os-win - common Windows library for Openstack*
 > > neutron hyperv ml2 plugin and agent* ovs on Windows and neutron ovs agent support* cinder drivers - SMB and Windows
 > > iSCSI* os-brick Windows connectors - iSCSI, FC, SMB, RBD* ceilometer Windows poller* manila Windows driver* glance
 > > Windows support* freerdp gateway
 > > ?> ?> The lack of 3rd party CI for testing all of this really needs to be addressed as well.
 > > ?> ?> If no maintainers are forthcoming between now and the next PTG in June the TC will need to officially retire the
 > > project and start the process of removing support for Windows across the various projects that support this operating
 > > system in some way - either directly or through the use of os-win.
 > > ?> ?> For clarity this call refers to the use of the Hyper-V virtualisation driver and associated Windows server
 > > components to provide WIndows based OpenStack Hypervisors and does not relate to the ability to run Windows images as
 > > guests on OpenStack.
 > > ?> ?> Regards
 > > ?> ?> James
 > > ?> ?>
 > > [0]?https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html[1]?https://lists.openstack.org/p
 > > ipermail/openstack-discuss/2023-March/032888.html
 > > ?> 
 > > ?> 
 > > 
 > 
 > 
 > 


From fkr at osb-alliance.com  Mon Sep 11 19:45:18 2023
From: fkr at osb-alliance.com (Felix Kronlage-Dammers)
Date: Mon, 11 Sep 2023 21:45:18 +0200
Subject: [publiccloud-sig] Reminder - next meeting September 13th - 0700 UTC
Message-ID: <B2414B7D-58D0-4BFC-AA65-8F6A1140DB16@osb-alliance.com>

Hi everyone,

this Wednesday the next meeting of the public cloud sig is going to 
happen.
As announced a few weeks ago, we want to try out to have a videocall 
format every other meeting
of the public cloud SIG, so this time we will meet in a video call.

Part of the meeting will be a lightning talk. For the first lightning 
talk Artem (gtema@)
will talk on his work on ?OpenAPI support for OpenStack and making a 
new faster CLI on Rust?.
(There is a detailled mail about this work that Artem sent to this list 
End of August[1]).
Thanks a lot Artem for giving the first lightning talk in the new 
format.

We will meet at 0700 UTC here: 
https://conf.scs.koeln:8443/OIF-public-cloud-sig

In parallel we will be on irc on #openstack-operators as well of course.

Am very much looking forward to wednesday morning! :)

felix


[1] <url: 
https://lists.openstack.org/pipermail/openstack-discuss/2023-August/034934.html>
--
Felix Kronlage-Dammers
Product Owner IaaS & Operations Sovereign Cloud Stack

Sovereign Cloud Stack ? standardized, built and operated by many
Ein Projekt der Open Source Business Alliance - Bundesverband f?r 
digitale Souver?nit?t e.V.

Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | 
fkr at osb-alliance.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230911/f039fbb3/attachment-0001.htm>

From roger.riverac at gmail.com  Mon Sep 11 20:07:40 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Mon, 11 Sep 2023 16:07:40 -0400
Subject: [openstack-ansible] Dedicated gateway hosts not working with OVN
In-Reply-To: <BL1PR20MB4609860418513958DF7110DF8EEDA@BL1PR20MB4609.namprd20.prod.outlook.com>
References: <CAGe_Kfxkco+Zar9QbTzzw9u6aNGeGoMkMTH6K6TS6KWRnbDjtQ@mail.gmail.com>
 <CAPd_6AvQ7WEvaugcP7oZEAGz68vEHTKosYnyM_+HS-r4QFryrA@mail.gmail.com>
 <20230208143243.dth426y74jyfacxh@yuggoth.org>
 <CAGe_KfxmNBRWxCjq_uZb0Ek9F_sQpmC=ECSQfoSqsV0He82iZA@mail.gmail.com>
 <CAGe_KfwmP+4ovCrMwt+X050ZPrYD+1DUMvmTOV+xBW_UYF11Wg@mail.gmail.com>
 <CAPd_6AtvYxf-tJ2TrNOE99jY4qBnqpxk46N5EnHj+1zj+-ukUA@mail.gmail.com>
 <CAGe_KfzqXYegVzNiLeKx_D4Ob2v=XHOJeRaFr0UnYpByysEqRQ@mail.gmail.com>
 <CAPd_6AvoS7nZjYTz_7zS-MU-+U0b0qwTGoojOEp7nBsiw+XKDg@mail.gmail.com>
 <CAPd_6AsU_s-ptfBOiH3eRmtU7-mh4RG33N7_CJEirAioeM-35g@mail.gmail.com>
 <CAGe_KfySPjn_B78xC_MOmoD_4g-bGasNufsscmpLXMkm4a=sig@mail.gmail.com>
 <CAPd_6At6AkU5QUAz0N0W60ftGyMChaGUkAxA_it0wnFUhmjKyA@mail.gmail.com>
 <CAGe_Kfyw2HGzbLPx33tyA3Oiby3DfAcAGM2cD7V8Twb5UcLAYw@mail.gmail.com>
 <CAPd_6AuAiU1fc7-uXV0EQpyQ-iQ6A6T_YqXxfbr5QXuijaRE2A@mail.gmail.com>
 <BL1PR20MB460943F06D3025B36337007D8EEEA@BL1PR20MB4609.namprd20.prod.outlook.com>
 <CAGe_KfywcDq3yRMOLb4BpZ1872BZYZcbfTiFdXkxpmF5=erqgA@mail.gmail.com>
 <CAPgF-frFUYkcaH6rfp2i2+RS=q7p3Lk6LvSkjuKOfAwDKeqmHw@mail.gmail.com>
 <CAGe_KfzFGoT417fne=fum6LYtQic4TYSacsiRie89eAbA-sKyQ@mail.gmail.com>
 <BL1PR20MB46099B8B78FF800F3382EB1F8EEDA@BL1PR20MB4609.namprd20.prod.outlook.com>
 <CAGe_Kfx4fG96rNh1QD3qOT4joD+WS=5pHXoM2SiMAiyDDyJ4Ug@mail.gmail.com>
 <BL1PR20MB4609860418513958DF7110DF8EEDA@BL1PR20MB4609.namprd20.prod.outlook.com>
Message-ID: <CAGe_KfzOLOVmqDhDgAicy8=E-GspwF7dHRd-CdX=KxjksqBsqw@mail.gmail.com>

Hello everyone,

The openstack-ansible deployment was all good. Turns out it was a network
configuration problem for the external network. Aside from the below issues
which have been addressed, everything runs as expected now.

-OVN deployments fail when the provider bridge is defined for gateway hosts
and not for compute nodes.
-Add split(',') python list to supported_provider_types on
templates/horizon_local_settings.py.j2

Thank you everyone for all the help. This cleared out a lot of doubts.

Best regards.


On Fri, Sep 8, 2023 at 11:28?AM James Denton <james.denton at rackspace.com>
wrote:

> Thanks, Roger. Super helpful.
>
> If you?re attempting to launch the VM on that network it will fail, since
> that network is only plumbed to the net nodes as an 'external' network. For
> the VM, you will want to create a non-provider (tenant) network, which
> would likely be geneve, and then create a neutron router that connects to
> the external network and the tenant network. Your VM traffic would then
> traverse that router from compute->net node and out over the geneve overlay.
>
> Keep us posted.
>
> James
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* Roger Rivera <roger.riverac at gmail.com>
> *Sent:* Friday, September 8, 2023 8:43:19 AM
> *To:* James Denton <james.denton at rackspace.com>
> *Cc:* Satish Patel <satish.txt at gmail.com>; Dmitriy Rabotyagov <
> noonedeadpunk at gmail.com>; openstack-discuss <
> openstack-discuss at lists.openstack.org>
> *Subject:* Re: [openstack-ansible] Dedicated gateway hosts not working
> with OVN
>
> CAUTION: This message originated externally, please use caution when
> clicking on links or opening attachments!
>
> Hello James,
>
> I appreciate the prompt response. Please see the output for openstack
> network show <net> , pasted at
> https://paste.opendev.org/show/bIhYhu6fDWoMaIiyaRMJ/
>
> Thanks you
>
> On Fri, Sep 8, 2023 at 9:31?AM James Denton <james.denton at rackspace.com>
> wrote:
>
> Hi Roger,
>
> That output looks as I would expect, thank you.
>
> Can you please provide the output for ?openstack network show? for the
> network being attached to the VM?
>
> Thanks,
> James
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* Roger Rivera <roger.riverac at gmail.com>
> *Sent:* Friday, September 8, 2023 8:11:06 AM
> *To:* Satish Patel <satish.txt at gmail.com>
> *Cc:* James Denton <james.denton at rackspace.com>; Dmitriy Rabotyagov <
> noonedeadpunk at gmail.com>; openstack-discuss <
> openstack-discuss at lists.openstack.org>
> *Subject:* Re: [openstack-ansible] Dedicated gateway hosts not working
> with OVN
>
> CAUTION: This message originated externally, please use caution when
> clicking on links or opening attachments!
>
> Hello Satish,
>
> I appreciate your feedback and any help will be greatly appreciated.
> Please find the requested outputs pasted here:
> https://paste.opendev.org/show/bHWvGMUYW35sU43zUxem/
>
> I've included outputs for one compute and one network/gateway node.
>
> As a recap, among other nodes, the environment includes:
>
> -2x compute - 1x NIC ens1 with IPv4 (geneve) - no bridges
> -2x network/gateway nodes - 2x NICs - ens1 with IPv4 (geneve), ens2 as
> external net interface, br-vlan connected to ens2 bridge.
>
> Let me know if you need further information. Much appreciated.
>
> Thank you.
>
>
>
> --
> *Roger Rivera*
>


-- 
*Roger Rivera*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230911/8577106c/attachment.htm>

From amy at demarco.com  Mon Sep 11 20:16:02 2023
From: amy at demarco.com (Amy Marrich)
Date: Mon, 11 Sep 2023 15:16:02 -0500
Subject: [Diversity] Diversity and Inclusion WG Meeting reminder
Message-ID: <CAFs83Qo_g-Sv_JVTjPqcsiaYY-vGnauwYtZJ2LVYvjZxBd8AtA@mail.gmail.com>

This is a reminder that the Diversity and Inclusion WG will be meeting
tomorrow at 14:00 UTC in the #openinfra-diversity channel on OFTC. We
hope members of all OpenInfra projects join us as we look at the
progress on responses to the Foundation-wide diversity survey.

Thanks,

Amy (spotz)
0 - https://etherpad.opendev.org/p/diversity-wg-agenda


From jamesleong123098 at gmail.com  Tue Sep 12 02:02:06 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Mon, 11 Sep 2023 21:02:06 -0500
Subject: [kolla-ansible][horizon][policy]
Message-ID: <CA+_ZFmHMwibuC010TT-FnEJQRZduh-SRe=2xa9pSWvMPbafssg@mail.gmail.com>

Hi all,

I am currently having a yoga version openstack. I noticed that user from a
domain are able to view other domain leases if they are having admin role.
Is there any possible way to change anything in the policy file? I have
tried to add rule:owner but it didn't work out the way I wanted. Any
recommendations would be appreciated.

Best,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230911/41c8262e/attachment.htm>

From ygk.kmr at gmail.com  Tue Sep 12 03:55:32 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Tue, 12 Sep 2023 09:25:32 +0530
Subject: Nova conductor errors
Message-ID: <CAJreVFwEoc4wKrF4wi-pj9unaod9yx0b71ZfY741e6Ldjhb8jg@mail.gmail.com>

Hi All,

We have a Yoga OSA setup. We have been observing the following errors in
the nova conductor service intermittently. After a restart of the service,
they seem to disappear. The logs are as follows:

---
nova-conductor[3199409]:  ERROR oslo.messaging._drivers.impl_rabbit [-]
Connection failed: [Errno 24] Too many open files (retrying in 0 seconds):
OSError: [Errno 24] Too many open files
---

Is it a known issue with yoga ? Please let me know.


Thanks
Y.G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/9cfd90f8/attachment.htm>

From noonedeadpunk at gmail.com  Tue Sep 12 07:34:14 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 12 Sep 2023 09:34:14 +0200
Subject: Nova conductor errors
In-Reply-To: <CAJreVFwEoc4wKrF4wi-pj9unaod9yx0b71ZfY741e6Ldjhb8jg@mail.gmail.com>
References: <CAJreVFwEoc4wKrF4wi-pj9unaod9yx0b71ZfY741e6Ldjhb8jg@mail.gmail.com>
Message-ID: <CAPd_6Asse6+FwgB4=JB7p5UrQPAppukYTBHL=NVTCLamKOMhOg@mail.gmail.com>

Hey,

We are aware of this issue happening on compute nodes, when some
instances have a lot of volumes attached. For this purpose we define
following variable:

nova_compute_init_overrides:
  Service:
    LimitNOFILE: 4096

Same thing happening on nova-conductor makes me think of this bug
related to heartbeat_in_pthread change[1][2]. IIRC, it was also able
to leak file descriptors, that you can see as "Too many open files"
error.
Though bugfixes were backported to Yoga from what I see. But you can
try adding "nova_oslomsg_heartbeat_in_pthread: False" to your
user_variables and re-run os-nova-install.yml playbook.

[1] https://bugs.launchpad.net/openstack-ansible/+bug/1961603
[2] https://bugs.launchpad.net/oslo.messaging/+bug/1949964


??, 12 ????. 2023??. ? 05:58, Gk Gk <ygk.kmr at gmail.com>:
>
> Hi All,
>
> We have a Yoga OSA setup. We have been observing the following errors in the nova conductor service intermittently. After a restart of the service, they seem to disappear. The logs are as follows:
>
> ---
> nova-conductor[3199409]:  ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 24] Too many open files (retrying in 0 seconds): OSError: [Errno 24] Too many open files
> ---
>
> Is it a known issue with yoga ? Please let me know.
>
>
> Thanks
> Y.G


From noonedeadpunk at gmail.com  Tue Sep 12 07:45:48 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 12 Sep 2023 09:45:48 +0200
Subject: [openstack-ansible] Meeting on 12.09.2023 is cancelled
Message-ID: <CAPd_6Avm6PGPsU7gOPY3J_J=0uE6JnFpmB+qwaV+ESci70v4wg@mail.gmail.com>

Hi everyone,

Due to the absence of multiple core members of the group during this
week, it has been decided to cancel our regular community meeting on
12.09.2023.


From smooney at redhat.com  Tue Sep 12 09:09:31 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Tue, 12 Sep 2023 10:09:31 +0100
Subject: Nova conductor errors
In-Reply-To: <CAPd_6Asse6+FwgB4=JB7p5UrQPAppukYTBHL=NVTCLamKOMhOg@mail.gmail.com>
References: <CAJreVFwEoc4wKrF4wi-pj9unaod9yx0b71ZfY741e6Ldjhb8jg@mail.gmail.com>
 <CAPd_6Asse6+FwgB4=JB7p5UrQPAppukYTBHL=NVTCLamKOMhOg@mail.gmail.com>
Message-ID: <3ccbca93cb9e0178af2c5ea054fea43800ff79e5.camel@redhat.com>

On Tue, 2023-09-12 at 09:34 +0200, Dmitriy Rabotyagov wrote:
> Hey,
> 
> We are aware of this issue happening on compute nodes, when some
> instances have a lot of volumes attached. For this purpose we define
> following variable:
> 
> nova_compute_init_overrides:
> ? Service:
> ??? LimitNOFILE: 4096
> 
> Same thing happening on nova-conductor makes me think of this bug
> related to heartbeat_in_pthread change[1][2].
the heat beat in pthread is only intented to be used in the api and it activly
breaks the nova-compute agent. i suspect its also not a good idea to have enabled
for the conducotr or scheduler as i expect that to behave like the compute agent.
>  IIRC, it was also able
> to leak file descriptors, that you can see as "Too many open files"
> error.
> Though bugfixes were backported to Yoga from what I see. But you can
> try adding "nova_oslomsg_heartbeat_in_pthread: False" to your
> user_variables and re-run os-nova-install.yml playbook.
if osa is enabling the heartbeat_in_pthread on the conductor or anything
other the the api and metadata its a bug  in osa
> 
> [1] https://bugs.launchpad.net/openstack-ansible/+bug/1961603
> [2] https://bugs.launchpad.net/oslo.messaging/+bug/1949964
> 
> 
> ??, 12 ????. 2023??. ? 05:58, Gk Gk <ygk.kmr at gmail.com>:
> > 
> > Hi All,
> > 
> > We have a Yoga OSA setup. We have been observing the following errors in the nova conductor service intermittently.
> > After a restart of the service, they seem to disappear. The logs are as follows:
> > 
> > ---
> > nova-conductor[3199409]:? ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 24] Too many open
> > files (retrying in 0 seconds): OSError: [Errno 24] Too many open files
> > ---
> > 
> > Is it a known issue with yoga ? Please let me know.
> > 
> > 
> > Thanks
> > Y.G
> 



From ygk.kmr at gmail.com  Tue Sep 12 09:29:26 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Tue, 12 Sep 2023 14:59:26 +0530
Subject: Nova conductor errors
In-Reply-To: <3ccbca93cb9e0178af2c5ea054fea43800ff79e5.camel@redhat.com>
References: <CAJreVFwEoc4wKrF4wi-pj9unaod9yx0b71ZfY741e6Ldjhb8jg@mail.gmail.com>
 <CAPd_6Asse6+FwgB4=JB7p5UrQPAppukYTBHL=NVTCLamKOMhOg@mail.gmail.com>
 <3ccbca93cb9e0178af2c5ea054fea43800ff79e5.camel@redhat.com>
Message-ID: <CAJreVFwMFAFmwbiTbCr49uAwoRgmy-e6FKtdTBe8_Ue_ZmPNyQ@mail.gmail.com>

So, for the moment, how to proceed as a workaround  ?

On Tue, Sep 12, 2023 at 2:39?PM <smooney at redhat.com> wrote:

> On Tue, 2023-09-12 at 09:34 +0200, Dmitriy Rabotyagov wrote:
> > Hey,
> >
> > We are aware of this issue happening on compute nodes, when some
> > instances have a lot of volumes attached. For this purpose we define
> > following variable:
> >
> > nova_compute_init_overrides:
> >   Service:
> >     LimitNOFILE: 4096
> >
> > Same thing happening on nova-conductor makes me think of this bug
> > related to heartbeat_in_pthread change[1][2].
> the heat beat in pthread is only intented to be used in the api and it
> activly
> breaks the nova-compute agent. i suspect its also not a good idea to have
> enabled
> for the conducotr or scheduler as i expect that to behave like the compute
> agent.
> >  IIRC, it was also able
> > to leak file descriptors, that you can see as "Too many open files"
> > error.
> > Though bugfixes were backported to Yoga from what I see. But you can
> > try adding "nova_oslomsg_heartbeat_in_pthread: False" to your
> > user_variables and re-run os-nova-install.yml playbook.
> if osa is enabling the heartbeat_in_pthread on the conductor or anything
> other the the api and metadata its a bug  in osa
> >
> > [1] https://bugs.launchpad.net/openstack-ansible/+bug/1961603
> > [2] https://bugs.launchpad.net/oslo.messaging/+bug/1949964
> >
> >
> > ??, 12 ????. 2023??. ? 05:58, Gk Gk <ygk.kmr at gmail.com>:
> > >
> > > Hi All,
> > >
> > > We have a Yoga OSA setup. We have been observing the following errors
> in the nova conductor service intermittently.
> > > After a restart of the service, they seem to disappear. The logs are
> as follows:
> > >
> > > ---
> > > nova-conductor[3199409]:  ERROR oslo.messaging._drivers.impl_rabbit
> [-] Connection failed: [Errno 24] Too many open
> > > files (retrying in 0 seconds): OSError: [Errno 24] Too many open files
> > > ---
> > >
> > > Is it a known issue with yoga ? Please let me know.
> > >
> > >
> > > Thanks
> > > Y.G
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/57783ed6/attachment.htm>

From noonedeadpunk at gmail.com  Tue Sep 12 09:50:32 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 12 Sep 2023 11:50:32 +0200
Subject: Nova conductor errors
In-Reply-To: <CAJreVFwMFAFmwbiTbCr49uAwoRgmy-e6FKtdTBe8_Ue_ZmPNyQ@mail.gmail.com>
References: <CAJreVFwEoc4wKrF4wi-pj9unaod9yx0b71ZfY741e6Ldjhb8jg@mail.gmail.com>
 <CAPd_6Asse6+FwgB4=JB7p5UrQPAppukYTBHL=NVTCLamKOMhOg@mail.gmail.com>
 <3ccbca93cb9e0178af2c5ea054fea43800ff79e5.camel@redhat.com>
 <CAJreVFwMFAFmwbiTbCr49uAwoRgmy-e6FKtdTBe8_Ue_ZmPNyQ@mail.gmail.com>
Message-ID: <CAPd_6AvWMaZRpyatSV8u4W6vc8ifFPjXHvJ2-3MK_5eNDtrAeg@mail.gmail.com>

As I said, add "nova_oslomsg_heartbeat_in_pthread: False" to user_variables
and re-run os-nova-install.yml

On Tue, Sep 12, 2023, 11:29 Gk Gk <ygk.kmr at gmail.com> wrote:

> So, for the moment, how to proceed as a workaround  ?
>
> On Tue, Sep 12, 2023 at 2:39?PM <smooney at redhat.com> wrote:
>
>> On Tue, 2023-09-12 at 09:34 +0200, Dmitriy Rabotyagov wrote:
>> > Hey,
>> >
>> > We are aware of this issue happening on compute nodes, when some
>> > instances have a lot of volumes attached. For this purpose we define
>> > following variable:
>> >
>> > nova_compute_init_overrides:
>> >   Service:
>> >     LimitNOFILE: 4096
>> >
>> > Same thing happening on nova-conductor makes me think of this bug
>> > related to heartbeat_in_pthread change[1][2].
>> the heat beat in pthread is only intented to be used in the api and it
>> activly
>> breaks the nova-compute agent. i suspect its also not a good idea to have
>> enabled
>> for the conducotr or scheduler as i expect that to behave like the
>> compute agent.
>> >  IIRC, it was also able
>> > to leak file descriptors, that you can see as "Too many open files"
>> > error.
>> > Though bugfixes were backported to Yoga from what I see. But you can
>> > try adding "nova_oslomsg_heartbeat_in_pthread: False" to your
>> > user_variables and re-run os-nova-install.yml playbook.
>> if osa is enabling the heartbeat_in_pthread on the conductor or anything
>> other the the api and metadata its a bug  in osa
>> >
>> > [1] https://bugs.launchpad.net/openstack-ansible/+bug/1961603
>> > [2] https://bugs.launchpad.net/oslo.messaging/+bug/1949964
>> >
>> >
>> > ??, 12 ????. 2023??. ? 05:58, Gk Gk <ygk.kmr at gmail.com>:
>> > >
>> > > Hi All,
>> > >
>> > > We have a Yoga OSA setup. We have been observing the following errors
>> in the nova conductor service intermittently.
>> > > After a restart of the service, they seem to disappear. The logs are
>> as follows:
>> > >
>> > > ---
>> > > nova-conductor[3199409]:  ERROR oslo.messaging._drivers.impl_rabbit
>> [-] Connection failed: [Errno 24] Too many open
>> > > files (retrying in 0 seconds): OSError: [Errno 24] Too many open files
>> > > ---
>> > >
>> > > Is it a known issue with yoga ? Please let me know.
>> > >
>> > >
>> > > Thanks
>> > > Y.G
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/50670260/attachment-0001.htm>

From bartosz at stackhpc.com  Tue Sep 12 10:13:37 2023
From: bartosz at stackhpc.com (Bartosz Bezak)
Date: Tue, 12 Sep 2023 12:13:37 +0200
Subject: [Kolla] Transition Xena to EOL 
Message-ID: <5DF3C268-06C2-40B3-8BC9-850844C1F0AE@stackhpc.com>

Hello,

As aggreed on IRC meeting, Kolla Xena deliverables (Kolla, Kolla-Ansible, Kayobe, Ansible-Collection-Kolla) are going EOL. [1]
Yoga, Zed and Antelope are our current stable releases. Xena was in Extended Maintenance for a some time,
Kolla community does not have resources to support it actively.
All changes for Kolla project deliverables in Xena branches have been abandoned.

[1] https://review.opendev.org/c/openstack/releases/+/894630

Best regards, 
Bartosz Bezak



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/c97da558/attachment.htm>

From knikolla at bu.edu  Tue Sep 12 11:08:09 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Tue, 12 Sep 2023 11:08:09 +0000
Subject: [tc] Technical Committee next weekly meeting Today, September 12, 2023
Message-ID: <4A316283-E216-420E-BD4B-ECDF65E51761@bu.edu>

Hi all,

This is a reminder that the next weekly Technical Committee meeting is to be held today on Tuesday, September 12 2023 at 1800 UTC on #openstack-tc on OFTC IRC.

Please find the agenda below:

    ? Roll call
    ? Follow up on past action items
        ? No action items
    ? Gate health check
    ? OpenStack TC Charter Updates for OIF Foundation Simplification
        ? As discussed in the previous TC+Board syncup, the OpenInfra Foundation bylaws contain a lot of OpenStack specific language.
        ? Kristi, Gmann, and Brian have been meeting with Allison from the board to study the necessary changes to move that language to the charter.
        ? Bylaws changes and what all to go in the TC charter have been shared in an email. TC needs to provide the feedback before Sept 19.
    ? OpenStack Elections
        ? #link https://governance.openstack.org/election/
        ? #link https://review.opendev.org/c/openstack/election/+/893810
            ? Feedback from election officials regarding template for extra ACs.
    ? 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

From ygk.kmr at gmail.com  Tue Sep 12 12:00:19 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Tue, 12 Sep 2023 17:30:19 +0530
Subject: Nova conductor errors
In-Reply-To: <CAPd_6AvWMaZRpyatSV8u4W6vc8ifFPjXHvJ2-3MK_5eNDtrAeg@mail.gmail.com>
References: <CAJreVFwEoc4wKrF4wi-pj9unaod9yx0b71ZfY741e6Ldjhb8jg@mail.gmail.com>
 <CAPd_6Asse6+FwgB4=JB7p5UrQPAppukYTBHL=NVTCLamKOMhOg@mail.gmail.com>
 <3ccbca93cb9e0178af2c5ea054fea43800ff79e5.camel@redhat.com>
 <CAJreVFwMFAFmwbiTbCr49uAwoRgmy-e6FKtdTBe8_Ue_ZmPNyQ@mail.gmail.com>
 <CAPd_6AvWMaZRpyatSV8u4W6vc8ifFPjXHvJ2-3MK_5eNDtrAeg@mail.gmail.com>
Message-ID: <CAJreVFwg_kvgJ_bgLgLyahVyHFKuhF-CdKw0LZsjDmZQDT2PxA@mail.gmail.com>

Does this statement "nova_oslomsg_heartbeat_in_pthread: False"  go into
nova.conf of the nova-api container ?

On Tue, Sep 12, 2023 at 3:20?PM Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
wrote:

> As I said, add "nova_oslomsg_heartbeat_in_pthread: False" to
> user_variables and re-run os-nova-install.yml
>
> On Tue, Sep 12, 2023, 11:29 Gk Gk <ygk.kmr at gmail.com> wrote:
>
>> So, for the moment, how to proceed as a workaround  ?
>>
>> On Tue, Sep 12, 2023 at 2:39?PM <smooney at redhat.com> wrote:
>>
>>> On Tue, 2023-09-12 at 09:34 +0200, Dmitriy Rabotyagov wrote:
>>> > Hey,
>>> >
>>> > We are aware of this issue happening on compute nodes, when some
>>> > instances have a lot of volumes attached. For this purpose we define
>>> > following variable:
>>> >
>>> > nova_compute_init_overrides:
>>> >   Service:
>>> >     LimitNOFILE: 4096
>>> >
>>> > Same thing happening on nova-conductor makes me think of this bug
>>> > related to heartbeat_in_pthread change[1][2].
>>> the heat beat in pthread is only intented to be used in the api and it
>>> activly
>>> breaks the nova-compute agent. i suspect its also not a good idea to
>>> have enabled
>>> for the conducotr or scheduler as i expect that to behave like the
>>> compute agent.
>>> >  IIRC, it was also able
>>> > to leak file descriptors, that you can see as "Too many open files"
>>> > error.
>>> > Though bugfixes were backported to Yoga from what I see. But you can
>>> > try adding "nova_oslomsg_heartbeat_in_pthread: False" to your
>>> > user_variables and re-run os-nova-install.yml playbook.
>>> if osa is enabling the heartbeat_in_pthread on the conductor or anything
>>> other the the api and metadata its a bug  in osa
>>> >
>>> > [1] https://bugs.launchpad.net/openstack-ansible/+bug/1961603
>>> > [2] https://bugs.launchpad.net/oslo.messaging/+bug/1949964
>>> >
>>> >
>>> > ??, 12 ????. 2023??. ? 05:58, Gk Gk <ygk.kmr at gmail.com>:
>>> > >
>>> > > Hi All,
>>> > >
>>> > > We have a Yoga OSA setup. We have been observing the following
>>> errors in the nova conductor service intermittently.
>>> > > After a restart of the service, they seem to disappear. The logs are
>>> as follows:
>>> > >
>>> > > ---
>>> > > nova-conductor[3199409]:  ERROR oslo.messaging._drivers.impl_rabbit
>>> [-] Connection failed: [Errno 24] Too many open
>>> > > files (retrying in 0 seconds): OSError: [Errno 24] Too many open
>>> files
>>> > > ---
>>> > >
>>> > > Is it a known issue with yoga ? Please let me know.
>>> > >
>>> > >
>>> > > Thanks
>>> > > Y.G
>>> >
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/eda2203c/attachment.htm>

From jon at csail.mit.edu  Tue Sep 12 12:18:43 2023
From: jon at csail.mit.edu (Jonathan Proulx)
Date: Tue, 12 Sep 2023 08:18:43 -0400
Subject: [kolla-ansible] haproxy tls key location
Message-ID: <20230912121843.fp7q6g6iun2dqswp@csail.mit.edu>

Hi All,

Reading through https://docs.openstack.org/kolla-ansible/latest/admin/tls.html and global.yml / passwords.yml in my deploy  I see configuration for certificates but not where to set the key (though there is a key location configuration for backend tls in globals.yml).

Unsurprisingly when I put the certs where they are expected and enable
TLS the haproxy containers fail because they don't have a key.

What am I missing here?

Thanks,
-Jon

-- 
Jonathan Proulx (he/him)
Sr. Technical Architect
The Infrastructure Group
MIT CSAIL


From fungi at yuggoth.org  Tue Sep 12 12:37:53 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 12 Sep 2023 12:37:53 +0000
Subject: [kolla-ansible][horizon][policy][security-sig] Domain admins
In-Reply-To: <CA+_ZFmHMwibuC010TT-FnEJQRZduh-SRe=2xa9pSWvMPbafssg@mail.gmail.com>
References: <CA+_ZFmHMwibuC010TT-FnEJQRZduh-SRe=2xa9pSWvMPbafssg@mail.gmail.com>
Message-ID: <20230912123753.v4hfcet2yi54lvjm@yuggoth.org>

On 2023-09-11 21:02:06 -0500 (-0500), James Leong wrote:
> I am currently having a yoga version openstack. I noticed that
> user from a domain are able to view other domain leases if they
> are having admin role. Is there any possible way to change
> anything in the policy file? I have tried to add rule:owner but it
> didn't work out the way I wanted. Any recommendations would be
> appreciated.

What specifically were you trying to accomplish by granting admin
access to a domain user? While Keystone (the identity management
service) does have a concept of domain and project administrators
separate from system administrators, not all services in OpenStack
have implemented consistent support for this differentiation.

There is a community-wide goal[*] in progress to bring more
consistency to the RBAC implementation across services, but until
that is completed there are services where, for historical reasons,
the "admin" role means full service administrator access even if
it's associated with a project[**]. We could probably do a better
job of putting up warnings about this in obvious, discoverable
locations since even I had a hard time just now tracking down any
clear statement about the present state of these risks.

[*] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
[**] https://launchpad.net/bugs/1933269
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/3ce889fd/attachment.sig>

From emccormick at cirrusseven.com  Tue Sep 12 13:47:14 2023
From: emccormick at cirrusseven.com (Erik McCormick)
Date: Tue, 12 Sep 2023 09:47:14 -0400
Subject: [kolla-ansible] haproxy tls key location
In-Reply-To: <20230912121843.fp7q6g6iun2dqswp@csail.mit.edu>
References: <20230912121843.fp7q6g6iun2dqswp@csail.mit.edu>
Message-ID: <CAHUi5cPJHxCENRt4Pt-0Op8UO7YvenPTKXFbLDjEV7yrSSDqzg@mail.gmail.com>

On Tue, Sep 12, 2023 at 8:20?AM Jonathan Proulx <jon at csail.mit.edu> wrote:

> Hi All,
>
> Reading through
> https://docs.openstack.org/kolla-ansible/latest/admin/tls.html and
> global.yml / passwords.yml in my deploy  I see configuration for
> certificates but not where to set the key (though there is a key location
> configuration for backend tls in globals.yml).
>
> Unsurprisingly when I put the certs where they are expected and enable
> TLS the haproxy containers fail because they don't have a key.
>
> What am I missing here?
>
>
HAProxy likes to put everything in one file. concatenate your key onto the
end of your certificate chain.

-Erik

>
> Thanks,
> -Jon
>
> --
> Jonathan Proulx (he/him)
> Sr. Technical Architect
> The Infrastructure Group
> MIT CSAIL
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/70fb1eac/attachment.htm>

From noonedeadpunk at gmail.com  Tue Sep 12 13:49:22 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 12 Sep 2023 15:49:22 +0200
Subject: Nova conductor errors
In-Reply-To: <CAJreVFwg_kvgJ_bgLgLyahVyHFKuhF-CdKw0LZsjDmZQDT2PxA@mail.gmail.com>
References: <CAJreVFwEoc4wKrF4wi-pj9unaod9yx0b71ZfY741e6Ldjhb8jg@mail.gmail.com>
 <CAPd_6Asse6+FwgB4=JB7p5UrQPAppukYTBHL=NVTCLamKOMhOg@mail.gmail.com>
 <3ccbca93cb9e0178af2c5ea054fea43800ff79e5.camel@redhat.com>
 <CAJreVFwMFAFmwbiTbCr49uAwoRgmy-e6FKtdTBe8_Ue_ZmPNyQ@mail.gmail.com>
 <CAPd_6AvWMaZRpyatSV8u4W6vc8ifFPjXHvJ2-3MK_5eNDtrAeg@mail.gmail.com>
 <CAJreVFwg_kvgJ_bgLgLyahVyHFKuhF-CdKw0LZsjDmZQDT2PxA@mail.gmail.com>
Message-ID: <CAPd_6AsJdMxBAEt4U_zMbLYu6UvSzzU1vLCaZE-P+CVLgET2aw@mail.gmail.com>

It goes to /etc/openstack_deploy/user_variables.yml

On Tue, Sep 12, 2023, 14:00 Gk Gk <ygk.kmr at gmail.com> wrote:

> Does this statement "nova_oslomsg_heartbeat_in_pthread: False"  go into
> nova.conf of the nova-api container ?
>
> On Tue, Sep 12, 2023 at 3:20?PM Dmitriy Rabotyagov <
> noonedeadpunk at gmail.com> wrote:
>
>> As I said, add "nova_oslomsg_heartbeat_in_pthread: False" to
>> user_variables and re-run os-nova-install.yml
>>
>> On Tue, Sep 12, 2023, 11:29 Gk Gk <ygk.kmr at gmail.com> wrote:
>>
>>> So, for the moment, how to proceed as a workaround  ?
>>>
>>> On Tue, Sep 12, 2023 at 2:39?PM <smooney at redhat.com> wrote:
>>>
>>>> On Tue, 2023-09-12 at 09:34 +0200, Dmitriy Rabotyagov wrote:
>>>> > Hey,
>>>> >
>>>> > We are aware of this issue happening on compute nodes, when some
>>>> > instances have a lot of volumes attached. For this purpose we define
>>>> > following variable:
>>>> >
>>>> > nova_compute_init_overrides:
>>>> >   Service:
>>>> >     LimitNOFILE: 4096
>>>> >
>>>> > Same thing happening on nova-conductor makes me think of this bug
>>>> > related to heartbeat_in_pthread change[1][2].
>>>> the heat beat in pthread is only intented to be used in the api and it
>>>> activly
>>>> breaks the nova-compute agent. i suspect its also not a good idea to
>>>> have enabled
>>>> for the conducotr or scheduler as i expect that to behave like the
>>>> compute agent.
>>>> >  IIRC, it was also able
>>>> > to leak file descriptors, that you can see as "Too many open files"
>>>> > error.
>>>> > Though bugfixes were backported to Yoga from what I see. But you can
>>>> > try adding "nova_oslomsg_heartbeat_in_pthread: False" to your
>>>> > user_variables and re-run os-nova-install.yml playbook.
>>>> if osa is enabling the heartbeat_in_pthread on the conductor or anything
>>>> other the the api and metadata its a bug  in osa
>>>> >
>>>> > [1] https://bugs.launchpad.net/openstack-ansible/+bug/1961603
>>>> > [2] https://bugs.launchpad.net/oslo.messaging/+bug/1949964
>>>> >
>>>> >
>>>> > ??, 12 ????. 2023??. ? 05:58, Gk Gk <ygk.kmr at gmail.com>:
>>>> > >
>>>> > > Hi All,
>>>> > >
>>>> > > We have a Yoga OSA setup. We have been observing the following
>>>> errors in the nova conductor service intermittently.
>>>> > > After a restart of the service, they seem to disappear. The logs
>>>> are as follows:
>>>> > >
>>>> > > ---
>>>> > > nova-conductor[3199409]:  ERROR oslo.messaging._drivers.impl_rabbit
>>>> [-] Connection failed: [Errno 24] Too many open
>>>> > > files (retrying in 0 seconds): OSError: [Errno 24] Too many open
>>>> files
>>>> > > ---
>>>> > >
>>>> > > Is it a known issue with yoga ? Please let me know.
>>>> > >
>>>> > >
>>>> > > Thanks
>>>> > > Y.G
>>>> >
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/31fcf374/attachment-0001.htm>

From Danny.Webb at thehutgroup.com  Tue Sep 12 13:52:30 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Tue, 12 Sep 2023 13:52:30 +0000
Subject: [kolla-ansible] haproxy tls key location
In-Reply-To: <20230912121843.fp7q6g6iun2dqswp@csail.mit.edu>
References: <20230912121843.fp7q6g6iun2dqswp@csail.mit.edu>
Message-ID: <LO2P265MB577392C2A20E60FE827633B79AF1A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

You create a single file with both certificate and key in it.
________________________________
From: Jonathan Proulx <jon at csail.mit.edu>
Sent: 12 September 2023 13:18
To: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla-ansible] haproxy tls key location

CAUTION: This email originates from outside THG

Hi All,

Reading through https://docs.openstack.org/kolla-ansible/latest/admin/tls.html<https://docs.openstack.org/kolla-ansible/latest/admin/tls.html> and global.yml / passwords.yml in my deploy I see configuration for certificates but not where to set the key (though there is a key location configuration for backend tls in globals.yml).

Unsurprisingly when I put the certs where they are expected and enable
TLS the haproxy containers fail because they don't have a key.

What am I missing here?

Thanks,
-Jon

--
Jonathan Proulx (he/him)
Sr. Technical Architect
The Infrastructure Group
MIT CSAIL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/06b6499b/attachment.htm>

From jon at csail.mit.edu  Tue Sep 12 13:58:06 2023
From: jon at csail.mit.edu (Jonathan Proulx)
Date: Tue, 12 Sep 2023 09:58:06 -0400
Subject: [kolla-ansible] haproxy tls key location
In-Reply-To: <CAHUi5cPJHxCENRt4Pt-0Op8UO7YvenPTKXFbLDjEV7yrSSDqzg@mail.gmail.com>
References: <20230912121843.fp7q6g6iun2dqswp@csail.mit.edu>
 <CAHUi5cPJHxCENRt4Pt-0Op8UO7YvenPTKXFbLDjEV7yrSSDqzg@mail.gmail.com>
Message-ID: <20230912135806.dxfpkf5hign6ocl4@csail.mit.edu>

On Tue, Sep 12, 2023 at 09:47:14AM -0400, Erik McCormick wrote:

:HAProxy likes to put everything in one file. concatenate your key onto the
:end of your certificate chain.

Ah yes the many flavors of "cert"...thanks again Erik.

-Jon


From nguyenhuukhoinw at gmail.com  Tue Sep 12 12:19:00 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 12 Sep 2023 19:19:00 +0700
Subject: [openstack][skyline] Some works with skyline
Message-ID: <CABAODRcqw1xhfaue-XGWthxxaHi_z6KSdxEb3qg=qB6X1FmHbw@mail.gmail.com>

Hello guys.
I am working on Skyline.

I can integrate my monitor tab on it.

I will try to do something about it. If it works properly, I can contribute.

It is a very nice project. I hope it will grow and grow in the future.

Thanks Skyline Team.


[image: image.png]

Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/fbc22431/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 248643 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230912/fbc22431/attachment-0001.png>

From satish.txt at gmail.com  Tue Sep 12 23:52:54 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 12 Sep 2023 19:52:54 -0400
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CABAODRcqw1xhfaue-XGWthxxaHi_z6KSdxEb3qg=qB6X1FmHbw@mail.gmail.com>
References: <CABAODRcqw1xhfaue-XGWthxxaHi_z6KSdxEb3qg=qB6X1FmHbw@mail.gmail.com>
Message-ID: <DC63C6C5-9247-4893-A023-52EA00E1E2AB@gmail.com>

Damn! How did you interstate monitoring? I would like to give it a try.

Agreed, skyline is really good addition to openstack cloud. 

Sent from my iPhone

> On Sep 12, 2023, at 11:38 AM, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
> 
> ?
> Hello guys.
> I am working on Skyline. 
> 
> I can integrate my monitor tab on it. 
> 
> I will try to do something about it. If it works properly, I can contribute.
> 
> It is a very nice project. I hope it will grow and grow in the future.
> 
> Thanks Skyline Team.
> 
> 
> <image.png>
> 
> 
> Nguyen Huu Khoi


From nguyenhuukhoinw at gmail.com  Wed Sep 13 00:08:19 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 13 Sep 2023 07:08:19 +0700
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <DC63C6C5-9247-4893-A023-52EA00E1E2AB@gmail.com>
References: <CABAODRcqw1xhfaue-XGWthxxaHi_z6KSdxEb3qg=qB6X1FmHbw@mail.gmail.com>
 <DC63C6C5-9247-4893-A023-52EA00E1E2AB@gmail.com>
Message-ID: <CABAODRcG9zrjzKTCShwTXmN3Q5rdW2ibyZh7K66s_MhN9zZ-eA@mail.gmail.com>

Nguyen Huu Khoi
Hello. I just read skyline source code and followed it about data source.
This is https://github.com/zhangjianweibj/prometheus-libvirt-exporter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230913/2bf75374/attachment.htm>

From zigo at debian.org  Wed Sep 13 07:21:18 2023
From: zigo at debian.org (Thomas Goirand)
Date: Wed, 13 Sep 2023 09:21:18 +0200
Subject: [all] SQLAlchemy 2.x support in Bobcat
Message-ID: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>

Hi,

As you may know, and to my great frustration, I'm not the maintainer of 
SQLAlchemy in Debian, even though OpenStack is the biggest consumer of 
it. The current maintainer insists that he wants to upload SQLA 2.x in 
Unstable, potentially breaking all of OpenStack.

At the present moment, if I understand correctly, we're not there yet, 
and Bobcat doesn't have such a support. It would be ok for me, *IF* 
there are patches available on master, that I could backport to Bobcat 
and maintain in the debian/patches folder of each project. However, the 
biggest current annoyance, is that I have no idea where we are at. Are 
we close to such a support? Is there a list of patches to apply on top 
of Bobcat that is maintained somewhere?

Please enlighten me... :)

Cheers,

Thomas Goirand (zigo)


From katonalala at gmail.com  Wed Sep 13 11:57:49 2023
From: katonalala at gmail.com (Lajos Katona)
Date: Wed, 13 Sep 2023 13:57:49 +0200
Subject: [all] SQLAlchemy 2.x support in Bobcat
In-Reply-To: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
Message-ID: <CALg0jKm3judavq8t-1eva9fpWhuNWQ1vVX_WJdSW5gM-EH=06g@mail.gmail.com>

Hi,
Neutron projects are tested in Bobcat with sqlalchemy 2 (actually with the
main branch), so I would not expect big issues (?) (bagpipe was the last
project with serious failures and it is green in the last week)
My understanding was that Openstackwise we bump sqlalchemy with
starting Caracal, see:
https://review.opendev.org/c/openstack/requirements/+/879743

BUT: based on some discussions ie:
https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2023-09-12.log.html#t2023-09-12T16:37:08
I have doubts that it will happen.

Lajos

Thomas Goirand <zigo at debian.org> ezt ?rta (id?pont: 2023. szept. 13., Sze,
10:22):

> Hi,
>
> As you may know, and to my great frustration, I'm not the maintainer of
> SQLAlchemy in Debian, even though OpenStack is the biggest consumer of
> it. The current maintainer insists that he wants to upload SQLA 2.x in
> Unstable, potentially breaking all of OpenStack.
>
> At the present moment, if I understand correctly, we're not there yet,
> and Bobcat doesn't have such a support. It would be ok for me, *IF*
> there are patches available on master, that I could backport to Bobcat
> and maintain in the debian/patches folder of each project. However, the
> biggest current annoyance, is that I have no idea where we are at. Are
> we close to such a support? Is there a list of patches to apply on top
> of Bobcat that is maintained somewhere?
>
> Please enlighten me... :)
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230913/37ad5529/attachment.htm>

From stephenfin at redhat.com  Wed Sep 13 13:39:47 2023
From: stephenfin at redhat.com (Stephen Finucane)
Date: Wed, 13 Sep 2023 14:39:47 +0100
Subject: [all] SQLAlchemy 2.x support in Bobcat
In-Reply-To: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
Message-ID: <dc035bef4b93d0048aacad02aa08bf4b4ecf1a34.camel@redhat.com>

On Wed, 2023-09-13 at 09:21 +0200, Thomas Goirand wrote:
> Hi,
> 
> As you may know, and to my great frustration, I'm not the maintainer of 
> SQLAlchemy in Debian, even though OpenStack is the biggest consumer of 
> it. The current maintainer insists that he wants to upload SQLA 2.x in 
> Unstable, potentially breaking all of OpenStack.
> 
> At the present moment, if I understand correctly, we're not there yet, 
> and Bobcat doesn't have such a support. It would be ok for me, *IF* 
> there are patches available on master, that I could backport to Bobcat 
> and maintain in the debian/patches folder of each project. However, the 
> biggest current annoyance, is that I have no idea where we are at. Are 
> we close to such a support? Is there a list of patches to apply on top 
> of Bobcat that is maintained somewhere?
> 
> Please enlighten me... :)

I think you figured this out on IRC this morning, but the vast majority (though
not all) of the patches are available at the sqlalchemy-20 topic in Gerrit [1].
I've been working on this for almost 2 years now and have most of the core
projects well on their way but not everything is complete, as you'll tell from
that list. I have a canary patch [2] that I've been using to spot missing
services. I plan to pick up the Manila work again early in C, but could do with
help removing the use of autocommit in Heat and the weird test failures I'm
seeing in Cinder [3]. We also need reviews of the Masakri series (Is that
project dead? I can't tell). Once those are addressed, I _think_ we might be
done but who knows what else we'll find...

Cheers,
Stephen

[1] https://review.opendev.org/q/topic:sqlalchemy-20+is:open
[2] https://review.opendev.org/c/openstack/requirements/+/879743
[3] https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder

> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 



From tobias.urdin at binero.com  Wed Sep 13 14:11:59 2023
From: tobias.urdin at binero.com (Tobias Urdin)
Date: Wed, 13 Sep 2023 14:11:59 +0000
Subject: [all] SQLAlchemy 2.x support in Bobcat
In-Reply-To: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
Message-ID: <16B5B611-5558-40C0-98CB-389E4E81C424@binero.com>

Hello,
I did Gnocchi recently and it?s available in the new 4.6.0 release.

I don?t envy you if you have to backport every single patch, those are hundred of patches layered on-top of each
other and then probably some standalone fixes here and there across the entire ecosystem.

I hope you will fight the maintainer because that doesn?t sound fun :(

Best regards
Tobias


> On 13 Sep 2023, at 09:21, Thomas Goirand <zigo at debian.org> wrote:
> 
> Hi,
> 
> As you may know, and to my great frustration, I'm not the maintainer of SQLAlchemy in Debian, even though OpenStack is the biggest consumer of it. The current maintainer insists that he wants to upload SQLA 2.x in Unstable, potentially breaking all of OpenStack.
> 
> At the present moment, if I understand correctly, we're not there yet, and Bobcat doesn't have such a support. It would be ok for me, *IF* there are patches available on master, that I could backport to Bobcat and maintain in the debian/patches folder of each project. However, the biggest current annoyance, is that I have no idea where we are at. Are we close to such a support? Is there a list of patches to apply on top of Bobcat that is maintained somewhere?
> 
> Please enlighten me... :)
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 


From jobernar at redhat.com  Wed Sep 13 14:15:07 2023
From: jobernar at redhat.com (Jon Bernard)
Date: Wed, 13 Sep 2023 14:15:07 +0000
Subject: Cinder Bug Report 2023-09-13
Message-ID: <ZQHD6zZVWRbnkpkM@localhost>

Hello Argonauts,

Cinder Bug Meeting Etherpad
<https://etherpad.opendev.org/p/cinder-bug-squad-meeting>

Undecided

- Fail to migrate, resize, evacuate VM with volume state backing-up
  <https://bugs.launchpad.net/cinder/+bug/2034677>
  - Status: New

- Dell PowerMax Live Migration Fails Without a Pool Name
  <https://bugs.launchpad.net/cinder/+bug/2034937>
  - Status: New

- Cinder Backups Fail with cinder.exception.ServiceNotFound with multiple availibility zones
  <https://bugs.launchpad.net/cinder/+bug/2035007>
  - Status: New

- Dell PowerFlex (Scaleio) connector doesn't handle volume disconnection/unmapping properly
  <https://bugs.launchpad.net/os-brick/+bug/2034685>
  - Status: New

Thanks,

-- 
Jon



From nguyenhuukhoinw at gmail.com  Wed Sep 13 16:09:14 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 13 Sep 2023 23:09:14 +0700
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CAPgF-fq5drfhO5q9bQJhphJzcYFCCDw2S1q_dMzDd6JxGVO5TQ@mail.gmail.com>
References: <CABAODRcG9zrjzKTCShwTXmN3Q5rdW2ibyZh7K66s_MhN9zZ-eA@mail.gmail.com>
 <7E26F394-AA89-4A3A-98F5-ED84951E50F3@gmail.com>
 <CABAODRd4dkhiM+H3=qDh1URSKUq+RmVUzJTo157SaMqvagnW7Q@mail.gmail.com>
 <CAPgF-fq5drfhO5q9bQJhphJzcYFCCDw2S1q_dMzDd6JxGVO5TQ@mail.gmail.com>
Message-ID: <CABAODRdyY=xtefa8rtCRcfbj1M9BuqUFboFz+8T0fjnbo07hQA@mail.gmail.com>

Hello.
The case is here,
https://github.com/openstack/skyline-console/blob/master/src/pages/compute/containers/Instance/Detail/index.jsx

but you need to understand how skyline construct page. This project uses
nodejs, I use the chart.js library to code. it will need some knowledge
about api and javascript.

Let's read first.


Nguyen Huu Khoi


On Wed, Sep 13, 2023 at 7:29?PM Satish Patel <satish.txt at gmail.com> wrote:

> Sure that is ok. Can you give me a small hit about what you actually
> did? I can see you created a new tab 'monitor' but behind that did you
> create a new css theme etc to pull metrics from prometheus?
>
> All I want to do is just to see if it's worth it because we don't have
> prometheus but we have different data sources which I can integrate. Thanks
> for the work. very appreciated.
>
> On Wed, Sep 13, 2023 at 7:27?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello. Bc i am just working. And I am not dev so I still learn. If it is
>> ok then i will do.
>>
>> On Wed, Sep 13, 2023, 6:17 PM Satish Patel <satish.txt at gmail.com> wrote:
>>
>>> That is great!!
>>>
>>> I?m not a developer but will try to read the code but it would be good
>>> if you just give me file name or clue about where to look.
>>>
>>> If you have patch or diff would be great. Why don?t you contribute this
>>> feature and submit a patch
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 12, 2023, at 8:08 PM, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>>> wrote:
>>>
>>> ?
>>>
>>> Nguyen Huu Khoi
>>> Hello. I just read skyline source code and followed it about data
>>> source. This is
>>> https://github.com/zhangjianweibj/prometheus-libvirt-exporter.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230913/b04a22d0/attachment.htm>

From satish.txt at gmail.com  Wed Sep 13 16:21:28 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 13 Sep 2023 12:21:28 -0400
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CABAODRdyY=xtefa8rtCRcfbj1M9BuqUFboFz+8T0fjnbo07hQA@mail.gmail.com>
References: <CABAODRcG9zrjzKTCShwTXmN3Q5rdW2ibyZh7K66s_MhN9zZ-eA@mail.gmail.com>
 <7E26F394-AA89-4A3A-98F5-ED84951E50F3@gmail.com>
 <CABAODRd4dkhiM+H3=qDh1URSKUq+RmVUzJTo157SaMqvagnW7Q@mail.gmail.com>
 <CAPgF-fq5drfhO5q9bQJhphJzcYFCCDw2S1q_dMzDd6JxGVO5TQ@mail.gmail.com>
 <CABAODRdyY=xtefa8rtCRcfbj1M9BuqUFboFz+8T0fjnbo07hQA@mail.gmail.com>
Message-ID: <CAPgF-fr6RunZqq878KVs1jeuOwQyKp-g7VYxKdgohBkLg5RnMQ@mail.gmail.com>

Thank you!

Then what is the deal here? This thread says just add prometheus config and
magic will happen.

https://bugs.launchpad.net/skyline-apiserver/+bug/2002902

On Wed, Sep 13, 2023 at 12:09?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello.
> The case is here,
>
> https://github.com/openstack/skyline-console/blob/master/src/pages/compute/containers/Instance/Detail/index.jsx
>
> but you need to understand how skyline construct page. This project uses
> nodejs, I use the chart.js library to code. it will need some knowledge
> about api and javascript.
>
> Let's read first.
>
>
> Nguyen Huu Khoi
>
>
> On Wed, Sep 13, 2023 at 7:29?PM Satish Patel <satish.txt at gmail.com> wrote:
>
>> Sure that is ok. Can you give me a small hit about what you actually
>> did? I can see you created a new tab 'monitor' but behind that did you
>> create a new css theme etc to pull metrics from prometheus?
>>
>> All I want to do is just to see if it's worth it because we don't have
>> prometheus but we have different data sources which I can integrate. Thanks
>> for the work. very appreciated.
>>
>> On Wed, Sep 13, 2023 at 7:27?AM Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com> wrote:
>>
>>> Hello. Bc i am just working. And I am not dev so I still learn. If it is
>>> ok then i will do.
>>>
>>> On Wed, Sep 13, 2023, 6:17 PM Satish Patel <satish.txt at gmail.com> wrote:
>>>
>>>> That is great!!
>>>>
>>>> I?m not a developer but will try to read the code but it would be good
>>>> if you just give me file name or clue about where to look.
>>>>
>>>> If you have patch or diff would be great. Why don?t you contribute this
>>>> feature and submit a patch
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Sep 12, 2023, at 8:08 PM, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>>>> wrote:
>>>>
>>>> ?
>>>>
>>>> Nguyen Huu Khoi
>>>> Hello. I just read skyline source code and followed it about data
>>>> source. This is
>>>> https://github.com/zhangjianweibj/prometheus-libvirt-exporter.
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230913/6fb85ea2/attachment-0001.htm>

From nguyenhuukhoinw at gmail.com  Wed Sep 13 17:00:20 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Thu, 14 Sep 2023 00:00:20 +0700
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CAPgF-fr6RunZqq878KVs1jeuOwQyKp-g7VYxKdgohBkLg5RnMQ@mail.gmail.com>
References: <CABAODRcG9zrjzKTCShwTXmN3Q5rdW2ibyZh7K66s_MhN9zZ-eA@mail.gmail.com>
 <7E26F394-AA89-4A3A-98F5-ED84951E50F3@gmail.com>
 <CABAODRd4dkhiM+H3=qDh1URSKUq+RmVUzJTo157SaMqvagnW7Q@mail.gmail.com>
 <CAPgF-fq5drfhO5q9bQJhphJzcYFCCDw2S1q_dMzDd6JxGVO5TQ@mail.gmail.com>
 <CABAODRdyY=xtefa8rtCRcfbj1M9BuqUFboFz+8T0fjnbo07hQA@mail.gmail.com>
 <CAPgF-fr6RunZqq878KVs1jeuOwQyKp-g7VYxKdgohBkLg5RnMQ@mail.gmail.com>
Message-ID: <CABAODRcdUB+WHqwcqxw-ZhvSX2HN3JmW38B4zWD3JU=WTimqww@mail.gmail.com>

Hello.
It talks about node monitor. Which I am doing about instance monitoring.
You can check on Administrator Page >>> Monitor Center.
Nguyen Huu Khoi


On Wed, Sep 13, 2023 at 11:21?PM Satish Patel <satish.txt at gmail.com> wrote:

> Thank you!
>
> Then what is the deal here? This thread says just add prometheus config
> and magic will happen.
>
> https://bugs.launchpad.net/skyline-apiserver/+bug/2002902
>
> On Wed, Sep 13, 2023 at 12:09?PM Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com> wrote:
>
>> Hello.
>> The case is here,
>>
>> https://github.com/openstack/skyline-console/blob/master/src/pages/compute/containers/Instance/Detail/index.jsx
>>
>> but you need to understand how skyline construct page. This project uses
>> nodejs, I use the chart.js library to code. it will need some knowledge
>> about api and javascript.
>>
>> Let's read first.
>>
>>
>> Nguyen Huu Khoi
>>
>>
>> On Wed, Sep 13, 2023 at 7:29?PM Satish Patel <satish.txt at gmail.com>
>> wrote:
>>
>>> Sure that is ok. Can you give me a small hit about what you actually
>>> did? I can see you created a new tab 'monitor' but behind that did you
>>> create a new css theme etc to pull metrics from prometheus?
>>>
>>> All I want to do is just to see if it's worth it because we don't have
>>> prometheus but we have different data sources which I can integrate. Thanks
>>> for the work. very appreciated.
>>>
>>> On Wed, Sep 13, 2023 at 7:27?AM Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com> wrote:
>>>
>>>> Hello. Bc i am just working. And I am not dev so I still learn. If it
>>>> is ok then i will do.
>>>>
>>>> On Wed, Sep 13, 2023, 6:17 PM Satish Patel <satish.txt at gmail.com>
>>>> wrote:
>>>>
>>>>> That is great!!
>>>>>
>>>>> I?m not a developer but will try to read the code but it would be good
>>>>> if you just give me file name or clue about where to look.
>>>>>
>>>>> If you have patch or diff would be great. Why don?t you contribute
>>>>> this feature and submit a patch
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Sep 12, 2023, at 8:08 PM, Nguy?n H?u Kh?i <
>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>
>>>>> ?
>>>>>
>>>>> Nguyen Huu Khoi
>>>>> Hello. I just read skyline source code and followed it about data
>>>>> source. This is
>>>>> https://github.com/zhangjianweibj/prometheus-libvirt-exporter.
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/48821c6a/attachment.htm>

From satish.txt at gmail.com  Wed Sep 13 18:22:47 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 13 Sep 2023 14:22:47 -0400
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CABAODRcdUB+WHqwcqxw-ZhvSX2HN3JmW38B4zWD3JU=WTimqww@mail.gmail.com>
References: <CABAODRcG9zrjzKTCShwTXmN3Q5rdW2ibyZh7K66s_MhN9zZ-eA@mail.gmail.com>
 <7E26F394-AA89-4A3A-98F5-ED84951E50F3@gmail.com>
 <CABAODRd4dkhiM+H3=qDh1URSKUq+RmVUzJTo157SaMqvagnW7Q@mail.gmail.com>
 <CAPgF-fq5drfhO5q9bQJhphJzcYFCCDw2S1q_dMzDd6JxGVO5TQ@mail.gmail.com>
 <CABAODRdyY=xtefa8rtCRcfbj1M9BuqUFboFz+8T0fjnbo07hQA@mail.gmail.com>
 <CAPgF-fr6RunZqq878KVs1jeuOwQyKp-g7VYxKdgohBkLg5RnMQ@mail.gmail.com>
 <CABAODRcdUB+WHqwcqxw-ZhvSX2HN3JmW38B4zWD3JU=WTimqww@mail.gmail.com>
Message-ID: <CAPgF-frzTeGmehyDN6K0ucjcsbb3a3RDFST+3MDQWzTa0P3Zkw@mail.gmail.com>

Hi,

Assuming instance monitoring also calls prometheus api or query to get
specific matrices for instance.

On Wed, Sep 13, 2023 at 1:00?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello.
> It talks about node monitor. Which I am doing about instance monitoring.
> You can check on Administrator Page >>> Monitor Center.
> Nguyen Huu Khoi
>
>
> On Wed, Sep 13, 2023 at 11:21?PM Satish Patel <satish.txt at gmail.com>
> wrote:
>
>> Thank you!
>>
>> Then what is the deal here? This thread says just add prometheus config
>> and magic will happen.
>>
>> https://bugs.launchpad.net/skyline-apiserver/+bug/2002902
>>
>> On Wed, Sep 13, 2023 at 12:09?PM Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com> wrote:
>>
>>> Hello.
>>> The case is here,
>>>
>>> https://github.com/openstack/skyline-console/blob/master/src/pages/compute/containers/Instance/Detail/index.jsx
>>>
>>> but you need to understand how skyline construct page. This project uses
>>> nodejs, I use the chart.js library to code. it will need some knowledge
>>> about api and javascript.
>>>
>>> Let's read first.
>>>
>>>
>>> Nguyen Huu Khoi
>>>
>>>
>>> On Wed, Sep 13, 2023 at 7:29?PM Satish Patel <satish.txt at gmail.com>
>>> wrote:
>>>
>>>> Sure that is ok. Can you give me a small hit about what you actually
>>>> did? I can see you created a new tab 'monitor' but behind that did you
>>>> create a new css theme etc to pull metrics from prometheus?
>>>>
>>>> All I want to do is just to see if it's worth it because we don't have
>>>> prometheus but we have different data sources which I can integrate. Thanks
>>>> for the work. very appreciated.
>>>>
>>>> On Wed, Sep 13, 2023 at 7:27?AM Nguy?n H?u Kh?i <
>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>
>>>>> Hello. Bc i am just working. And I am not dev so I still learn. If it
>>>>> is ok then i will do.
>>>>>
>>>>> On Wed, Sep 13, 2023, 6:17 PM Satish Patel <satish.txt at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> That is great!!
>>>>>>
>>>>>> I?m not a developer but will try to read the code but it would be
>>>>>> good if you just give me file name or clue about where to look.
>>>>>>
>>>>>> If you have patch or diff would be great. Why don?t you contribute
>>>>>> this feature and submit a patch
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Sep 12, 2023, at 8:08 PM, Nguy?n H?u Kh?i <
>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Nguyen Huu Khoi
>>>>>> Hello. I just read skyline source code and followed it about data
>>>>>> source. This is
>>>>>> https://github.com/zhangjianweibj/prometheus-libvirt-exporter.
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230913/326d1f23/attachment.htm>

From satish.txt at gmail.com  Wed Sep 13 19:08:07 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 13 Sep 2023 15:08:07 -0400
Subject: [kolla-ansible][ovn] availability zone for OVN
In-Reply-To: <fc9e69232bd5516b41a083bc3829ba001efefc28.camel@redhat.com>
References: <CAPgF-fomCgpUMbJpfx9DyoPiHoW=yYOygk-SptCrx1KxHabR3Q@mail.gmail.com>
 <CAB1EZBoyLi5Z7d+QP6srr0HcTeOp6z_xHnv_MODq5x-CHhB8Vw@mail.gmail.com>
 <fc9e69232bd5516b41a083bc3829ba001efefc28.camel@redhat.com>
Message-ID: <CAPgF-frst-k3XtwUVH9SmMakO3EscgV9UK-nWnp9cTXs2f40Ew@mail.gmail.com>

Hi Sean,

Thanks for your input. I have an open bug report here to skyline. It would
be good if you add your point there for more visibility
https://bugs.launchpad.net/skyline-apiserver/+bug/2035012

On Mon, Sep 11, 2023 at 4:53?AM <smooney at redhat.com> wrote:

> On Sun, 2023-09-10 at 14:51 +0100, Lucas Alvares Gomes wrote:
> > On Sun, Sep 10, 2023 at 4:13?AM Satish Patel <satish.txt at gmail.com>
> wrote:
> > >
> > > Folks,
> > >
> > > I am trying to set an availability zone for OVN because skyline UI has
> a mandatory requirement to have an
> > > availability zone otherwise you are not allowed to create a network
> from skyline GUI.
> one thing that skiline and admin s to a lesser degree need to be aware of
> is that nova AZ, Neutron AZ and cinder AZ
> are generally not related to each other. you as an admin can align them
> but a enduser should not assume that
> when creating a vm with a netwok and a voluem that the name of the AZ for
> all 3 should be the same.
> AZs are also optional in all 3 servics that support them. nova invents a
> fake AZ called "nova" and puts all host
> that dont otherwise have an az in it but its considerd a bug to explictly
> request the nova az.
> we have debated makeing that a hard error in future api version although
> currently we do know that some people do
> reueqst the defautl nova az even though we document that you should not.
> https://docs.openstack.org/nova/latest/admin/availability-zones.html
> """
> The use of the default availability zone name in requests can be very
> error-prone. Since the user can see the list of
> availability zones, they have no way to know whether the default
> availability zone name (currently nova) is provided
> because a host belongs to an aggregate whose AZ metadata key is set to
> nova, or because there is at least one host not
> belonging to any aggregate. Consequently, it is highly recommended for
> users to never ever ask for booting an instance
> by specifying an explicit AZ named nova and for operators to never set the
> AZ metadata for an aggregate to nova. This
> can result is some problems due to the fact that the instance AZ
> information is explicitly attached to nova which could
> break further move operations when either the host is moved to another
> aggregate or when the user would like to migrate
> the instance.
> """
>
> i raise this because i would consider it a bug form a nova point of view
> if skyline forced you to specyify
> an az when booting a vm. i would also consider it a bug in skyline if it
> forced the same on neutron or cinder
> since they are an optional feature. even if its common to configure them
> the skyline ui should not force you to select
> one.
>
>
> > >
> > > for OVN based deployment only option to set AZ is in ovn-cms-options
> > >
> > > # ovs-vsctl set open_vswitch .
> external_ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0"
> > >
> > > Question:
> > >
> > > 1. How do I configure in kolla-ansible to override or set
> ovn-cms-options on only gateway chassis?
> > > 2. How does AZ work in OVN because OVN is anyway distributed as per
> documents, What if I just give foobar AZ name to
> > > meet Skyline requirement? Is it going to break anything?
> >
> > Answering 2.
> >
> > There are two types of availability zones in Neutron: Routers and
> Networks.
> >
> > For Routers, ML2/OVN will schedule the gateway router ports onto the
> > nodes belonging to the availability zones provided by the
> > --availability-zone-hint parameter, for example:
> >
> > $ openstack router create --availability-zone-hint az-0
> > --availability-zone-hint az-1 router-0
> >
> > For Networks. Since DHCP is distributed in ML2/OVN as you pointed out
> > we do not care about scheduling DHCP agents (like ML2/OVS). But there
> > are few cases for Network AZ in ML2/OVN that are related to external
> > ports [0], these are ports that live on a different host than the
> > instance to address use cases such as SR-IOV and Baremetal with
> > ML2/OVN.
> >
> > You can read more ML2/OVN AZs here:
> >
> https://docs.openstack.org/neutron/latest/admin/ovn/availability_zones.html
> >
> > [0]
> https://docs.openstack.org/neutron/latest/admin/ovn/external_ports.html
> >
> > Cheers,
> > Lucas
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230913/51ba16ba/attachment-0001.htm>

From rdhasman at redhat.com  Thu Sep 14 07:48:33 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 14 Sep 2023 13:18:33 +0530
Subject: [cinder][PTG] Cinder 2024.1 (Caracal) PTG Planning
Message-ID: <CAARK8KQCjoHW7DmwAdAWJ1SejgeaK1BRrbF=ZRsqpMz-BNyCmw@mail.gmail.com>

Hello All,

The 2024.1 (Caracal) virtual PTG is approaching and will be held between
23-27 October, 2023.
I've created a planning etherpad[1] and a PTG etherpad[2] to gather topics
for the PTG.
Note that you only need to add topics in the planning etherpad[1] and those
will be arranged
in the PTG etherpad[2] later.

Date: Tuesday (24th October) to Friday (27th October) 2023
Time: 1300-1700 UTC
Etherpad: https://etherpad.opendev.org/p/caracal-ptg-cinder-planning

Please add your topics timely so they can be arranged as per your
preferences, see you at the PTG!

[1] https://etherpad.opendev.org/p/caracal-ptg-cinder-planning
[2] https://etherpad.opendev.org/p/caracal-ptg-cinder

Thanks
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/8a2d5aac/attachment.htm>

From nguyenhuukhoinw at gmail.com  Thu Sep 14 09:07:59 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Thu, 14 Sep 2023 16:07:59 +0700
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CAPgF-frzTeGmehyDN6K0ucjcsbb3a3RDFST+3MDQWzTa0P3Zkw@mail.gmail.com>
References: <CABAODRcG9zrjzKTCShwTXmN3Q5rdW2ibyZh7K66s_MhN9zZ-eA@mail.gmail.com>
 <7E26F394-AA89-4A3A-98F5-ED84951E50F3@gmail.com>
 <CABAODRd4dkhiM+H3=qDh1URSKUq+RmVUzJTo157SaMqvagnW7Q@mail.gmail.com>
 <CAPgF-fq5drfhO5q9bQJhphJzcYFCCDw2S1q_dMzDd6JxGVO5TQ@mail.gmail.com>
 <CABAODRdyY=xtefa8rtCRcfbj1M9BuqUFboFz+8T0fjnbo07hQA@mail.gmail.com>
 <CAPgF-fr6RunZqq878KVs1jeuOwQyKp-g7VYxKdgohBkLg5RnMQ@mail.gmail.com>
 <CABAODRcdUB+WHqwcqxw-ZhvSX2HN3JmW38B4zWD3JU=WTimqww@mail.gmail.com>
 <CAPgF-frzTeGmehyDN6K0ucjcsbb3a3RDFST+3MDQWzTa0P3Zkw@mail.gmail.com>
Message-ID: <CABAODRehuC7yBXTHOBVcmy2UY0v=J2W4p9Mw-iBMrd9nfgDgng@mail.gmail.com>

Hello.
What do you mean?
Nguyen Huu Khoi


On Thu, Sep 14, 2023 at 1:22?AM Satish Patel <satish.txt at gmail.com> wrote:

> Hi,
>
> Assuming instance monitoring also calls prometheus api or query to get
> specific matrices for instance.
>
> On Wed, Sep 13, 2023 at 1:00?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello.
>> It talks about node monitor. Which I am doing about instance monitoring.
>> You can check on Administrator Page >>> Monitor Center.
>> Nguyen Huu Khoi
>>
>>
>> On Wed, Sep 13, 2023 at 11:21?PM Satish Patel <satish.txt at gmail.com>
>> wrote:
>>
>>> Thank you!
>>>
>>> Then what is the deal here? This thread says just add prometheus config
>>> and magic will happen.
>>>
>>> https://bugs.launchpad.net/skyline-apiserver/+bug/2002902
>>>
>>> On Wed, Sep 13, 2023 at 12:09?PM Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com> wrote:
>>>
>>>> Hello.
>>>> The case is here,
>>>>
>>>> https://github.com/openstack/skyline-console/blob/master/src/pages/compute/containers/Instance/Detail/index.jsx
>>>>
>>>> but you need to understand how skyline construct page. This project
>>>> uses nodejs, I use the chart.js library to code. it will need some
>>>> knowledge about api and javascript.
>>>>
>>>> Let's read first.
>>>>
>>>>
>>>> Nguyen Huu Khoi
>>>>
>>>>
>>>> On Wed, Sep 13, 2023 at 7:29?PM Satish Patel <satish.txt at gmail.com>
>>>> wrote:
>>>>
>>>>> Sure that is ok. Can you give me a small hit about what you actually
>>>>> did? I can see you created a new tab 'monitor' but behind that did you
>>>>> create a new css theme etc to pull metrics from prometheus?
>>>>>
>>>>> All I want to do is just to see if it's worth it because we don't have
>>>>> prometheus but we have different data sources which I can integrate. Thanks
>>>>> for the work. very appreciated.
>>>>>
>>>>> On Wed, Sep 13, 2023 at 7:27?AM Nguy?n H?u Kh?i <
>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>
>>>>>> Hello. Bc i am just working. And I am not dev so I still learn. If it
>>>>>> is ok then i will do.
>>>>>>
>>>>>> On Wed, Sep 13, 2023, 6:17 PM Satish Patel <satish.txt at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> That is great!!
>>>>>>>
>>>>>>> I?m not a developer but will try to read the code but it would be
>>>>>>> good if you just give me file name or clue about where to look.
>>>>>>>
>>>>>>> If you have patch or diff would be great. Why don?t you contribute
>>>>>>> this feature and submit a patch
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Sep 12, 2023, at 8:08 PM, Nguy?n H?u Kh?i <
>>>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>>>
>>>>>>> ?
>>>>>>>
>>>>>>> Nguyen Huu Khoi
>>>>>>> Hello. I just read skyline source code and followed it about data
>>>>>>> source. This is
>>>>>>> https://github.com/zhangjianweibj/prometheus-libvirt-exporter.
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/69dab950/attachment.htm>

From rdhasman at redhat.com  Thu Sep 14 10:33:44 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 14 Sep 2023 16:03:44 +0530
Subject: [cinder] festival of feature reviews on 15th September
Message-ID: <CAARK8KTP-UgxjDX8Z-b++w48=nvAgCNbZZavOz27M9J4UJKGUA@mail.gmail.com>

Hello Argonauts,

We will be having our monthly festival of reviews tomorrow
i.e. 15th September (Friday) from 1400-1600 UTC.

Following are some additional details:
Date: 15th September, 2023
Time: 1400-1600 UTC
Meeting link:  https://meet.google.com/jqg-eigw-rku
etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews

We are planning to prioritize patches for RC2[1].

[1] https://etherpad.opendev.org/p/cinder-bobcat-rc-patches

Thanks
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/70812617/attachment.htm>

From openstack at jangutter.com  Thu Sep 14 10:54:19 2023
From: openstack at jangutter.com (Jan Gutter)
Date: Thu, 14 Sep 2023 11:54:19 +0100
Subject: [kolla-ansible][zun] Intention to drop support for Zun for the 2023.1
 and path forward
Message-ID: <CAAAzNVKfwGN=DZwWKY-qUFP25yfk4mmR2FsPfLSmJEgNxXHppg@mail.gmail.com>

Hi folks,

In yesterday's Kolla IRC meeting we discussed the path forward for Zun
[1] and came to the conclusion that it might be better for all
involved to drop support for Zun for the 2023.1 release until it can
be updated to support the necessary dependencies. More specific
details at the end of the message.

With this in mind, the plan is to start this process in a week from
now, unless a better solution is presented. There is still some time
for discussion, please don't hesitate!

There are two paths forward after this:

If Zun can be updated to support the dependencies during the
maintenance timeframe of 2023.1, then support would be restored.

If no support is available at the time Caracal releases, however, it
will be considered for removal in kolla and kolla-ansible.

What this means:

Kolla-ansible operators currently running Zun should hold off
migration to 2023.1. Any development help would of course be
appreciated. Please coordinate with the Zun project to help with
development.

Details on the dependency problems:

* Currently, Zun has an external dependency on Docker 20.x, and uses a
feature that has been removed in later versions of Docker.
* This Docker feature also relies on an older version of etcd (3.3)
* The mitigation [2] is to pin to the old versions of Docker and etcd,
but this is not possible with Debian Bookworm hosts.

Why this is a problem in Kolla-ansible (and Kolla):

* This can't easily be solved by vendoring in an older version of
etcd: the migration path it introduces to operators would incur a
significant amount of risk.
* Host level involvement is also particularly painful, the host
version of Docker needs to connect to the etcd service running in the
containers.
* Even though the containers can be kept buildable and the
configuration and inventory settings could be maintained, a working
setup is not testable in CI.

Thanks very much for everyone's patience, contributions and time!

[1]: https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-09-13-13.00.log.html
[2]: https://bugs.launchpad.net/zun/+bug/2007142


From tkajinam at redhat.com  Thu Sep 14 11:19:58 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Thu, 14 Sep 2023 20:19:58 +0900
Subject: [puppet] Transitioning train, ussuri and victoria to EOL
In-Reply-To: <CAL_crJToMKEPqFxjCNuiAuu79EuTqzBTHF=WNvTmJLji2YQ_Rg@mail.gmail.com>
References: <CAL_crJToMKEPqFxjCNuiAuu79EuTqzBTHF=WNvTmJLji2YQ_Rg@mail.gmail.com>
Message-ID: <CAL_crJR2bgHCgjfiaS26QgXk9JOEFwgcQT9yQegqPdN0MJbMBQ@mail.gmail.com>

Because I have not heard any objections, I've pushed the changes to EOL
these old branches.
 train: https://review.opendev.org/c/openstack/releases/+/893909
 ussuri: https://review.opendev.org/c/openstack/releases/+/893995
 victoria: https://review.opendev.org/c/openstack/releases/+/894000

In case you have any concern, then please leave comments in these reviews.

On Wed, Sep 6, 2023 at 9:38?PM Takashi Kajinami <tkajinam at redhat.com> wrote:

> Hello,
>
>
> As we agreed in the PTG discussions at Vancouver, we'll EOL the old stable
> branches
> of Puppet OpenStack projects. As the first step I'll start transitioning
> stable/train, ussuri
> and victoria to EOL early next week.
>
> Please let me know in case anyone has any concerns about it.
>
> Thank you,
> Takashi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/d5039d84/attachment-0001.htm>

From bajaykushal009 at gmail.com  Thu Sep 14 03:59:03 2023
From: bajaykushal009 at gmail.com (Ajay Kushal)
Date: Thu, 14 Sep 2023 09:29:03 +0530
Subject: Octavia - open source scalable load balancer for use in large
 OpenStack deployments.
Message-ID: <CAKbiUYKt7X6Hr-arFz_GR6e6LwJ682jBmLsbzkVR55OJO-FzAA@mail.gmail.com>

Hello this is Ajay, final year engineering student from karnataka,India.
I have come across this project and feels really interesting and very
important for part my course project.
Can you please help me in executing this complete project successfully or
sharing a demo video of project could be more clear.
Please help me in this regards..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/2ede9a80/attachment.htm>

From rafaa.haji3 at gmail.com  Thu Sep 14 09:38:16 2023
From: rafaa.haji3 at gmail.com (Rafa)
Date: Thu, 14 Sep 2023 11:38:16 +0200
Subject: [nova] Live migration of a RAM intensive instance failed
Message-ID: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>

Hello,
I have a volume-backed instance with 16 vCPU and 64GB RAM. The instance
uses 60GB RAM out of 64GB (used: 22GB; buff/cache 38GB). When I do a
live migration of this instance, it fails without any timeouts.
It copies almost all the RAM (within 150 - 250 seconds) to the target
compute host without any problems according to the logs. Then the
instance is paused to copy the rest of the RAM. Everything seems to be
working correctly up to this point, but then the instance resumes and
the following error message appears:

Live Migration failure: operation failed: migration out job:
unexpectedly failed: libvirt.libvirtError: operation failed:
migration out job: unexpectedly failed

Unfortunately, this error message does not say much. It doesn't look
like it's due to any timeouts or short downtimes, but I still tested
different (higher) values for the following configurations.
Unfortunately without success.
- live_migration_completion_timeout
- live_migration_timeout_action: abort / force_complete (pause)
- live_migration_downtime
- live_migration_downtime_steps
- live_migration_downtime_delay
- live_migration_permit_auto_converge: True / False

All other instances on the same source and destination hosts can be
live migrated without any issues. This instance can also be
successfully live migrated after a restart, as it is probably not yet
heavily loaded. After a few hours, however, the live migration no
longer works.

Any ideas what the problem could be?

Logs:
- nova-compute.log from source compute host:
https://paste.openstack.org/show/bJMFxnPKQBEVaPakud61/
- i found this Traceback using journalctrl:
https://paste.openstack.org/show/bIS4GFAd2RJ5fHVN9I8d/
- there was also an error in /var/log/libvirt/qemu/:
https://paste.openstack.org/show/bImT89IelDcXXBPSgTCO/

Enviroment:
- Libvirt: 8.0.0
- QEMU: 4.2.1
- Nova: 25.1.1
- OpenStack: Yoga
- Compute operating system: Ubuntu 20.04


From berndbausch at gmail.com  Thu Sep 14 13:52:22 2023
From: berndbausch at gmail.com (berndbausch at gmail.com)
Date: Thu, 14 Sep 2023 22:52:22 +0900
Subject: Octavia - open source scalable load balancer for use in large
 OpenStack deployments.
In-Reply-To: <CAKbiUYKt7X6Hr-arFz_GR6e6LwJ682jBmLsbzkVR55OJO-FzAA@mail.gmail.com>
References: <CAKbiUYKt7X6Hr-arFz_GR6e6LwJ682jBmLsbzkVR55OJO-FzAA@mail.gmail.com>
Message-ID: <016f01d9e712$b05cf550$1116dff0$@gmail.com>

I would start with the official documentation at https://docs.openstack.org/octavia/latest/. The Youtube Openinfra Foundation channel has a number of videos from various OpenStack summits; searching for @openinfrafoundation Octavia in Youtube will yield a few very useful presentations, or perhaps simply search for openstack Octavia.

 

From: Ajay Kushal <bajaykushal009 at gmail.com> 
Sent: Thursday, September 14, 2023 12:59 PM
To: openstack-discuss at lists.openstack.org
Subject: Octavia - open source scalable load balancer for use in large OpenStack deployments.

 

Hello this is Ajay, final year engineering student from karnataka,India.

I have come across this project and feels really interesting and very important for part my course project.

Can you please help me in executing this complete project successfully or sharing a demo video of project could be more clear.

Please help me in this regards.. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/92092415/attachment.htm>

From eblock at nde.ag  Thu Sep 14 14:18:21 2023
From: eblock at nde.ag (Eugen Block)
Date: Thu, 14 Sep 2023 14:18:21 +0000
Subject: [nova] Live migration of a RAM intensive instance failed
In-Reply-To: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
Message-ID: <20230914141821.Horde.BgGlwPjPCXWJRhoLxRG_P7H@webmail.nde.ag>

Hi, could you share logs from the target compute node as well?

Zitat von Rafa <rafaa.haji3 at gmail.com>:

> Hello,
> I have a volume-backed instance with 16 vCPU and 64GB RAM. The instance
> uses 60GB RAM out of 64GB (used: 22GB; buff/cache 38GB). When I do a
> live migration of this instance, it fails without any timeouts.
> It copies almost all the RAM (within 150 - 250 seconds) to the target
> compute host without any problems according to the logs. Then the
> instance is paused to copy the rest of the RAM. Everything seems to be
> working correctly up to this point, but then the instance resumes and
> the following error message appears:
>
> Live Migration failure: operation failed: migration out job:
> unexpectedly failed: libvirt.libvirtError: operation failed:
> migration out job: unexpectedly failed
>
> Unfortunately, this error message does not say much. It doesn't look
> like it's due to any timeouts or short downtimes, but I still tested
> different (higher) values for the following configurations.
> Unfortunately without success.
> - live_migration_completion_timeout
> - live_migration_timeout_action: abort / force_complete (pause)
> - live_migration_downtime
> - live_migration_downtime_steps
> - live_migration_downtime_delay
> - live_migration_permit_auto_converge: True / False
>
> All other instances on the same source and destination hosts can be
> live migrated without any issues. This instance can also be
> successfully live migrated after a restart, as it is probably not yet
> heavily loaded. After a few hours, however, the live migration no
> longer works.
>
> Any ideas what the problem could be?
>
> Logs:
> - nova-compute.log from source compute host:
> https://paste.openstack.org/show/bJMFxnPKQBEVaPakud61/
> - i found this Traceback using journalctrl:
> https://paste.openstack.org/show/bIS4GFAd2RJ5fHVN9I8d/
> - there was also an error in /var/log/libvirt/qemu/:
> https://paste.openstack.org/show/bImT89IelDcXXBPSgTCO/
>
> Enviroment:
> - Libvirt: 8.0.0
> - QEMU: 4.2.1
> - Nova: 25.1.1
> - OpenStack: Yoga
> - Compute operating system: Ubuntu 20.04





From roger.riverac at gmail.com  Thu Sep 14 15:37:18 2023
From: roger.riverac at gmail.com (Roger Rivera)
Date: Thu, 14 Sep 2023 11:37:18 -0400
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CABAODRcqw1xhfaue-XGWthxxaHi_z6KSdxEb3qg=qB6X1FmHbw@mail.gmail.com>
References: <CABAODRcqw1xhfaue-XGWthxxaHi_z6KSdxEb3qg=qB6X1FmHbw@mail.gmail.com>
Message-ID: <CAGe_KfzDWz5eLRgxg=9a8e0k2yd1LOV==0rrAqXm05bAb-+aEg@mail.gmail.com>

Hi Nguyen

This looks great! Congratulations Nguyen. Adding monitoring is an excellent
contribution. Hopefully we start to see some traction on Skyline as I do
also agree it is a phenomenal project that adds value to the OpenStack
ecosystem. Would be awesome to see it integrate monitoring, metering, and
maybe even billing for public-cloud use cases.

Thanks again,

Roger

On Tue, Sep 12, 2023 at 11:45?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello guys.
> I am working on Skyline.
>
> I can integrate my monitor tab on it.
>
> I will try to do something about it. If it works properly, I can
> contribute.
>
> It is a very nice project. I hope it will grow and grow in the future.
>
> Thanks Skyline Team.
>
>
> [image: image.png]
>
> Nguyen Huu Khoi
>


-- 
*Roger Rivera*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/55f4652b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 248643 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/55f4652b/attachment-0001.png>

From elod.illes at est.tech  Thu Sep 14 16:01:42 2023
From: elod.illes at est.tech (=?utf-8?B?RWzDtWQgSWxsw6lz?=)
Date: Thu, 14 Sep 2023 16:01:42 +0000
Subject: [adjutant][barbican][blazar][ec2-api][freezer][masakari][mistral][monasca][murano][sahara][solum][telemetry][vitrage][zun]
 broken gate on master branch
Message-ID: <VI1P18901MB07510F67CDCE0C61EBACCBB7FFF7A@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>

Hi $teams_in_subject,

I've generated test patches to see gate health (this time for
cycle-with-rc deliverables, that have not merged any patches recently)
and the patches show [1] that you have broken CI jobs on
your gate. Could the teams please check what the issue is / issues are
and fix as soon as possible? Thanks in advance!

[1] https://review.opendev.org/q/topic:release-health-check-cwr-bobcat+is:open

Thanks,

El?d Ill?s
irc: elodilles @ #openstack-release
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/781962d6/attachment.htm>

From hongbin034 at gmail.com  Thu Sep 14 16:04:41 2023
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Fri, 15 Sep 2023 00:04:41 +0800
Subject: [kolla-ansible][zun] Intention to drop support for Zun for the
 2023.1 and path forward
In-Reply-To: <CAAAzNVKfwGN=DZwWKY-qUFP25yfk4mmR2FsPfLSmJEgNxXHppg@mail.gmail.com>
References: <CAAAzNVKfwGN=DZwWKY-qUFP25yfk4mmR2FsPfLSmJEgNxXHppg@mail.gmail.com>
Message-ID: <CAFNUc+RG6VaEGxwF2W8PmUpuMAChc5+n-qmn6ehd0vcLLLC-jQ@mail.gmail.com>

Hi,

I am from Zun team. The goal is to fix it in "C" release. I will keep the
status updated in this ticket: https://bugs.launchpad.net/zun/+bug/2007142
. Sorry for all the inconvenience.

Best regards,
Hongbin

On Thu, Sep 14, 2023 at 6:56?PM Jan Gutter <openstack at jangutter.com> wrote:

> Hi folks,
>
> In yesterday's Kolla IRC meeting we discussed the path forward for Zun
> [1] and came to the conclusion that it might be better for all
> involved to drop support for Zun for the 2023.1 release until it can
> be updated to support the necessary dependencies. More specific
> details at the end of the message.
>
> With this in mind, the plan is to start this process in a week from
> now, unless a better solution is presented. There is still some time
> for discussion, please don't hesitate!
>
> There are two paths forward after this:
>
> If Zun can be updated to support the dependencies during the
> maintenance timeframe of 2023.1, then support would be restored.
>
> If no support is available at the time Caracal releases, however, it
> will be considered for removal in kolla and kolla-ansible.
>
> What this means:
>
> Kolla-ansible operators currently running Zun should hold off
> migration to 2023.1. Any development help would of course be
> appreciated. Please coordinate with the Zun project to help with
> development.
>
> Details on the dependency problems:
>
> * Currently, Zun has an external dependency on Docker 20.x, and uses a
> feature that has been removed in later versions of Docker.
> * This Docker feature also relies on an older version of etcd (3.3)
> * The mitigation [2] is to pin to the old versions of Docker and etcd,
> but this is not possible with Debian Bookworm hosts.
>
> Why this is a problem in Kolla-ansible (and Kolla):
>
> * This can't easily be solved by vendoring in an older version of
> etcd: the migration path it introduces to operators would incur a
> significant amount of risk.
> * Host level involvement is also particularly painful, the host
> version of Docker needs to connect to the etcd service running in the
> containers.
> * Even though the containers can be kept buildable and the
> configuration and inventory settings could be maintained, a working
> setup is not testable in CI.
>
> Thanks very much for everyone's patience, contributions and time!
>
> [1]:
> https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-09-13-13.00.log.html
> [2]: https://bugs.launchpad.net/zun/+bug/2007142
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/627e9d00/attachment.htm>

From pierre at stackhpc.com  Thu Sep 14 16:52:20 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Thu, 14 Sep 2023 18:52:20 +0200
Subject: [adjutant][barbican][blazar][ec2-api][freezer][masakari][mistral][monasca][murano][sahara][solum][telemetry][vitrage][zun]
 broken gate on master branch
In-Reply-To: <VI1P18901MB07510F67CDCE0C61EBACCBB7FFF7A@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
References: <VI1P18901MB07510F67CDCE0C61EBACCBB7FFF7A@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
Message-ID: <CA+ny2sxK63KeRjN9zVxWFq+i0u6Qynu-JLM3=dgG+q6oYA2REg@mail.gmail.com>

Thanks El?d for letting us know.

blazar-dashboard is failing due to lower-constraints testing, I am removing
it like it was done in other projects.

On Thu, 14 Sept 2023 at 18:06, El?d Ill?s <elod.illes at est.tech> wrote:

> Hi $teams_in_subject,
>
> I've generated test patches to see gate health (this time for
> cycle-with-rc deliverables, that have not merged any patches recently)
> and the patches show [1] that you have broken CI jobs on
> your gate. Could the teams please check what the issue is / issues are
> and fix as soon as possible? Thanks in advance!
>
> [1]
> https://review.opendev.org/q/topic:release-health-check-cwr-bobcat+is:open
>
> Thanks,
>
> El?d Ill?s
> irc: elodilles @ #openstack-release
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/141d56b9/attachment.htm>

From rafaa.haji3 at gmail.com  Thu Sep 14 17:07:55 2023
From: rafaa.haji3 at gmail.com (Rafa)
Date: Thu, 14 Sep 2023 19:07:55 +0200
Subject: [nova] Live migration of a RAM intensive instance failed
In-Reply-To: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
References: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
Message-ID: <CALOxu45mGrUzKzNANshRF16atTn9=sgtjBx4MMi+JuJee+D1iA@mail.gmail.com>

> Hi, could you share logs from the target compute node as well?

yes, here: https://paste.openstack.org/show/blpJE8krA1N6PVaLTVF0/


From nguyenhuukhoinw at gmail.com  Fri Sep 15 01:49:40 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Fri, 15 Sep 2023 08:49:40 +0700
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CAGe_KfzDWz5eLRgxg=9a8e0k2yd1LOV==0rrAqXm05bAb-+aEg@mail.gmail.com>
References: <CABAODRcqw1xhfaue-XGWthxxaHi_z6KSdxEb3qg=qB6X1FmHbw@mail.gmail.com>
 <CAGe_KfzDWz5eLRgxg=9a8e0k2yd1LOV==0rrAqXm05bAb-+aEg@mail.gmail.com>
Message-ID: <CABAODRf=ShXyAU4cyTTPZa_x-XDQfK-PD0mQ4xJ_jZu-QrKHew@mail.gmail.com>

I will try to add after it works properly. because I need to convert units.
If more people use Skyline and other projects, Openstack will become more
great. I will contribute because I use open source.

Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/b757a3ef/attachment.htm>

From satish.txt at gmail.com  Fri Sep 15 02:25:30 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 14 Sep 2023 22:25:30 -0400
Subject: [kolla-ansible]change prometheus data volume path
Message-ID: <CAPgF-fq_MtKwW9J+jSQjH7QXDp2Y+zL8hJ4mAT_SNjundTY+Rg@mail.gmail.com>

Folks,

I have deployed prometheus with koll-ansible and now I want to change the
path of prometheus volume to store matrices on bigger partitions. How do I
change the volume path of prometheus to store matrix data on
separate filesystem?

This is what I did in globals.yml but it doesn't work. Is the following
variable correct?

prometheus_server_default_volumes: "/mnt/prometheus"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230914/5a46dbc9/attachment.htm>

From ilya_p at hotmail.com  Fri Sep 15 06:52:47 2023
From: ilya_p at hotmail.com (Ilya Popov)
Date: Fri, 15 Sep 2023 06:52:47 +0000
Subject: [cinder][kolla-ansible] cinder-volume active/active usage
In-Reply-To: <20230828110627.Horde.TUdKYUVeuHSgHLuTSq4azz-@webmail.nde.ag>
References: <CAOirdiWLEQ2+cna8Qnu-WKOfN5FmFn1UKqw-bPaWGqRF13E-gw@mail.gmail.com>
 <20230828110627.Horde.TUdKYUVeuHSgHLuTSq4azz-@webmail.nde.ag>
Message-ID: <PAXP193MB2121A71094EF240AFC18A127FDF6A@PAXP193MB2121.EURP193.PROD.OUTLOOK.COM>

Hello,

there is additional issue, then using active/active cinder volume setup:

https://bugs.launchpad.net/cinder/+bug/1927186

as we discussed in cinder IRC - it looks like architectural problem in cinder (data sync between active/active cinder-volume and cinder-scheduler)

Regards,

Ilya


________________________________
From: Eugen Block <eblock at nde.ag>
Sent: Monday, August 28, 2023 11:06 AM
To: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: Re: [cinder][kolla-ansible] cinder-volume active/active usage

Hi,

I'm not familiar with kolla-ansible but since nobody else replied to
this thread I just wanted to bump it. A year ago Gorka commented on my
thread [3] about active/active setup, but we don't use any of the
deployment tools, we have our own deployment method. I also don't
really have answers for you, I don't think it makes a big difference
which DLM tool you use, maybe the one you're more familiar with. I
tested cinder-volume a/a with zookeeper and seemed to work well in my
lab setup, I don't have an actual deployment to speak from experience.

Regards,
Eugen

[3]
https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030554.html

Zitat von ??? <hanguangyu2 at gmail.com>:

> Hello,
>
> I saw that kolla-ansible had allow cinder coordination backend to be
> configured. And it can be set to "redis" or "etcd" in
> /etc/kolla/gloabls.yml [1]. Based on my current understanding, this
> option enables cinder-volume active/active.
>
> 1. I would like to ask, between Redis and Etcd, which one is more
> recommended or what are their pros and cons?
> 2. And I have saw the spec of cinder-volume a/a[2]. Is it sufficient
> to configure [coordination]backend_url and [DEFAULT]cluster to use
> Cinder volume active/active, or are there any other considerations?
> Could any reference for Cinder volume active/active configuration and
> usage documentation be recommended ?
>
> I would appreciate for any help.
> Best wishes.
>
> Han Guangyu
>
> [1]
> https://github.com/openstack/kolla-ansible/blob/master/etc/kolla/globals.yml#L539
> [2]
> https://specs.openstack.org/openstack/cinder-specs/specs/ocata/ha-aa-job-distribution.html




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/5cf49411/attachment.htm>

From pierre at stackhpc.com  Fri Sep 15 08:03:03 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Fri, 15 Sep 2023 10:03:03 +0200
Subject: [kolla-ansible]change prometheus data volume path
In-Reply-To: <CAPgF-fq_MtKwW9J+jSQjH7QXDp2Y+zL8hJ4mAT_SNjundTY+Rg@mail.gmail.com>
References: <CAPgF-fq_MtKwW9J+jSQjH7QXDp2Y+zL8hJ4mAT_SNjundTY+Rg@mail.gmail.com>
Message-ID: <CA+ny2syBtiUpqZvL460Oxca-dJ2h9maaHW7b1kTUukA-fEFYOA@mail.gmail.com>

Hello Satish,

The prometheus_server_default_volumes variable is defined as:

prometheus_server_default_volumes:
  - "{{ node_config_directory }}/prometheus-server/:{{
container_config_directory }}/:ro"
  - "/etc/localtime:/etc/localtime:ro"
  - "{{ '/etc/timezone:/etc/timezone:ro' if ansible_facts.os_family ==
'Debian' else '' }}"
  - "prometheus_v2:/var/lib/prometheus"
  - "kolla_logs:/var/log/kolla/"

As you can see, it configures a lot more than just how Prometheus data is
stored. By default it uses the prometheus_v2 Docker volume. If you want to
store your data in /mnt/prometheus, you can use:

prometheus_server_default_volumes:
  - "{{ node_config_directory }}/prometheus-server/:{{
container_config_directory }}/:ro"
  - "/etc/localtime:/etc/localtime:ro"
  - "{{ '/etc/timezone:/etc/timezone:ro' if ansible_facts.os_family ==
'Debian' else '' }}"
  - "/mnt/prometheus:/var/lib/prometheus"
  - "kolla_logs:/var/log/kolla/"

Note that it won't move the data for you. If you want to keep existing
data, stop prometheus_server containers and copy the data from
/var/lib/docker/volumes/prometheus_v2/_data into /mnt/prometheus before
applying this configuration.

Best regards,
Pierre Riteau (priteau)

On Fri, 15 Sept 2023 at 04:29, Satish Patel <satish.txt at gmail.com> wrote:

> Folks,
>
> I have deployed prometheus with koll-ansible and now I want to change the
> path of prometheus volume to store matrices on bigger partitions. How do I
> change the volume path of prometheus to store matrix data on
> separate filesystem?
>
> This is what I did in globals.yml but it doesn't work. Is the following
> variable correct?
>
> prometheus_server_default_volumes: "/mnt/prometheus"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/c11984a7/attachment-0001.htm>

From Danny.Webb at thehutgroup.com  Fri Sep 15 08:09:24 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Fri, 15 Sep 2023 08:09:24 +0000
Subject: [kolla-ansible]change prometheus data volume path
In-Reply-To: <CAPgF-fq_MtKwW9J+jSQjH7QXDp2Y+zL8hJ4mAT_SNjundTY+Rg@mail.gmail.com>
References: <CAPgF-fq_MtKwW9J+jSQjH7QXDp2Y+zL8hJ4mAT_SNjundTY+Rg@mail.gmail.com>
Message-ID: <LO2P265MB5773A7FAEA02722503CBF0889AF6A@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

https://github.com/openstack/kolla-ansible/blob/428acfe97fdfbc89fd4dea577160192647e6f6b5/ansible/roles/prometheus/defaults/main.yml#L226

You'd have to completely redefine the default volumes list.  The other option is to do your mount into the /var/lib/docker/volumes/prometheus_v2/data directory
________________________________
From: Satish Patel <satish.txt at gmail.com>
Sent: 15 September 2023 03:25
To: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla-ansible]change prometheus data volume path


CAUTION: This email originates from outside THG

________________________________
Folks,

I have deployed prometheus with koll-ansible and now I want to change the path of prometheus volume to store matrices on bigger partitions. How do I change the volume path of prometheus to store matrix data on separate filesystem?

This is what I did in globals.yml but it doesn't work. Is the following variable correct?

prometheus_server_default_volumes: "/mnt/prometheus"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/bac0438f/attachment.htm>

From pfb29.cam at gmail.com  Fri Sep 15 10:43:42 2023
From: pfb29.cam at gmail.com (Paul Browne)
Date: Fri, 15 Sep 2023 11:43:42 +0100
Subject: [manila] - Enforcing CephFS pool data placement via backend config.
 options deprecated?
Message-ID: <CAMikz55DVXps0+aOYF0-RaCiwMiw=Kf3-Z4Pgt-K1QpgKC7qqA@mail.gmail.com>

Hello to the list,

In OpenStack releases prior to Wallaby, in CephFS native driver Manila
backend config there existed a configuration directive
cephfs_volume_path_prefix
<https://docs.openstack.org/manila/wallaby/configuration/shared-file-systems/samples/manila.conf.htm>
 ;

# DEPRECATED: The prefix of the cephfs volume path. (string value)
> # This option is deprecated for removal since Wallaby.
> # Its value may be silently ignored in the future.
> # Reason: This option is not used starting with the Nautilus release
> # of Ceph.
> #cephfs_volume_path_prefix = /volumes


This volume path prefix was usable (and very useful) to set different
prefixes in different backends, pointing to different pools in the same
backend Ceph cluster e.g. pools backed by storage devices of different
characteristics/technology or Ceph CRUSH rule, etc

The pool selection would be done in CephFS via the use of file layout
fattributes <https://docs.ceph.com/en/quincy/cephfs/file-layouts/>, file
layout inheritance ensuring that data created in sub-directories ends up in
the correct Ceph pool.

e.g. two backends using the same Ceph cluster but two different path
prefixes hitting different Ceph pools

[cephfsnative1]
> driver_handles_share_servers = False
> share_backend_name = CEPHFS1
> share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
> cephfs_conf_path = /etc/ceph/ceph.conf
> cephfs_auth_id = manila
> cephfs_cluster_name = ceph
> cephfs_volume_path_prefix = /volumes-staging
> cephfs_volume_mode = 777
> cephfs_enable_snapshots = False



> [cephfsnative1_ec]
> driver_handles_share_servers = False
> share_backend_name = CEPHFS1_EC
> share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
> cephfs_conf_path = /etc/ceph/ceph.conf
> cephfs_auth_id = manila
> cephfs_cluster_name = ceph
> cephfs_volume_path_prefix = /volumes-ec-staging
> cephfs_volume_mode = 777
> cephfs_enable_snapshots = False


However, since Wallaby this config directive looks to have been deprecated
and the default of using a path prefix of only /volumes is possible.Trying
to use any other prefix in backend configs is ignored.

Would anyone on the list know why this option was deprecated in Manila
code, or was this forced on Manila by upstream Ceph as of Nautilus?

Is there a way to get back to an equivalent functionality?

Currently using only a default path of /volumes means we have lost all
flexibility in defining Manila CephFS share data placement using the native
CephFS driver.

Possibly using share group types+share groups and some pre-created paths in
the root CephFS could get to something like equivalency?

But these paths would need to correspond to the share group UUID, which
will only be known after the share group has been created.

So not all that flexible a path, since it requires an interaction between
users to communicate the share group ID and Ceph admins to set the correct
file layout policy. Putting the path prefix in the backend type removed all
of that in a nicely transparent way.

Having just prototyped this, it will work for setting a desired file layout
on a pre-defined share group UUID path in the root CephFS, though it's not
really ideal or sustainable to be able to do this for dynamically created
share groups by users or automation...

Thanks in advance for any advice,
Paul Browne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/4d90c22a/attachment.htm>

From pfb29 at cam.ac.uk  Fri Sep 15 10:54:12 2023
From: pfb29 at cam.ac.uk (Paul Browne)
Date: Fri, 15 Sep 2023 10:54:12 +0000
Subject: [manila] - Enforcing CephFS pool data placement via backend config.
 options deprecated?
Message-ID: <LO0P265MB2923F49FF8B9FA4DCC7E049DF6F6A@LO0P265MB2923.GBRP265.PROD.OUTLOOK.COM>

Hello to the list,

In OpenStack releases prior to Wallaby, in CephFS native driver Manila backend config there existed a configuration directive cephfs_volume_path_prefix<https://docs.openstack.org/manila/wallaby/configuration/shared-file-systems/samples/manila.conf.htm> ;

# DEPRECATED: The prefix of the cephfs volume path. (string value)
# This option is deprecated for removal since Wallaby.
# Its value may be silently ignored in the future.
# Reason: This option is not used starting with the Nautilus release
# of Ceph.
#cephfs_volume_path_prefix = /volumes

This volume path prefix was usable (and very useful) to set different prefixes in different backends, pointing to different pools in the same backend Ceph cluster e.g. pools backed by storage devices of different characteristics/technology or Ceph CRUSH rule, etc

The pool selection would be done in CephFS via the use of file layout fattributes<https://docs.ceph.com/en/quincy/cephfs/file-layouts/>, file layout inheritance ensuring that data created in prefix child sub-directories ends up in the correct Ceph pool.

e.g. two backends using the same Ceph cluster but two different path prefixes hitting different Ceph pools

[cephfsnative1]
driver_handles_share_servers = False
share_backend_name = CEPHFS1
share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
cephfs_conf_path = /etc/ceph/ceph.conf
cephfs_auth_id = manila
cephfs_cluster_name = ceph
cephfs_volume_path_prefix = /volumes-staging
cephfs_volume_mode = 777
cephfs_enable_snapshots = False

[cephfsnative1_ec]
driver_handles_share_servers = False
share_backend_name = CEPHFS1_EC
share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
cephfs_conf_path = /etc/ceph/ceph.conf
cephfs_auth_id = manila
cephfs_cluster_name = ceph
cephfs_volume_path_prefix = /volumes-ec-staging
cephfs_volume_mode = 777
cephfs_enable_snapshots = False

However, since Wallaby this config directive looks to have been deprecated and the default of using a path prefix of only /volumes is possible. Trying to use any other prefix in backend configs is ignored.

Would anyone on the list know why this option was deprecated in Manila code, or was this forced on Manila by upstream Ceph as of Nautilus? Is there a way to get back to an equivalent functionality?

Currently using only a default path of /volumes means we have lost all flexibility in defining Manila CephFS share data placement using the native CephFS driver.

Possibly using share group types+share groups and some pre-created paths in the root CephFS could get to something like equivalency?

But these paths would need to correspond to the share group UUID, which will only be known after the share group has been created.

So not all that flexible a path, since it requires an interaction between users/tenant to communicate the share group ID and Ceph admins to set the correct file layout policy. Putting the path prefix in the backend+share-type removed all of that in a nicely transparent way.

Having just prototyped this, it will work for setting a desired file layout on a pre-defined share group UUID path in the root CephFS, though it's not really ideal or sustainable to be able to do this for dynamically created share groups by users or automation, which could exist in large numbers...

Thanks in advance for any advice,
Paul Browne



*******************
Paul Browne
Research Computing Platforms
University Information Services
Roger Needham Building
JJ Thompson Avenue
University of Cambridge
Cambridge
United Kingdom
E-Mail: pfb29 at cam.ac.uk<mailto:pfb29 at cam.ac.uk>
Tel: 0044-1223-746548
*******************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/4963f448/attachment-0001.htm>

From zigo at debian.org  Fri Sep 15 11:07:03 2023
From: zigo at debian.org (Thomas Goirand)
Date: Fri, 15 Sep 2023 13:07:03 +0200
Subject: [all] oslo.db 14.0.0 breaks at least 4 projects (was: SQLAlchemy
 2.x support in Bobcat)
In-Reply-To: <dc035bef4b93d0048aacad02aa08bf4b4ecf1a34.camel@redhat.com>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
 <dc035bef4b93d0048aacad02aa08bf4b4ecf1a34.camel@redhat.com>
Message-ID: <b9c5699e-d5d2-5a22-7782-2e2b9b35321d@debian.org>

On 9/13/23 15:39, Stephen Finucane wrote:
> On Wed, 2023-09-13 at 09:21 +0200, Thomas Goirand wrote:
>> Hi,
>>
>> As you may know, and to my great frustration, I'm not the maintainer of
>> SQLAlchemy in Debian, even though OpenStack is the biggest consumer of
>> it. The current maintainer insists that he wants to upload SQLA 2.x in
>> Unstable, potentially breaking all of OpenStack.
>>
>> At the present moment, if I understand correctly, we're not there yet,
>> and Bobcat doesn't have such a support. It would be ok for me, *IF*
>> there are patches available on master, that I could backport to Bobcat
>> and maintain in the debian/patches folder of each project. However, the
>> biggest current annoyance, is that I have no idea where we are at. Are
>> we close to such a support? Is there a list of patches to apply on top
>> of Bobcat that is maintained somewhere?
>>
>> Please enlighten me... :)
> 
> I think you figured this out on IRC this morning, but the vast majority (though
> not all) of the patches are available at the sqlalchemy-20 topic in Gerrit [1].
> I've been working on this for almost 2 years now and have most of the core
> projects well on their way but not everything is complete, as you'll tell from
> that list. I have a canary patch [2] that I've been using to spot missing
> services. I plan to pick up the Manila work again early in C, but could do with
> help removing the use of autocommit in Heat and the weird test failures I'm
> seeing in Cinder [3]. We also need reviews of the Masakri series (Is that
> project dead? I can't tell). Once those are addressed, I _think_ we might be
> done but who knows what else we'll find...
> 
> Cheers,
> Stephen
> 
> [1] https://review.opendev.org/q/topic:sqlalchemy-20+is:open
> [2] https://review.opendev.org/c/openstack/requirements/+/879743
> [3] https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder

Thanks for your work, really!
And thanks for the details above.

Now, not sure how much this is related, but I've seen that the new 
oslo.db 14.0.0 breaks:
- freezer-api
- trove
- cloudkitty
- watcher

Is there any plan to fix oslo.db, or the above projects? Maybe revert 
some commits in oslo.db? Can someone explain to me what's going on for 
this as well?

Cheers,

Thomas Goirand (zigo)



From stephenfin at redhat.com  Fri Sep 15 11:26:05 2023
From: stephenfin at redhat.com (Stephen Finucane)
Date: Fri, 15 Sep 2023 12:26:05 +0100
Subject: [all] oslo.db 14.0.0 breaks at least 4 projects (was:
 SQLAlchemy 2.x support in Bobcat)
In-Reply-To: <b9c5699e-d5d2-5a22-7782-2e2b9b35321d@debian.org>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
 <dc035bef4b93d0048aacad02aa08bf4b4ecf1a34.camel@redhat.com>
 <b9c5699e-d5d2-5a22-7782-2e2b9b35321d@debian.org>
Message-ID: <c431a5cafdd2d38f3469e75e75010c72be9cc56c.camel@redhat.com>

On Fri, 2023-09-15 at 13:07 +0200, Thomas Goirand wrote:
> On 9/13/23 15:39, Stephen Finucane wrote:
> > On Wed, 2023-09-13 at 09:21 +0200, Thomas Goirand wrote:
> > > Hi,
> > > 
> > > As you may know, and to my great frustration, I'm not the maintainer of
> > > SQLAlchemy in Debian, even though OpenStack is the biggest consumer of
> > > it. The current maintainer insists that he wants to upload SQLA 2.x in
> > > Unstable, potentially breaking all of OpenStack.
> > > 
> > > At the present moment, if I understand correctly, we're not there yet,
> > > and Bobcat doesn't have such a support. It would be ok for me, *IF*
> > > there are patches available on master, that I could backport to Bobcat
> > > and maintain in the debian/patches folder of each project. However, the
> > > biggest current annoyance, is that I have no idea where we are at. Are
> > > we close to such a support? Is there a list of patches to apply on top
> > > of Bobcat that is maintained somewhere?
> > > 
> > > Please enlighten me... :)
> > 
> > I think you figured this out on IRC this morning, but the vast majority (though
> > not all) of the patches are available at the sqlalchemy-20 topic in Gerrit [1].
> > I've been working on this for almost 2 years now and have most of the core
> > projects well on their way but not everything is complete, as you'll tell from
> > that list. I have a canary patch [2] that I've been using to spot missing
> > services. I plan to pick up the Manila work again early in C, but could do with
> > help removing the use of autocommit in Heat and the weird test failures I'm
> > seeing in Cinder [3]. We also need reviews of the Masakri series (Is that
> > project dead? I can't tell). Once those are addressed, I _think_ we might be
> > done but who knows what else we'll find...
> > 
> > Cheers,
> > Stephen
> > 
> > [1] https://review.opendev.org/q/topic:sqlalchemy-20+is:open
> > [2] https://review.opendev.org/c/openstack/requirements/+/879743
> > [3] https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder
> 
> Thanks for your work, really!
> And thanks for the details above.
> 
> Now, not sure how much this is related, but I've seen that the new 
> oslo.db 14.0.0 breaks:
> - freezer-api
> - trove
> - cloudkitty
> - watcher
> 
> Is there any plan to fix oslo.db, or the above projects? Maybe revert 
> some commits in oslo.db? Can someone explain to me what's going on for 
> this as well?

oslo.db has intentionally *not* been bumped to >= 13.0.0 in upper-constraints
because it introduces many breaking changes that are not compatible with
SQLAlchemy 2.x. Conversely, oslo.db < 13.0.0 is simply not compatible with
SQLAlchemy >= 2.x. As such, we can't bump oslo.db until the various projects
have been fixed which is the same as what we're seeing with SQLAlchemy 2.x.

Fortunately projects that adopt to I have been pushing patches to various
projects that add a "tips" job for testing main/master branches of SQLAlchemy,
Alembic, and oslo.db, e.g. [1][2][3][4]. The Neutron folks were well ahead of
the curve as usual and also have their own (which is where I got the idea from).
The projects you mention above could do with an equivalent job and my guess is
that the process of getting there will highlight quite a bit of work that they
need to do. They need to start at that asap (and tbh really should have started
at it a long time ago as they've had over 2 years of a warning [5]).

Cheers,
Stephen

[1] https://review.opendev.org/c/openstack/barbican/+/888308
[2] https://review.opendev.org/c/openstack/placement/+/886229
[3] https://review.opendev.org/c/openstack/cinder/+/886152
[4] https://review.opendev.org/c/openstack/glance/+/889066
[5] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html

> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 



From pierre at stackhpc.com  Fri Sep 15 11:50:22 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Fri, 15 Sep 2023 13:50:22 +0200
Subject: [all] oslo.db 14.0.0 breaks at least 4 projects (was: SQLAlchemy
 2.x support in Bobcat)
In-Reply-To: <c431a5cafdd2d38f3469e75e75010c72be9cc56c.camel@redhat.com>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
 <dc035bef4b93d0048aacad02aa08bf4b4ecf1a34.camel@redhat.com>
 <b9c5699e-d5d2-5a22-7782-2e2b9b35321d@debian.org>
 <c431a5cafdd2d38f3469e75e75010c72be9cc56c.camel@redhat.com>
Message-ID: <CA+ny2szSUVxt_cu12Vy06byN2ZkUmJtR3+LgqgYs2fXT=-_Xww@mail.gmail.com>

On Fri, 15 Sept 2023 at 13:29, Stephen Finucane <stephenfin at redhat.com>
wrote:

> On Fri, 2023-09-15 at 13:07 +0200, Thomas Goirand wrote:
> > On 9/13/23 15:39, Stephen Finucane wrote:
> > > On Wed, 2023-09-13 at 09:21 +0200, Thomas Goirand wrote:
> > > > Hi,
> > > >
> > > > As you may know, and to my great frustration, I'm not the maintainer
> of
> > > > SQLAlchemy in Debian, even though OpenStack is the biggest consumer
> of
> > > > it. The current maintainer insists that he wants to upload SQLA 2.x
> in
> > > > Unstable, potentially breaking all of OpenStack.
> > > >
> > > > At the present moment, if I understand correctly, we're not there
> yet,
> > > > and Bobcat doesn't have such a support. It would be ok for me, *IF*
> > > > there are patches available on master, that I could backport to
> Bobcat
> > > > and maintain in the debian/patches folder of each project. However,
> the
> > > > biggest current annoyance, is that I have no idea where we are at.
> Are
> > > > we close to such a support? Is there a list of patches to apply on
> top
> > > > of Bobcat that is maintained somewhere?
> > > >
> > > > Please enlighten me... :)
> > >
> > > I think you figured this out on IRC this morning, but the vast
> majority (though
> > > not all) of the patches are available at the sqlalchemy-20 topic in
> Gerrit [1].
> > > I've been working on this for almost 2 years now and have most of the
> core
> > > projects well on their way but not everything is complete, as you'll
> tell from
> > > that list. I have a canary patch [2] that I've been using to spot
> missing
> > > services. I plan to pick up the Manila work again early in C, but
> could do with
> > > help removing the use of autocommit in Heat and the weird test
> failures I'm
> > > seeing in Cinder [3]. We also need reviews of the Masakri series (Is
> that
> > > project dead? I can't tell). Once those are addressed, I _think_ we
> might be
> > > done but who knows what else we'll find...
> > >
> > > Cheers,
> > > Stephen
> > >
> > > [1] https://review.opendev.org/q/topic:sqlalchemy-20+is:open
> > > [2] https://review.opendev.org/c/openstack/requirements/+/879743
> > > [3]
> https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder
> >
> > Thanks for your work, really!
> > And thanks for the details above.
> >
> > Now, not sure how much this is related, but I've seen that the new
> > oslo.db 14.0.0 breaks:
> > - freezer-api
> > - trove
> > - cloudkitty
> > - watcher
> >
> > Is there any plan to fix oslo.db, or the above projects? Maybe revert
> > some commits in oslo.db? Can someone explain to me what's going on for
> > this as well?
>
> oslo.db has intentionally *not* been bumped to >= 13.0.0 in
> upper-constraints
> because it introduces many breaking changes that are not compatible with
> SQLAlchemy 2.x. Conversely, oslo.db < 13.0.0 is simply not compatible with
> SQLAlchemy >= 2.x. As such, we can't bump oslo.db until the various
> projects
> have been fixed which is the same as what we're seeing with SQLAlchemy 2.x.
>
> Fortunately projects that adopt to I have been pushing patches to various
> projects that add a "tips" job for testing main/master branches of
> SQLAlchemy,
> Alembic, and oslo.db, e.g. [1][2][3][4]. The Neutron folks were well ahead
> of
> the curve as usual and also have their own (which is where I got the idea
> from).
> The projects you mention above could do with an equivalent job and my
> guess is
> that the process of getting there will highlight quite a bit of work that
> they
> need to do. They need to start at that asap (and tbh really should have
> started
> at it a long time ago as they've had over 2 years of a warning [5]).
>
> Cheers,
> Stephen
>
> [1] https://review.opendev.org/c/openstack/barbican/+/888308
> [2] https://review.opendev.org/c/openstack/placement/+/886229
> [3] https://review.opendev.org/c/openstack/cinder/+/886152
> [4] https://review.opendev.org/c/openstack/glance/+/889066
> [5]
> https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html
>
> >
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
>

Thank you for highlighting cloudkitty. I added it as a discussion item for
our meeting next week.

Cheers,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/a7142859/attachment.htm>

From smooney at redhat.com  Fri Sep 15 11:56:32 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Fri, 15 Sep 2023 12:56:32 +0100
Subject: [nova] Live migration of a RAM intensive instance failed
In-Reply-To: <CALOxu45mGrUzKzNANshRF16atTn9=sgtjBx4MMi+JuJee+D1iA@mail.gmail.com>
References: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
 <CALOxu45mGrUzKzNANshRF16atTn9=sgtjBx4MMi+JuJee+D1iA@mail.gmail.com>
Message-ID: <32b2c8c454331d6fff141ea9bed56bce567eccdb.camel@redhat.com>

On Thu, 2023-09-14 at 19:07 +0200, Rafa wrote:
> > Hi, could you share logs from the target compute node as well?
> 
> yes, here: https://paste.openstack.org/show/blpJE8krA1N6PVaLTVF0/
> 

if the vm is under heavy memory load then its advisable ot use post-copy live migration.

in general live migration is not intened to be used with a vm under load
as there is no gurenettee that it will ever complete. post-copy live migration
can signifcantly increae the probablity that a vm under load will live migrate
in a reasonabel amount of time.

https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_post_copy

auto converge can also help but tis less important

https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_auto_converge



From zigo at debian.org  Fri Sep 15 12:11:56 2023
From: zigo at debian.org (Thomas Goirand)
Date: Fri, 15 Sep 2023 14:11:56 +0200
Subject: [all] oslo.db 14.0.0 breaks at least 4 projects (was: SQLAlchemy
 2.x support in Bobcat)
In-Reply-To: <c431a5cafdd2d38f3469e75e75010c72be9cc56c.camel@redhat.com>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
 <dc035bef4b93d0048aacad02aa08bf4b4ecf1a34.camel@redhat.com>
 <b9c5699e-d5d2-5a22-7782-2e2b9b35321d@debian.org>
 <c431a5cafdd2d38f3469e75e75010c72be9cc56c.camel@redhat.com>
Message-ID: <0e3a7928-26f4-1767-5305-42a86882e1e2@debian.org>

On 9/15/23 13:26, Stephen Finucane wrote:
> On Fri, 2023-09-15 at 13:07 +0200, Thomas Goirand wrote:
>> On 9/13/23 15:39, Stephen Finucane wrote:
>>> On Wed, 2023-09-13 at 09:21 +0200, Thomas Goirand wrote:
>>>> Hi,
>>>>
>>>> As you may know, and to my great frustration, I'm not the maintainer of
>>>> SQLAlchemy in Debian, even though OpenStack is the biggest consumer of
>>>> it. The current maintainer insists that he wants to upload SQLA 2.x in
>>>> Unstable, potentially breaking all of OpenStack.
>>>>
>>>> At the present moment, if I understand correctly, we're not there yet,
>>>> and Bobcat doesn't have such a support. It would be ok for me, *IF*
>>>> there are patches available on master, that I could backport to Bobcat
>>>> and maintain in the debian/patches folder of each project. However, the
>>>> biggest current annoyance, is that I have no idea where we are at. Are
>>>> we close to such a support? Is there a list of patches to apply on top
>>>> of Bobcat that is maintained somewhere?
>>>>
>>>> Please enlighten me... :)
>>>
>>> I think you figured this out on IRC this morning, but the vast majority (though
>>> not all) of the patches are available at the sqlalchemy-20 topic in Gerrit [1].
>>> I've been working on this for almost 2 years now and have most of the core
>>> projects well on their way but not everything is complete, as you'll tell from
>>> that list. I have a canary patch [2] that I've been using to spot missing
>>> services. I plan to pick up the Manila work again early in C, but could do with
>>> help removing the use of autocommit in Heat and the weird test failures I'm
>>> seeing in Cinder [3]. We also need reviews of the Masakri series (Is that
>>> project dead? I can't tell). Once those are addressed, I _think_ we might be
>>> done but who knows what else we'll find...
>>>
>>> Cheers,
>>> Stephen
>>>
>>> [1] https://review.opendev.org/q/topic:sqlalchemy-20+is:open
>>> [2] https://review.opendev.org/c/openstack/requirements/+/879743
>>> [3] https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder
>>
>> Thanks for your work, really!
>> And thanks for the details above.
>>
>> Now, not sure how much this is related, but I've seen that the new
>> oslo.db 14.0.0 breaks:
>> - freezer-api
>> - trove
>> - cloudkitty
>> - watcher
>>
>> Is there any plan to fix oslo.db, or the above projects? Maybe revert
>> some commits in oslo.db? Can someone explain to me what's going on for
>> this as well?
> 
> oslo.db has intentionally *not* been bumped to >= 13.0.0 in upper-constraints
> because it introduces many breaking changes that are not compatible with
> SQLAlchemy 2.x. Conversely, oslo.db < 13.0.0 is simply not compatible with
> SQLAlchemy >= 2.x. As such, we can't bump oslo.db until the various projects
> have been fixed which is the same as what we're seeing with SQLAlchemy 2.x.
> 
> Fortunately projects that adopt to I have been pushing patches to various
> projects that add a "tips" job for testing main/master branches of SQLAlchemy,
> Alembic, and oslo.db, e.g. [1][2][3][4]. The Neutron folks were well ahead of
> the curve as usual and also have their own (which is where I got the idea from).
> The projects you mention above could do with an equivalent job and my guess is
> that the process of getting there will highlight quite a bit of work that they
> need to do. They need to start at that asap (and tbh really should have started
> at it a long time ago as they've had over 2 years of a warning [5]).
> 
> Cheers,
> Stephen
> 
> [1] https://review.opendev.org/c/openstack/barbican/+/888308
> [2] https://review.opendev.org/c/openstack/placement/+/886229
> [3] https://review.opendev.org/c/openstack/cinder/+/886152
> [4] https://review.opendev.org/c/openstack/glance/+/889066
> [5] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html

FYI, I also fell into the trap of castellan 4.2.0. I'm writing this here 
for others *not* to do the same mistake as me: do not upgrade, or Cinder 
will fail its unit tests, and only 4.1.0 is the upper bound. Switching 
back to 4.1.0 made Cinder build correctly for me.

The good thing with castellan is, I forgot to upload it to Experimental, 
so to the contrary of oslo.db, it's okish for me ... :)

I hope that helps others,
Cheers,

Thomas Goirand (zigo)



From nguyenhuukhoinw at gmail.com  Thu Sep 14 22:37:43 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Fri, 15 Sep 2023 05:37:43 +0700
Subject: [openstack][skyline] Some works with skyline
In-Reply-To: <CAGe_KfzDWz5eLRgxg=9a8e0k2yd1LOV==0rrAqXm05bAb-+aEg@mail.gmail.com>
References: <CABAODRcqw1xhfaue-XGWthxxaHi_z6KSdxEb3qg=qB6X1FmHbw@mail.gmail.com>
 <CAGe_KfzDWz5eLRgxg=9a8e0k2yd1LOV==0rrAqXm05bAb-+aEg@mail.gmail.com>
Message-ID: <CABAODRfRp8zhwc3swaHCpEPQnPs3_q8MTi1caHKZMFaAM564uw@mail.gmail.com>

Hello.
I will try to add after it works properly. because I need to convert units.
If more people use Skyline and other projects, Openstack will become more
great. I will contribute because I use open source.
Nguyen Huu Khoi


On Thu, Sep 14, 2023 at 10:37?PM Roger Rivera <roger.riverac at gmail.com>
wrote:

> Hi Nguyen
>
> This looks great! Congratulations Nguyen. Adding monitoring is an
> excellent contribution. Hopefully we start to see some traction on Skyline
> as I do also agree it is a phenomenal project that adds value to the
> OpenStack ecosystem. Would be awesome to see it integrate monitoring,
> metering, and maybe even billing for public-cloud use cases.
>
> Thanks again,
>
> Roger
>
> On Tue, Sep 12, 2023 at 11:45?AM Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com> wrote:
>
>> Hello guys.
>> I am working on Skyline.
>>
>> I can integrate my monitor tab on it.
>>
>> I will try to do something about it. If it works properly, I can
>> contribute.
>>
>> It is a very nice project. I hope it will grow and grow in the future.
>>
>> Thanks Skyline Team.
>>
>>
>> [image: image.png]
>>
>> Nguyen Huu Khoi
>>
>
>
> --
> *Roger Rivera*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/92963d78/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 248643 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/92963d78/attachment-0001.png>

From ralonsoh at redhat.com  Fri Sep 15 13:01:55 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 15 Sep 2023 15:01:55 +0200
Subject: [neutron] Neutron drivers meeting cancelled
Message-ID: <CAECr9X67wK05jDh+QtrGn7ECMNot-PUysd=N_N4Fgg9GtVoaDg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/5f80c20f/attachment.htm>

From elod.illes at est.tech  Fri Sep 15 16:05:32 2023
From: elod.illes at est.tech (=?iso-8859-1?Q?El=F5d_Ill=E9s?=)
Date: Fri, 15 Sep 2023 16:05:32 +0000
Subject: [release] Release countdown for week R-2, Sep 18-22
Message-ID: <VI1P18901MB0751D27425E663D35EB9BB10FFF6A@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>

Development Focus
-----------------

At this point we should have release candidates (RC1 or recent intermediary
release) for all the 2023.2 Bobcat deliverables. Teams should be working
on any release-critical bugs that would require another RC or intermediary
release before the final release.

Warning
-------

This is a special note to teams about issues regarding oslo.db and
castellan deliverables. Please be aware that new releases are about to be
sent out. For details, see the mail thread:

https://lists.openstack.org/pipermail/openstack-discuss/2023-September/035100.html

Actions
-------

Early in the week, the release team will be proposing stable/2023.2 branch
creation for all deliverables that have not branched yet, using the latest
available 2023.2 Bobcat release as the branch point. If your team is ready
to go for creating that branch, please let us know by leaving a +1 on these
patches.

If you would like to wait for another release before branching, you can -1
the patch and update it later in the week with the new release you would
like to use. By the end of the week the release team will merge those
patches though, unless an exception is granted.

Once stable/2023.2 branches are created, if a release-critical bug is
detected, you will need to fix the issue in the master branch first, then
backport the fix to the stable/2023.2 branch before releasing out of the
stable/2023.2 branch.

After all of the cycle-with-rc projects have branched we will branch
devstack, grenade, and the requirements repos. This will effectively open
them up for 2024.1 Caracal development, though the focus should still be on
finishing up 2023.2 Bobcat until the final release.

For projects with translations, watch for any translation patches coming
through and merge them quickly. A new release should be produced so that
translations are included in the final 2023.2 Bobcat release.

Finally, now is a good time to finalize release notes. In particular,
consider adding any relevant "prelude" content. Release notes are
targeted for the downstream consumers of your project, so it would be
great to include any useful information for those that are going to pick
up and use or deploy the 2023.2 Bobcat version of your project.

Upcoming Deadlines & Dates
--------------------------

Final RC deadline: September 28th, 2023 (R-1 week)
Final 2023.2 Bobcat release: October 4th, 2023
2024.1 Caracal Virtual PTG - October 23-27, 2023
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230915/0e70c5ed/attachment.htm>

From nguyenhuukhoinw at gmail.com  Sun Sep 17 07:16:04 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sun, 17 Sep 2023 14:16:04 +0700
Subject: [openstack][skyline]Menu route problem.
Message-ID: <CABAODReyqEJvka_nso=2NRiPoE8vTsMPM7eyv8L6PMsubWwoCg@mail.gmail.com>

Hello guys.

I am working on Skyline and I followed

https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-12-Menu-introduction.md

https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-13-Route-introduction.md

I add layouts/menu.jsx
#####
   {
      path: '/konitor',
      name: t('Konitor'),
      key: /konitor',
      icon: <DatabaseOutlined />,
      children: [
        {
          path: '/konitor/konitork',
          name: t('Konitork'),
          key: 'konitork',
          level: 1,
        }
      ],
    }

I put my component in

pages/konitor/containers/Konitork/index.jsx

#######
import React, { Component } from 'react';
import { inject, observer } from 'mobx-react';


export class Konitork extends Component {
   render() {
    return (
      <div>nhk oi</div>
    );
  }
}
export default observer(Konitork);

Here is my routes/index.js

#####

import BaseLayout from '../../../layouts/Basic';
import Konitork from '../containers/Konitork';
import Instance from  '../containers/Instance';
const PATH = '/konitor';
export default [
  {
    path: PATH,
    component: BaseLayout,
    routes: [
      { path: `${PATH}/konitork`, component: Konitork, exact: true },
    ],
  },
];

When click on Menu. Konitor>>Konitork. It return 404. although I have
x.x.x.x:9999/konitor/konitork.

Pls correct me. Thank you much.

Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230917/01340160/attachment.htm>

From damian at bulira.pl  Sun Sep 17 16:52:12 2023
From: damian at bulira.pl (Damian Bulira)
Date: Sun, 17 Sep 2023 18:52:12 +0200
Subject: [barbican][cinder] Business Software License in new Vault
Message-ID: <CANoT_xuBZvLTZNTYwtV0Zfbwq3ekPSQBpbz7JeiLGFck2OmAww@mail.gmail.com>

Hi Guys,

Recently Hashicorp changed their product licensing from MPL to BSL. Did any
of you carry out research on the impact of this change in regard to using
Vault as a backend in Barbican and/or Cinder for both private and public
clouds? Any thoughts about that?

Cheers,
Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230917/466b621e/attachment.htm>

From rafaa.haji3 at gmail.com  Mon Sep 18 09:29:14 2023
From: rafaa.haji3 at gmail.com (Rafa)
Date: Mon, 18 Sep 2023 11:29:14 +0200
Subject: [nova] Live migration of a RAM intensive instance failed
In-Reply-To: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
References: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
Message-ID: <CALOxu45QP7jY6pWx8_8_PbRY+e5tic4J8=83f+ado3JgQiQoDw@mail.gmail.com>

As I can read and understand from the source compute logs,
the memory is copied over successfully and there is no migration timeout.
But after the instance is paused there is something wrong happening.
I first thought it could be the short migration downtime (default=500ms),
that's why I increased the "live_migration_downtime" to higher values
(max was 300000ms; just for testing:) ) and nothing changed.

And the error message doesn't say much either.

I don't really want to use post-copy as it can lead to data loss.

Auto Converge doesn't seem to help either.



Am Fr., 15. Sept. 2023 um 13:56 Uhr schrieb <smooney at redhat.com>:
>
> On Thu, 2023-09-14 at 19:07 +0200, Rafa wrote:
> > > Hi, could you share logs from the target compute node as well?
> >
> > yes, here: https://paste.openstack.org/show/blpJE8krA1N6PVaLTVF0/
> >
>
> if the vm is under heavy memory load then its advisable ot use post-copy live migration.
>
> in general live migration is not intened to be used with a vm under load
> as there is no gurenettee that it will ever complete. post-copy live migration
> can signifcantly increae the probablity that a vm under load will live migrate
> in a reasonabel amount of time.
>
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_post_copy
>
> auto converge can also help but tis less important
>
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_auto_converge
>


From thierry at openstack.org  Mon Sep 18 10:04:40 2023
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 18 Sep 2023 12:04:40 +0200
Subject: [largescale-sig] Next meeting: September 20, 8utc
Message-ID: <38ff495a-68e5-2f00-fa7f-8e643a555e9d@openstack.org>

Hi everyone,

The Large Scale SIG will be meeting this Wednesday in 
#openstack-operators on OFTC IRC, at 8UTC, our APAC+EU-friendly time. I 
will be chairing.

You can doublecheck how that UTC time translates locally at:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230920T08

Feel free to add topics to the agenda:
https://etherpad.opendev.org/p/large-scale-sig-meeting

Regards,

-- 
Thierry Carrez


From smooney at redhat.com  Mon Sep 18 10:06:56 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Mon, 18 Sep 2023 11:06:56 +0100
Subject: [barbican][cinder] Business Software License in new Vault
In-Reply-To: <CANoT_xuBZvLTZNTYwtV0Zfbwq3ekPSQBpbz7JeiLGFck2OmAww@mail.gmail.com>
References: <CANoT_xuBZvLTZNTYwtV0Zfbwq3ekPSQBpbz7JeiLGFck2OmAww@mail.gmail.com>
Message-ID: <e1795d129c022f5699c3c7307f2ac39c27c8efc5.camel@redhat.com>

On Sun, 2023-09-17 at 18:52 +0200, Damian Bulira wrote:
> Hi Guys,
> 
> Recently Hashicorp changed their product licensing from MPL to BSL. Did any
> of you carry out research on the impact of this change in regard to using
> Vault as a backend in Barbican and/or Cinder for both private and public
> clouds? Any thoughts about that?

im not that familiar with vault or barbican but unless we are importing code form
vault it should nova no impact on the licensing of the barbican code base.

i belive we actully use https://github.com/openstack/castellan as an indirection layer
in any openstack project that talks to vault.

if the BSL which is not generally accpted as a opensouce lisnce is incompatble with apache2
we woudl have to drop vault support if we were now calling any bsl code.

assumign we are using non CLIs or non bsl clinent libs we shoudl be unaffected by the chagne
however it may have implicatoins for deployers both new and existing.

looking at it looks like its written in terms of vaults http api.
https://github.com/openstack/castellan/blob/master/castellan/key_manager/vault_key_manager.py
as a result castellan should be insulated form this change and proejcts like nova that only interact
via castallan should be fine.  barbincan appears to be using castellan at first glance too 
https://github.com/openstack/barbican/blob/c8e3dc14e6225f1d400131434e8afec0aa410ae7/barbican/plugin/vault_secret_store.py#L65

so i think form a code licening point of view we are ok.
that does not mean we hould nessisarly endorce the use of vault going forward but i honestly dont
know enough about the politic or details of the bsl change to really comment on that.

if its not already a cpabality of barbican now might be a good time to investiage support for secrete migration between
secrete backends...


> 
> Cheers,
> Damian



From michel.jouvin at ijclab.in2p3.fr  Mon Sep 18 10:13:04 2023
From: michel.jouvin at ijclab.in2p3.fr (Michel Jouvin)
Date: Mon, 18 Sep 2023 12:13:04 +0200
Subject: [nova] Live migration of a RAM intensive instance failed
In-Reply-To: <CALOxu45QP7jY6pWx8_8_PbRY+e5tic4J8=83f+ado3JgQiQoDw@mail.gmail.com>
References: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
 <CALOxu45QP7jY6pWx8_8_PbRY+e5tic4J8=83f+ado3JgQiQoDw@mail.gmail.com>
Message-ID: <a445e17c-ca03-1713-8bb8-a537a7e3e4bf@ijclab.in2p3.fr>

Hi,

post-copy looks to meas a very attractive approach for these 
heavy-loaded VMs but I didn't understand that there is an inherent risk 
of data-loss (except if there is an implementation bug)... Are you sure?

Michel

Le 18/09/2023 ? 11:29, Rafa a ?crit?:
> As I can read and understand from the source compute logs,
> the memory is copied over successfully and there is no migration timeout.
> But after the instance is paused there is something wrong happening.
> I first thought it could be the short migration downtime (default=500ms),
> that's why I increased the "live_migration_downtime" to higher values
> (max was 300000ms; just for testing:) ) and nothing changed.
>
> And the error message doesn't say much either.
>
> I don't really want to use post-copy as it can lead to data loss.
>
> Auto Converge doesn't seem to help either.
>
>
>
> Am Fr., 15. Sept. 2023 um 13:56 Uhr schrieb <smooney at redhat.com>:
>> On Thu, 2023-09-14 at 19:07 +0200, Rafa wrote:
>>>> Hi, could you share logs from the target compute node as well?
>>> yes, here: https://paste.openstack.org/show/blpJE8krA1N6PVaLTVF0/
>>>
>> if the vm is under heavy memory load then its advisable ot use post-copy live migration.
>>
>> in general live migration is not intened to be used with a vm under load
>> as there is no gurenettee that it will ever complete. post-copy live migration
>> can signifcantly increae the probablity that a vm under load will live migrate
>> in a reasonabel amount of time.
>>
>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_post_copy
>>
>> auto converge can also help but tis less important
>>
>> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_auto_converge
>>


From smooney at redhat.com  Mon Sep 18 10:42:41 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Mon, 18 Sep 2023 11:42:41 +0100
Subject: [nova] Live migration of a RAM intensive instance failed
In-Reply-To: <a445e17c-ca03-1713-8bb8-a537a7e3e4bf@ijclab.in2p3.fr>
References: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
 <CALOxu45QP7jY6pWx8_8_PbRY+e5tic4J8=83f+ado3JgQiQoDw@mail.gmail.com>
 <a445e17c-ca03-1713-8bb8-a537a7e3e4bf@ijclab.in2p3.fr>
Message-ID: <8607bf6d3c3ac588885aaa1e608634432d7b4941.camel@redhat.com>

On Mon, 2023-09-18 at 12:13 +0200, Michel Jouvin wrote:
> Hi,
> 
> post-copy looks to meas a very attractive approach for these 
> heavy-loaded VMs but I didn't understand that there is an inherent risk 
> of data-loss (except if there is an implementation bug)... Are you sure?

a simplifed  view of how post-copy works is it intially does a copy of the vm memroy, then if the vm is not
loaded it just sync complete the migration as normal, if it detect a substiatal delta in the memory since the inial copy
happened it enters post copy mode. how post-copy mode work is the dirty pages are marked as dirty on the dest and the
vm resumes form the dest, in the background qemu continue to copy the dirty pages form the souce to the dest
and if the gust every tries to read form a dirty page it gets retrived on demand from the souce.
all write in post copy mode are made to the dest.

the possibelty for data loss comos form 2 sources
1.) if the qemu process on the source craches or is terminated by say an OOM event on the source host then
any uncopied memory is lost.
2.) if one of your top of rack switches explodes and you have a network partation or the connection
over which the data is being copied is broken then the migraiton will fail.

so in both cases an external event causes the souce vm to be unreaachable form the dest.
that means the runign vm on the dest cant access the required info. this can in some cases cause data-loss

without post-copy the senario 2 woudl not cause data loss and would have just caused the migration to be aborted.
the vm woudl have continued to run on the souce node. senario 1 would have caused the data-loss
regradless of doing a migrations so that is kind of irrelevent. i.e. if the vm gets killed as a resutl of an OOM event
then any uncommited disk writes or any data in memory is goign to be lost even if you are not live migrating it.

you just have to descied if you feeel comfortable with the possiblity fo the vm crashing if there is a network
partition. this should be a very very rare event or you have bigger probelmes in your datacenter then slow migrations
but its why we dont ebale postcopy by default upstream. we do enable it by default in our downstream product for what
its worth because we beilve the risk is minimal and when you are doing an emergency drainging fo a host due to hardware
failures defaultign to a config that is likely to succeed is generally more desirable.

so tl;dr 2 is the reason for the data-loss comment.

> 
> Michel
> 
> Le 18/09/2023 ? 11:29, Rafa a ?crit?:
> > As I can read and understand from the source compute logs,
> > the memory is copied over successfully and there is no migration timeout.
> > But after the instance is paused there is something wrong happening.
> > I first thought it could be the short migration downtime (default=500ms),
> > that's why I increased the "live_migration_downtime" to higher values
> > (max was 300000ms; just for testing:) ) and nothing changed.
> > 
> > And the error message doesn't say much either.
> > 
> > I don't really want to use post-copy as it can lead to data loss.
> > 
> > Auto Converge doesn't seem to help either.
> > 
> > 
> > 
> > Am Fr., 15. Sept. 2023 um 13:56 Uhr schrieb <smooney at redhat.com>:
> > > On Thu, 2023-09-14 at 19:07 +0200, Rafa wrote:
> > > > > Hi, could you share logs from the target compute node as well?
> > > > yes, here: https://paste.openstack.org/show/blpJE8krA1N6PVaLTVF0/
> > > > 
> > > if the vm is under heavy memory load then its advisable ot use post-copy live migration.
> > > 
> > > in general live migration is not intened to be used with a vm under load
> > > as there is no gurenettee that it will ever complete. post-copy live migration
> > > can signifcantly increae the probablity that a vm under load will live migrate
> > > in a reasonabel amount of time.
> > > 
> > > https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_post_copy
> > > 
> > > auto converge can also help but tis less important
> > > 
> > > https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_auto_converge
> > > 
> 



From rafaa.haji3 at gmail.com  Mon Sep 18 10:49:39 2023
From: rafaa.haji3 at gmail.com (Rafa)
Date: Mon, 18 Sep 2023 12:49:39 +0200
Subject: [nova] Live migration of a RAM intensive instance failed
In-Reply-To: <a445e17c-ca03-1713-8bb8-a537a7e3e4bf@ijclab.in2p3.fr>
References: <CALOxu46K5U20nd0khLqCjvMwi9OHQwCWJA-Z0dLCsUw0DmtUsw@mail.gmail.com>
 <CALOxu45QP7jY6pWx8_8_PbRY+e5tic4J8=83f+ado3JgQiQoDw@mail.gmail.com>
 <a445e17c-ca03-1713-8bb8-a537a7e3e4bf@ijclab.in2p3.fr>
Message-ID: <CALOxu45YDVLHh_i0d1F1DO2rkbw71iKba+JeVmQ5ZdbzVb=VVA@mail.gmail.com>

I didn't mean to imply that post-copy always results in data loss.
But this is possible if the network connection between source and
destination host is disconnected during the post-copy operation.

Am Mo., 18. Sept. 2023 um 12:14 Uhr schrieb Michel Jouvin
<michel.jouvin at ijclab.in2p3.fr>:
>
> Hi,
>
> post-copy looks to meas a very attractive approach for these
> heavy-loaded VMs but I didn't understand that there is an inherent risk
> of data-loss (except if there is an implementation bug)... Are you sure?
>
> Michel
>
> Le 18/09/2023 ? 11:29, Rafa a ?crit :
> > As I can read and understand from the source compute logs,
> > the memory is copied over successfully and there is no migration timeout.
> > But after the instance is paused there is something wrong happening.
> > I first thought it could be the short migration downtime (default=500ms),
> > that's why I increased the "live_migration_downtime" to higher values
> > (max was 300000ms; just for testing:) ) and nothing changed.
> >
> > And the error message doesn't say much either.
> >
> > I don't really want to use post-copy as it can lead to data loss.
> >
> > Auto Converge doesn't seem to help either.
> >
> >
> >
> > Am Fr., 15. Sept. 2023 um 13:56 Uhr schrieb <smooney at redhat.com>:
> >> On Thu, 2023-09-14 at 19:07 +0200, Rafa wrote:
> >>>> Hi, could you share logs from the target compute node as well?
> >>> yes, here: https://paste.openstack.org/show/blpJE8krA1N6PVaLTVF0/
> >>>
> >> if the vm is under heavy memory load then its advisable ot use post-copy live migration.
> >>
> >> in general live migration is not intened to be used with a vm under load
> >> as there is no gurenettee that it will ever complete. post-copy live migration
> >> can signifcantly increae the probablity that a vm under load will live migrate
> >> in a reasonabel amount of time.
> >>
> >> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_post_copy
> >>
> >> auto converge can also help but tis less important
> >>
> >> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_auto_converge
> >>
>


From tobias.urdin at binero.com  Mon Sep 18 11:42:24 2023
From: tobias.urdin at binero.com (Tobias Urdin)
Date: Mon, 18 Sep 2023 11:42:24 +0000
Subject: [barbican][cinder] Business Software License in new Vault
In-Reply-To: <e1795d129c022f5699c3c7307f2ac39c27c8efc5.camel@redhat.com>
References: <CANoT_xuBZvLTZNTYwtV0Zfbwq3ekPSQBpbz7JeiLGFck2OmAww@mail.gmail.com>
 <e1795d129c022f5699c3c7307f2ac39c27c8efc5.camel@redhat.com>
Message-ID: <67AA20B7-B63A-4F81-A24D-B891392A0F9D@binero.com>

The code part is not a issue, I think this question is mostly directed towards operators
using Vault as the backend (backend storage with an API essentially) for Barbican.

I?m also very interested in this topic, my idea was to email their licensing department and simply
ask unless somebody here has an answer already.

Best regards
Tobias

> On 18 Sep 2023, at 12:06, smooney at redhat.com wrote:
> 
> On Sun, 2023-09-17 at 18:52 +0200, Damian Bulira wrote:
>> Hi Guys,
>> 
>> Recently Hashicorp changed their product licensing from MPL to BSL. Did any
>> of you carry out research on the impact of this change in regard to using
>> Vault as a backend in Barbican and/or Cinder for both private and public
>> clouds? Any thoughts about that?
> 
> im not that familiar with vault or barbican but unless we are importing code form
> vault it should nova no impact on the licensing of the barbican code base.
> 
> i belive we actully use https://github.com/openstack/castellan as an indirection layer
> in any openstack project that talks to vault.
> 
> if the BSL which is not generally accpted as a opensouce lisnce is incompatble with apache2
> we woudl have to drop vault support if we were now calling any bsl code.
> 
> assumign we are using non CLIs or non bsl clinent libs we shoudl be unaffected by the chagne
> however it may have implicatoins for deployers both new and existing.
> 
> looking at it looks like its written in terms of vaults http api.
> https://github.com/openstack/castellan/blob/master/castellan/key_manager/vault_key_manager.py
> as a result castellan should be insulated form this change and proejcts like nova that only interact
> via castallan should be fine.  barbincan appears to be using castellan at first glance too 
> https://github.com/openstack/barbican/blob/c8e3dc14e6225f1d400131434e8afec0aa410ae7/barbican/plugin/vault_secret_store.py#L65
> 
> so i think form a code licening point of view we are ok.
> that does not mean we hould nessisarly endorce the use of vault going forward but i honestly dont
> know enough about the politic or details of the bsl change to really comment on that.
> 
> if its not already a cpabality of barbican now might be a good time to investiage support for secrete migration between
> secrete backends...
> 
> 
>> 
>> Cheers,
>> Damian
> 
> 


From msgm68 at gmail.com  Mon Sep 18 12:27:16 2023
From: msgm68 at gmail.com (Mostafa Salari)
Date: Mon, 18 Sep 2023 15:57:16 +0330
Subject: [Ceilometer] neither gnocchi nor file publisher receive any data or
 metric
Message-ID: <CAGQ+h=3f02wshZQsd-R-nGuG4V6J2d7TJ0noYjfojfm-Uhunpg@mail.gmail.com>

Hi. how can i find a simple, correct, ceilometer configuration for "yoga"
version of openstack?
1) I followed this instruction guide
<https://docs.openstack.org/ceilometer/latest/install/> step by step!
2) I installed devstack with enabled ceilometer (and gnocchi as backend)
but after both tries mentioned above, i did not see any metric.
I also changed the publisher from gnocchi:// into file:// but the result
did not change.

cat /etc/ceilometer/ceilometer.conf:
[DEFAULT]
transport_url = rabbit://stackrabbit:bsvbr5pzLpN0szN84v3m at 127.0.0.1:5672/
use_syslog = True

[oslo_messaging_notifications]
topics = notifications
driver = messagingv2

[coordination]
backend_url = redis://localhost:6379

[notification]
workers = 4

[cache]
backend_argument = url:redis://localhost:6379
backend_argument = distributed_lock:True
backend_argument = db:0
backend_argument = redis_expiration_time:600
backend = dogpile.cache.redis
enabled = True

[service_credentials]
auth_url = http://127.0.0.1/identity
region_name = RegionOne
password = bsvbr5pzLpN0szN84v3m
username = ceilometer
project_name = service
project_domain_id = default
user_domain_id = default
auth_type = password

[keystone_authtoken]
memcached_servers = localhost:11211
cafile = /opt/stack/data/ca-bundle.pem
project_domain_name = Default
project_name = service
user_domain_name = Default
password = bsvbr5pzLpN0szN84v3m
username = ceilometer
auth_url = http://127.0.0.1/identity
interface = public
auth_type = password


_________________________________________
cat /etc/ceilometer/pipeline.yaml:
---
sources:
    - name: meter_source
      meters:
          - "*"
      sinks:
          - meter_sink
sinks:
    - name: meter_sink
      publishers:
          - file:///tmp/ceilofile?json
#          - gnocchi://?archive_policy=low&filter_project=service

____________________________
cat /etc/ceilometer/polling.yaml
---
sources:
    - name: all_pollsters
      interval: 300
      meters:
        - "*"

_____________________________
root at os-aio:/# cat /etc/gnocchi/gnocchi.conf

[DEFAULT]
debug = True
coordination_url = redis://localhost:6379

[indexer]
url = mysql+pymysql://
root:bsvbr5pzLpN0szN84v3m at 127.0.0.1/gnocchi?charset=utf8

[storage]
redis_url = redis://localhost:6379
driver = redis

[metricd]
metric_processing_delay = 5

[api]
auth_mode = keystone

[keystone_authtoken]
memcached_servers = localhost:11211
cafile = /opt/stack/data/ca-bundle.pem
project_domain_name = Default
project_name = service
user_domain_name = Default
password = bsvbr5pzLpN0szN84v3m
username = gnocchi
auth_url = http://127.0.0.1/identity
interface = public
auth_type = password
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/48926e0e/attachment.htm>

From ykarel at redhat.com  Mon Sep 18 13:32:45 2023
From: ykarel at redhat.com (Yatin Karel)
Date: Mon, 18 Sep 2023 19:02:45 +0530
Subject: [neutron] CI meeting on 18.09.2023 cancelled
Message-ID: <CAPU8nTGfqT4ygF9+i2ur=bcVn9M+PBATkXKHv6Syd6eLyfWTBQ@mail.gmail.com>

Hello Neutron Team !!

I will be out tomorrow for a public holiday, so cancelling the CI meeting.
Sorry for the short notice.

See You at the next meeting on 25th of September.

Thanks and Regards
Yatin Karel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/ea9e68a5/attachment.htm>

From fungi at yuggoth.org  Mon Sep 18 13:55:02 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 18 Sep 2023 13:55:02 +0000
Subject: [barbican][cinder][tc] Business Software License in new Vault
In-Reply-To: <CANoT_xuBZvLTZNTYwtV0Zfbwq3ekPSQBpbz7JeiLGFck2OmAww@mail.gmail.com>
References: <CANoT_xuBZvLTZNTYwtV0Zfbwq3ekPSQBpbz7JeiLGFck2OmAww@mail.gmail.com>
Message-ID: <20230918135502.rxoe4nmaye6ndddl@yuggoth.org>

On 2023-09-17 18:52:12 +0200 (+0200), Damian Bulira wrote:
> Recently Hashicorp changed their product licensing from MPL to
> BSL. Did any of you carry out research on the impact of this
> change in regard to using Vault as a backend in Barbican and/or
> Cinder for both private and public clouds? Any thoughts about
> that?

I brought it up last month in the #openstack-tc IRC channel, and
there was some brief discussion but nothing concrete:

https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2023-08-10.log.html

If there are strong concerns, we do have an (infrequently-used)
mailing list for legal/licensing topics as well:
https://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/6271774c/attachment.sig>

From mnasiadka at gmail.com  Mon Sep 18 14:34:03 2023
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Mon, 18 Sep 2023 16:34:03 +0200
Subject: [kolla] [ptg] Kolla 2024.1 (Caracal) PTG planning
Message-ID: <7CCDA5E3-5F2A-4EE2-8B1B-9BFE9E143223@gmail.com>

Hello All,

The 2024.1 (Caracal) virtual PTG is approaching and will be held between 23-27 October, 2023.

I?ve created a usual etherpad [1] where you can post your topic proposals and we?ll discuss them

For dates - we have been usually meeting on two/three days:
There were requests on the Bobcat PTG to make these time slots more Europe friendly (e.g. earlier in the day and not finish at 8pm) and host a slot that is Americas/Asia friendly (if needed) - so I associated each day with a Doodle Poll - let?s try to work out best times for most of us.

1. Kolla/Kolla-Ansible topics day 1 - 4 hours 
Doodle: https://doodle.com/meeting/participate/id/dyXZN9nb
2. Kolla/Kolla-Ansible topics day 2 - 4 hours (including Kolla Operator Hour)
Doodle: https://doodle.com/meeting/participate/id/aO8WxqLb
3. Kayobe topics day - 2 hours
Doodle: https://doodle.com/meeting/participate/id/e5LmZExd

NOTE: If there are participants interested from other timezones that proposed times in the Doodle poll would not fit - please reply to this email and we?ll work out a dedicated slot.

Please add your topics timely so they can be arranged as per your preferences, see you at the PTG!

[1] https://etherpad.opendev.org/p/kolla-caracal-ptg

Thanks,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/c9a04d1d/attachment.htm>

From ykarel at redhat.com  Mon Sep 18 14:44:11 2023
From: ykarel at redhat.com (Yatin Karel)
Date: Mon, 18 Sep 2023 20:14:11 +0530
Subject: [neutron] CI meeting on 19.09.2023 cancelled
In-Reply-To: <CAPU8nTGfqT4ygF9+i2ur=bcVn9M+PBATkXKHv6Syd6eLyfWTBQ@mail.gmail.com>
References: <CAPU8nTGfqT4ygF9+i2ur=bcVn9M+PBATkXKHv6Syd6eLyfWTBQ@mail.gmail.com>
Message-ID: <CAPU8nTFOHNHFAq6F4J9Y9PwwQkCd19eHtdwS7yqZVYxQpsD8OA@mail.gmail.com>

Correction: Meeting Cancelled for tomorrow 19.09.2023

On Mon, Sep 18, 2023 at 7:02?PM Yatin Karel <ykarel at redhat.com> wrote:

> Hello Neutron Team !!
>
> I will be out tomorrow for a public holiday, so cancelling the CI meeting.
> Sorry for the short notice.
>
> See You at the next meeting on 25th of September.
>
> Thanks and Regards
> Yatin Karel
>


-- 
Thanks and Regards
Yatin Karel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/f644eede/attachment-0001.htm>

From geguileo at redhat.com  Mon Sep 18 14:49:33 2023
From: geguileo at redhat.com (Gorka Eguileor)
Date: Mon, 18 Sep 2023 16:49:33 +0200
Subject: [cinder] Map Availability Zone to Volume Type
In-Reply-To: <SN6PR04MB39824478449E0EC18A0D08E4F8E4A@SN6PR04MB3982.namprd04.prod.outlook.com>
References: <SN6PR04MB39824478449E0EC18A0D08E4F8E4A@SN6PR04MB3982.namprd04.prod.outlook.com>
Message-ID: <20230918144933.qy73s2jqpt52akff@localhost>

On 01/09, Jahns, Jay wrote:
> Hi,
>
> We have a multi-AZ environment where we launch instances with bootable volumes. When we specify AZ, we need to have a specific volume type in that AZ selected to launch to. Right now, the __DEFAULT__ volume type is used.
>
> Normally, that would work, since there is 1 backend in each AZ; however, we need to be able to use the key/value RESKEY:availability_zones to pin a volume type to an AZ, so we can use specific key/values in creating the volume.
>
> It is 2 separate backends in the environment.
>
> I see this bug:
> https://bugs.launchpad.net/cinder/+bug/1999706
>
> And this change:
> https://review.opendev.org/c/openstack/cinder/+/868539
>
> Is there anything we can do to help expedite adding this functionality? It seems that it was supposed to already be in.
>
> Thanks,
>
> Jay

Hi Jay,

I believe this is a valid and reasonable feature, unfortunately the
patch you are referencing has been abandoned, and as I have mentioned in
the review, I think the solution requires some discussion.

Not sure if this requires a proper spec or if it's enough to just have a
discussion in a PTG.

For example, I think the default volume type should be given priority
over other volume types if it can meet the AZ request (which the patch
doesn't do).

I would say that this requires someone to champion the effort leading
the discussion and implementing the code, unit tests and possibly
tempest tests.

Regards,
Gorka.



From ces.eduardo98 at gmail.com  Mon Sep 18 16:28:32 2023
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Mon, 18 Sep 2023 13:28:32 -0300
Subject: [manila] Manila Bugsquash Sep 19th - Sep 21st
Message-ID: <CAE51gQLRYM6DrPczsfe9fBfFLxUR8RQR-=Xd2WmthcvFC3X34A@mail.gmail.com>

Hello, Zorillas! As agreed in the previous weekly meeting, our bugsquash
will run from September 19th to September 21st.

The kick off call will be held on Tuesday, Sep 19th at 14:30 UTC using
meetpad [1].

We will use the Manila weekly meeting on Thursday at 15 UTC as a checkpoint.

If you plan to work on a bug that is not on the list [2], feel free to add
it.

Looking forward to seeing you there!

[1] https://meetpad.opendev.org/manilabobcatbugsquash
[2] https://etherpad.opendev.org/p/6VZ5-sbYiSy0hygRZZ6c

Regards,
carloss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/a34b2e33/attachment.htm>

From jay at gr-oss.io  Mon Sep 18 17:58:31 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Mon, 18 Sep 2023 10:58:31 -0700
Subject: [ironic] Mass retirement of old branches due to config errs
In-Reply-To: <CA+sTGNeGnb_sAtHm0HQ0LNLpP6oe0-P2LoXR-_iB5_RsC2VBxw@mail.gmail.com>
References: <CA+sTGNeGnb_sAtHm0HQ0LNLpP6oe0-P2LoXR-_iB5_RsC2VBxw@mail.gmail.com>
Message-ID: <CA+sTGNes4BiFsTAcL0VYdtmuPn=GzxVS8bCRhGpjFaR5WvWU-Q@mail.gmail.com>

I have taken action on this announced branch retirement.

A summary of merge requests created (which will retire the branch on merge)
and manual actions taken below. Once these changes are merged, all
zuul-config-errors for Ironic will be resolved.

ironic-prometheus-exporter
- https://review.opendev.org/c/openstack/releases/+/895702 EOL
ironic-prometheus-exporter stable/train
- bugfix/2.1 branch manually retired; tip commit tagged as bugfix-2.1-eol
-- git tag -s -a bugfix-2.1-eol -m "EOL bugfix/2.1"
98e48dad7680ba4593d80fb225a6b5d2254f783a
-- git push gerrit bugfix-2.1-eol
-- git push -d gerrit bugfix/2.1

networking-generic-switch
- https://review.opendev.org/c/openstack/releases/+/895705 Fix/EOL
networking-generic-switch pike
-- This was strange; the stable/pike branch existed but had no deliverables
yaml file. It appears stable/ocata for this was in a similar state at one
point, and fixed by adding the file with EOL ifnormation, so I pushed a
change which I hope will lead to the pike branch being retired+tagged as
normal in the same manner.
- https://review.opendev.org/c/openstack/releases/+/895707 EOL
networking-generic-switch stable/train
- https://review.opendev.org/c/openstack/releases/+/895709 EOL
networking-generic-switch stable/ussuri
- https://review.opendev.org/c/openstack/releases/+/895711 EOL
networking-generic-switch stable/victoria
- https://review.opendev.org/c/openstack/releases/+/895712 EOL
networking-generic-switch stable/wallaby
- https://review.opendev.org/c/openstack/releases/+/895713 EOL
networking-generic-switch stable/xena

python-ironicclient
- https://review.opendev.org/c/openstack/releases/+/895714 EOL
python-ironicclient stable/train
- https://review.opendev.org/c/openstack/releases/+/895717 EOL
python-ironicclient stable/ussuri
- https://review.opendev.org/c/openstack/releases/+/895719 EOL
python-ironicclient stable/victoria
- https://review.opendev.org/c/openstack/releases/+/895720 EOL
python-ironicclient stable/wallaby
- https://review.opendev.org/c/openstack/releases/+/895721 EOL
python-ironicclient stable/xena


Thanks,
Jay Faulkner
Ironic PTL

On Wed, Aug 23, 2023 at 1:21?PM Jay Faulkner <jay at gr-oss.io> wrote:

> Hi all,
>
> Ironic is one of the major offenders remaining in the work to cleanup Zuul
> config errors. To resolve these issues, it's my plan to retire any impacted
> branches unless a contributor volunteers to clean them up. I will give
> folks until at least September 1, 2023, to object before I begin to take
> action.
>
> These branches have been broken for at least one year, and have gotten no
> patches or releases in that time. It's clear they have little need to
> continue existing.
>
> Please look at https://zuul.opendev.org/t/openstack/config-errors for the
> full list of potentially impacted branches; I will list here as best I can:
>
> openstack/ironic-prometheus-exporter
> - bugfix/2.1
> - stable/train
>
> openstack/networking-generic-switch
> - stable/pike
> - stable/train
> - stable/ussuri
> - stable/victoria
> - stable/wallaby
> - stable/xena
>
> openstack/python-ironicclient
> - stable/train
> - stable/ussuri
> - stable/victoria
> - stable/wallaby
> - stable/xena
> - Note: stable/yoga is also in the config errors list, but is considered
> maintained and cannot be retired at this time. I will work to remove
> failing jobs and get this zuul config fixed manuallt.
>
>
>
> As an additional note, the following branches were retired months ago, but
> due to a bug were recreated. They have been fully deleted (again):
>
> openstack/ironic-python-agent
> - bugfix/8.0
>
> openstack/ironic
> - bugfix/18.0
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/a033a607/attachment.htm>

From mtomaska at redhat.com  Mon Sep 18 18:17:01 2023
From: mtomaska at redhat.com (Miro Tomaska)
Date: Mon, 18 Sep 2023 14:17:01 -0400
Subject: [neutron] Bug Deputy Report September 11 - 17
Message-ID: <CAGvgoLBpPwwwDL7p0G8s6PZ=Tq0ZD-NHsUGbaKHFzE+4-JLjTA@mail.gmail.com>

Hello All,

I was the neutron bug deputy last week (Sept 11-17). Here is what is new:

High:
-https://bugs.launchpad.net/neutron/+bug/2035325 FDB entries grows
indefinitely
Assigned: Luis Tomas

- https://bugs.launchpad.net/neutron/+bug/2035382
"TestMonitorDaemon._run_monitor"
failing radomly, initial message not written
Assigned: Miro Tomaska

- https://bugs.launchpad.net/neutron/+bug/2035578 [stable branches]
devstack-tobiko-neutron job Fails with InvocationError('could not find
executable python', None)
Unassigned

- https://bugs.launchpad.net/neutron/+bug/2036118 VM fails to contact
metadata during live-migration
Assigned: Jakub Libosvar


Medium:
- https://bugs.launchpad.net/neutron/+bug/2035168 Remaining db migrations
for unmaintained Nuage plugin
Unassigned

- https://bugs.launchpad.net/neutron/+bug/2035281 [ML2/OVN] DGP/Floating IP
issue - no flows for chassis gateway port
Assigned: Roberto Bartzen Acosta


Undecided:
- https://bugs.launchpad.net/neutron/+bug/2035230 Port on creation is
returned without the fixed_ips field populated

- https://bugs.launchpad.net/neutron/+bug/2035573 Insertion of a duplicated
ProviderResourceAssociation entry while creating a HA router
Asked for more info

- https://bugs.launchpad.net/neutron/+bug/2035332 [OVN] VLAN networks for
North / South Traffic Broken


Best Regards,
-- 
Miro Tomaska
Senior Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/a0d66dc7/attachment-0001.htm>

From gouthampravi at gmail.com  Mon Sep 18 22:36:34 2023
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Mon, 18 Sep 2023 18:36:34 -0400
Subject: [manila] - Enforcing CephFS pool data placement via backend
 config. options deprecated?
In-Reply-To: <CAMikz55DVXps0+aOYF0-RaCiwMiw=Kf3-Z4Pgt-K1QpgKC7qqA@mail.gmail.com>
References: <CAMikz55DVXps0+aOYF0-RaCiwMiw=Kf3-Z4Pgt-K1QpgKC7qqA@mail.gmail.com>
Message-ID: <CAKSuTPY9YPXY6=WcX+6_d7MG8AZwrZza=kQzpXGRn7mV=QUdoQ@mail.gmail.com>

Hi Paul,

My responses are inline.

On Fri, Sep 15, 2023 at 6:44?AM Paul Browne <pfb29.cam at gmail.com> wrote:
>
> Hello to the list,
>
> In OpenStack releases prior to Wallaby, in CephFS native driver Manila backend config there existed a configuration directive cephfs_volume_path_prefix ;
>
>> # DEPRECATED: The prefix of the cephfs volume path. (string value)
>> # This option is deprecated for removal since Wallaby.
>> # Its value may be silently ignored in the future.
>> # Reason: This option is not used starting with the Nautilus release
>> # of Ceph.
>> #cephfs_volume_path_prefix = /volumes
>
>
> This volume path prefix was usable (and very useful) to set different prefixes in different backends, pointing to different pools in the same backend Ceph cluster e.g. pools backed by storage devices of different characteristics/technology or Ceph CRUSH rule, etc
>
> The pool selection would be done in CephFS via the use of file layout fattributes, file layout inheritance ensuring that data created in sub-directories ends up in the correct Ceph pool.
>
> e.g. two backends using the same Ceph cluster but two different path prefixes hitting different Ceph pools
>
>> [cephfsnative1]
>> driver_handles_share_servers = False
>> share_backend_name = CEPHFS1
>> share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
>> cephfs_conf_path = /etc/ceph/ceph.conf
>> cephfs_auth_id = manila
>> cephfs_cluster_name = ceph
>> cephfs_volume_path_prefix = /volumes-staging
>> cephfs_volume_mode = 777
>> cephfs_enable_snapshots = False
>
>
>>
>> [cephfsnative1_ec]
>> driver_handles_share_servers = False
>> share_backend_name = CEPHFS1_EC
>> share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
>> cephfs_conf_path = /etc/ceph/ceph.conf
>> cephfs_auth_id = manila
>> cephfs_cluster_name = ceph
>> cephfs_volume_path_prefix = /volumes-ec-staging
>> cephfs_volume_mode = 777
>> cephfs_enable_snapshots = False
>
>
> However, since Wallaby this config directive looks to have been deprecated and the default of using a path prefix of only /volumes is possible.Trying to use any other prefix in backend configs is ignored.
>
> Would anyone on the list know why this option was deprecated in Manila code, or was this forced on Manila by upstream Ceph as of Nautilus?
>
> Is there a way to get back to an equivalent functionality?
>
> Currently using only a default path of /volumes means we have lost all flexibility in defining Manila CephFS share data placement using the native CephFS driver.
>
> Possibly using share group types+share groups and some pre-created paths in the root CephFS could get to something like equivalency?
>
> But these paths would need to correspond to the share group UUID, which will only be known after the share group has been created.
>
> So not all that flexible a path, since it requires an interaction between users to communicate the share group ID and Ceph admins to set the correct file layout policy. Putting the path prefix in the backend type removed all of that in a nicely transparent way.
>
> Having just prototyped this, it will work for setting a desired file layout on a pre-defined share group UUID path in the root CephFS, though it's not really ideal or sustainable to be able to do this for dynamically created share groups by users or automation...

The CephFS driver started using Ceph's "mgr/volumes" API to create and
delete CephFS subvolumes (manila shares) in the wallaby release [1].
The manila driver configuration option that you point out was removed
as part of this change. Prior to this change, the driver used a
"ceph_volume_client" python interface. This interface is gone since
the Ceph Pacific release. Functionally, we expected nothing
significant to change during this transition, but we lost some
customizability like the option that you point to. Now "/volumes" is
hard coded in the subvolume paths [2].

Ceph Pacific was the first Ceph release where having multiple CephFS
fileystems in a cluster was fully supported. I'm wondering if using
multiple file systems would allow you to retain the customizability
you're seeking. The difference in segregation would not be apparent in
the export path; but each CephFS filesystem would have its own
dedicated data/metadata pools, and separate MDS daemons on the
cluster. So you'll be able to achieve the provisioning separation that
you're seeking, and more customizability of OSD/pool characteristics.
The CephFS driver in manila can only work with one CephFS filesystem
at a time though (configuration option "cephfs_filesystem_name") [3].
So, just like you're doing currently, you can define multiple CephFS
backends, each with its own "cephfs_filesystem_name".

(For added security, you can manipulate "cephfs_auth_id" and have a
dedicated driver client user for each backend.)

I've copied Patrick and Venky from the CephFS community here. If there
are other options besides this, or if you have other questions, they
might be able to help.

Thanks,
Goutham

[1] https://review.opendev.org/c/openstack/manila/+/779619
[2] https://docs.ceph.com/en/latest/cephfs/fs-volumes/#fs-subvolumes
[3] https://opendev.org/openstack/manila/src/branch/stable/wallaby/manila/share/drivers/cephfs/driver.py#L138-L140


>
> Thanks in advance for any advice,
> Paul Browne


From nguyenhuukhoinw at gmail.com  Tue Sep 19 06:10:18 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 19 Sep 2023 13:10:18 +0700
Subject: [openstack][skyline]Menu route problem.
In-Reply-To: <CABAODReyqEJvka_nso=2NRiPoE8vTsMPM7eyv8L6PMsubWwoCg@mail.gmail.com>
References: <CABAODReyqEJvka_nso=2NRiPoE8vTsMPM7eyv8L6PMsubWwoCg@mail.gmail.com>
Message-ID: <CABAODRe88Mpr2i_Q7b=P5TkD=EW1DeOPBpwoX57bzCCxFecXUQ@mail.gmail.com>

Hello guys.
I update,
When I do similarly things with user-menu. It worked. I just have problem
when Add item on Console menu.
Nguyen Huu Khoi


On Sun, Sep 17, 2023 at 2:16?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello guys.
>
> I am working on Skyline and I followed
>
>
> https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-12-Menu-introduction.md
>
>
> https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-13-Route-introduction.md
>
> I add layouts/menu.jsx
> #####
>    {
>       path: '/konitor',
>       name: t('Konitor'),
>       key: /konitor',
>       icon: <DatabaseOutlined />,
>       children: [
>         {
>           path: '/konitor/konitork',
>           name: t('Konitork'),
>           key: 'konitork',
>           level: 1,
>         }
>       ],
>     }
>
> I put my component in
>
> pages/konitor/containers/Konitork/index.jsx
>
> #######
> import React, { Component } from 'react';
> import { inject, observer } from 'mobx-react';
>
>
> export class Konitork extends Component {
>    render() {
>     return (
>       <div>nhk oi</div>
>     );
>   }
> }
> export default observer(Konitork);
>
> Here is my routes/index.js
>
> #####
>
> import BaseLayout from '../../../layouts/Basic';
> import Konitork from '../containers/Konitork';
> import Instance from  '../containers/Instance';
> const PATH = '/konitor';
> export default [
>   {
>     path: PATH,
>     component: BaseLayout,
>     routes: [
>       { path: `${PATH}/konitork`, component: Konitork, exact: true },
>     ],
>   },
> ];
>
> When click on Menu. Konitor>>Konitork. It return 404. although I have
> x.x.x.x:9999/konitor/konitork.
>
> Pls correct me. Thank you much.
>
> Nguyen Huu Khoi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/fa49e565/attachment.htm>

From fmogollon at vicomtech.org  Tue Sep 19 08:24:11 2023
From: fmogollon at vicomtech.org (Felipe Mogollon)
Date: Tue, 19 Sep 2023 10:24:11 +0200
Subject: Advice on Openstack installer
Message-ID: <CAK8S=-sZFGk4wHBJ1grcR_VwLC_zj8oyu725hvdEePC60YVixg@mail.gmail.com>

Hello to everyone,

I have some experience in installing Openstack but I am having some weird
problems lately.

I have installed Openstack Victoria previously using packstack and
everything was working fine.

Some days ago I tried to deploy a more updated version of Openstack and
previous configuration that I was using with packstack is not working. I
have tried to deploy a new Openstack with packstack and devstack and none
of them were working.

I would like to ask you if you kown a running installer because I have run
out of ideas about what to do.

Regards

Felipe

-- 

[image: Vicomtech] <https://www.vicomtech.org>

Industry Division

Juan Felipe Mogoll?n Rodr?guez
Researcher
Digital Media
fmogollon at vicomtech.org
+(34) 943 30 92 30

The information contained in this electronic message is intended only for
the personal and confidential use of the recipients. If you have received
this e-mail by mistake, please, notify us and delete it.
 Avoid printing this message if it is not strictly necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/db29db0e/attachment.htm>

From nguyenhuukhoinw at gmail.com  Tue Sep 19 08:50:44 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 19 Sep 2023 15:50:44 +0700
Subject: [openstack][skyline]Menu route problem.
In-Reply-To: <CABAODRe88Mpr2i_Q7b=P5TkD=EW1DeOPBpwoX57bzCCxFecXUQ@mail.gmail.com>
References: <CABAODReyqEJvka_nso=2NRiPoE8vTsMPM7eyv8L6PMsubWwoCg@mail.gmail.com>
 <CABAODRe88Mpr2i_Q7b=P5TkD=EW1DeOPBpwoX57bzCCxFecXUQ@mail.gmail.com>
Message-ID: <CABAODRcJvZxioaKYWe_Sw8ZUh6bUzLsky8Vu-NQfe+ZsYxTO8Q@mail.gmail.com>

Hello.
I resolve my problem by add some things related with new menu to

https://github.com/openstack/skyline-console/blob/master/src/pages/basic/routes/index.js

I think we need update docs,

Nguyen Huu Khoi


On Tue, Sep 19, 2023 at 1:10?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello guys.
> I update,
> When I do similarly things with user-menu. It worked. I just have problem
> when Add item on Console menu.
> Nguyen Huu Khoi
>
>
> On Sun, Sep 17, 2023 at 2:16?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello guys.
>>
>> I am working on Skyline and I followed
>>
>>
>> https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-12-Menu-introduction.md
>>
>>
>> https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-13-Route-introduction.md
>>
>> I add layouts/menu.jsx
>> #####
>>    {
>>       path: '/konitor',
>>       name: t('Konitor'),
>>       key: /konitor',
>>       icon: <DatabaseOutlined />,
>>       children: [
>>         {
>>           path: '/konitor/konitork',
>>           name: t('Konitork'),
>>           key: 'konitork',
>>           level: 1,
>>         }
>>       ],
>>     }
>>
>> I put my component in
>>
>> pages/konitor/containers/Konitork/index.jsx
>>
>> #######
>> import React, { Component } from 'react';
>> import { inject, observer } from 'mobx-react';
>>
>>
>> export class Konitork extends Component {
>>    render() {
>>     return (
>>       <div>nhk oi</div>
>>     );
>>   }
>> }
>> export default observer(Konitork);
>>
>> Here is my routes/index.js
>>
>> #####
>>
>> import BaseLayout from '../../../layouts/Basic';
>> import Konitork from '../containers/Konitork';
>> import Instance from  '../containers/Instance';
>> const PATH = '/konitor';
>> export default [
>>   {
>>     path: PATH,
>>     component: BaseLayout,
>>     routes: [
>>       { path: `${PATH}/konitork`, component: Konitork, exact: true },
>>     ],
>>   },
>> ];
>>
>> When click on Menu. Konitor>>Konitork. It return 404. although I have
>> x.x.x.x:9999/konitor/konitork.
>>
>> Pls correct me. Thank you much.
>>
>> Nguyen Huu Khoi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/0ef7436b/attachment-0001.htm>

From mrunge at matthias-runge.de  Tue Sep 19 09:56:57 2023
From: mrunge at matthias-runge.de (Matthias Runge)
Date: Tue, 19 Sep 2023 11:56:57 +0200
Subject: [Ceilometer] neither gnocchi nor file publisher receive any data
 or metric
In-Reply-To: <CAGQ+h=3f02wshZQsd-R-nGuG4V6J2d7TJ0noYjfojfm-Uhunpg@mail.gmail.com>
References: <CAGQ+h=3f02wshZQsd-R-nGuG4V6J2d7TJ0noYjfojfm-Uhunpg@mail.gmail.com>
Message-ID: <1dd5d5f2-1275-9120-05ee-a22cd22c6e04@matthias-runge.de>

On 18/09/2023 14:27, Mostafa Salari wrote:
> Hi. how can i find a simple, correct, ceilometer configuration for 
> "yoga" version of openstack?
> 1) I followed this instruction guide 
> <https://docs.openstack.org/ceilometer/latest/install/>?step by step!
> 2) I installed devstack with enabled ceilometer (and gnocchi as backend)
> but after both tries mentioned above, i did not see any metric.
> I also changed the publisher from gnocchi:// into file:// but the result 
> did not change.


Did you launch a vm, create an image or a volume? Ceilometer listens on 
the rabbit bus and polls service apis, but in order to show something, 
there needs to exist some workload.

If you are asking for help, it's always beneficial to also provide logs.

Matthias



> 
> cat /etc/ceilometer/ceilometer.conf:
> [DEFAULT]
> transport_url = 
> rabbit://stackrabbit:bsvbr5pzLpN0szN84v3m at 127.0.0.1:5672/ 
> <http://stackrabbit:bsvbr5pzLpN0szN84v3m at 127.0.0.1:5672/>
> use_syslog = True
> 
> [oslo_messaging_notifications]
> topics = notifications
> driver = messagingv2
> 
> [coordination]
> backend_url = redis://localhost:6379
> 
> [notification]
> workers = 4
> 
> [cache]
> backend_argument = url:redis://localhost:6379
> backend_argument = distributed_lock:True
> backend_argument = db:0
> backend_argument = redis_expiration_time:600
> backend = dogpile.cache.redis
> enabled = True
> 
> [service_credentials]
> auth_url = http://127.0.0.1/identity <http://127.0.0.1/identity>
> region_name = RegionOne
> password = bsvbr5pzLpN0szN84v3m
> username = ceilometer
> project_name = service
> project_domain_id = default
> user_domain_id = default
> auth_type = password
> 
> [keystone_authtoken]
> memcached_servers = localhost:11211
> cafile = /opt/stack/data/ca-bundle.pem
> project_domain_name = Default
> project_name = service
> user_domain_name = Default
> password = bsvbr5pzLpN0szN84v3m
> username = ceilometer
> auth_url = http://127.0.0.1/identity <http://127.0.0.1/identity>
> interface = public
> auth_type = password
> 
> 
> _________________________________________
> cat /etc/ceilometer/pipeline.yaml:
> ---
> sources:
>  ? ? - name: meter_source
>  ? ? ? meters:
>  ? ? ? ? ? - "*"
>  ? ? ? sinks:
>  ? ? ? ? ? - meter_sink
> sinks:
>  ? ? - name: meter_sink
>  ? ? ? publishers:
>  ? ? ? ? ? - file:///tmp/ceilofile?json
> # ? ? ? ? ?- gnocchi://?archive_policy=low&filter_project=service
> 
> ____________________________
> cat /etc/ceilometer/polling.yaml
> ---
> sources:
>  ? ? - name: all_pollsters
>  ? ? ? interval: 300
>  ? ? ? meters:
>  ? ? ? ? - "*"
> 
> _____________________________
> root at os-aio:/# cat /etc/gnocchi/gnocchi.conf
> 
> [DEFAULT]
> debug = True
> coordination_url = redis://localhost:6379
> 
> [indexer]
> url = 
> mysql+pymysql://root:bsvbr5pzLpN0szN84v3m at 127.0.0.1/gnocchi?charset=utf8 
> <http://root:bsvbr5pzLpN0szN84v3m at 127.0.0.1/gnocchi?charset=utf8>
> 
> [storage]
> redis_url = redis://localhost:6379
> driver = redis
> 
> [metricd]
> metric_processing_delay = 5
> 
> [api]
> auth_mode = keystone
> 
> [keystone_authtoken]
> memcached_servers = localhost:11211
> cafile = /opt/stack/data/ca-bundle.pem
> project_domain_name = Default
> project_name = service
> user_domain_name = Default
> password = bsvbr5pzLpN0szN84v3m
> username = gnocchi
> auth_url = http://127.0.0.1/identity <http://127.0.0.1/identity>
> interface = public
> auth_type = password
> 
> 

-- 
Matthias Runge <mrunge at matthias-runge.de>



From berndbausch at gmail.com  Tue Sep 19 10:14:51 2023
From: berndbausch at gmail.com (berndbausch at gmail.com)
Date: Tue, 19 Sep 2023 19:14:51 +0900
Subject: Advice on Openstack installer
In-Reply-To: <CAK8S=-sZFGk4wHBJ1grcR_VwLC_zj8oyu725hvdEePC60YVixg@mail.gmail.com>
References: <CAK8S=-sZFGk4wHBJ1grcR_VwLC_zj8oyu725hvdEePC60YVixg@mail.gmail.com>
Message-ID: <01c301d9eae2$21b04950$6510dbf0$@gmail.com>

Your problem description is extremely vague. Which versions did you try, what were the symptoms, what did your configuration files look like?

 

The most recent version of OpenStack that I installed with Devstack was Zed. It was successful. Have you tried Kolla-Ansible?

 

Bernd.

 

From: Felipe Mogollon <fmogollon at vicomtech.org> 
Sent: Tuesday, September 19, 2023 5:24 PM
To: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Advice on Openstack installer

 

Hello to everyone,

 

I have some experience in installing Openstack but I am having some weird problems lately.

 

I have installed Openstack Victoria previously using packstack and everything was working fine.

 

Some days ago I tried to deploy a more updated version of Openstack and previous configuration that I was using with packstack is not working. I have tried to deploy a new Openstack with packstack and devstack and none of them were working.

 

I would like to ask you if you kown a running installer because I have run out of ideas about what to do.

 

Regards

 

Felipe


-- 


 <https://www.vicomtech.org/> 

Industry Division

		Juan Felipe Mogoll?n Rodr?guez
Researcher
Digital Media
 <mailto:fmogollon at vicomtech.org> fmogollon at vicomtech.org
+(34) 943 30 92 30

	

The information contained in this electronic message is intended only for the personal and confidential use of the recipients. If you have received this e-mail by mistake, please, notify us and delete it.
  <https://www.vicomtech.org/firmas/html/eco-hand-17.png>  Avoid printing this message if it is not strictly necessary.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/20e692be/attachment.htm>

From satish.txt at gmail.com  Tue Sep 19 11:01:23 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 19 Sep 2023 07:01:23 -0400
Subject: [openstack][skyline]Menu route problem.
In-Reply-To: <CABAODRcJvZxioaKYWe_Sw8ZUh6bUzLsky8Vu-NQfe+ZsYxTO8Q@mail.gmail.com>
References: <CABAODReyqEJvka_nso=2NRiPoE8vTsMPM7eyv8L6PMsubWwoCg@mail.gmail.com>
 <CABAODRe88Mpr2i_Q7b=P5TkD=EW1DeOPBpwoX57bzCCxFecXUQ@mail.gmail.com>
 <CABAODRcJvZxioaKYWe_Sw8ZUh6bUzLsky8Vu-NQfe+ZsYxTO8Q@mail.gmail.com>
Message-ID: <CAPgF-fopQ-DXp_yxnjEAOjR05_nL-7_6ZEWt85DcXuOy5OpLZQ@mail.gmail.com>

You should open feature request or improvement bug report here and assigned
it to yourself https://bugs.launchpad.net/skyline-apiserver

Sometimes people lose thread in mailing lists.

On Tue, Sep 19, 2023 at 4:53?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello.
> I resolve my problem by add some things related with new menu to
>
>
> https://github.com/openstack/skyline-console/blob/master/src/pages/basic/routes/index.js
>
> I think we need update docs,
>
> Nguyen Huu Khoi
>
>
> On Tue, Sep 19, 2023 at 1:10?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello guys.
>> I update,
>> When I do similarly things with user-menu. It worked. I just have problem
>> when Add item on Console menu.
>> Nguyen Huu Khoi
>>
>>
>> On Sun, Sep 17, 2023 at 2:16?PM Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com> wrote:
>>
>>> Hello guys.
>>>
>>> I am working on Skyline and I followed
>>>
>>>
>>> https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-12-Menu-introduction.md
>>>
>>>
>>> https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-13-Route-introduction.md
>>>
>>> I add layouts/menu.jsx
>>> #####
>>>    {
>>>       path: '/konitor',
>>>       name: t('Konitor'),
>>>       key: /konitor',
>>>       icon: <DatabaseOutlined />,
>>>       children: [
>>>         {
>>>           path: '/konitor/konitork',
>>>           name: t('Konitork'),
>>>           key: 'konitork',
>>>           level: 1,
>>>         }
>>>       ],
>>>     }
>>>
>>> I put my component in
>>>
>>> pages/konitor/containers/Konitork/index.jsx
>>>
>>> #######
>>> import React, { Component } from 'react';
>>> import { inject, observer } from 'mobx-react';
>>>
>>>
>>> export class Konitork extends Component {
>>>    render() {
>>>     return (
>>>       <div>nhk oi</div>
>>>     );
>>>   }
>>> }
>>> export default observer(Konitork);
>>>
>>> Here is my routes/index.js
>>>
>>> #####
>>>
>>> import BaseLayout from '../../../layouts/Basic';
>>> import Konitork from '../containers/Konitork';
>>> import Instance from  '../containers/Instance';
>>> const PATH = '/konitor';
>>> export default [
>>>   {
>>>     path: PATH,
>>>     component: BaseLayout,
>>>     routes: [
>>>       { path: `${PATH}/konitork`, component: Konitork, exact: true },
>>>     ],
>>>   },
>>> ];
>>>
>>> When click on Menu. Konitor>>Konitork. It return 404. although I have
>>> x.x.x.x:9999/konitor/konitork.
>>>
>>> Pls correct me. Thank you much.
>>>
>>> Nguyen Huu Khoi
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/0322eb91/attachment-0001.htm>

From nguyenhuukhoinw at gmail.com  Tue Sep 19 11:20:42 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 19 Sep 2023 18:20:42 +0700
Subject: [openstack][skyline]Menu route problem.
In-Reply-To: <CAPgF-fopQ-DXp_yxnjEAOjR05_nL-7_6ZEWt85DcXuOy5OpLZQ@mail.gmail.com>
References: <CABAODReyqEJvka_nso=2NRiPoE8vTsMPM7eyv8L6PMsubWwoCg@mail.gmail.com>
 <CABAODRe88Mpr2i_Q7b=P5TkD=EW1DeOPBpwoX57bzCCxFecXUQ@mail.gmail.com>
 <CABAODRcJvZxioaKYWe_Sw8ZUh6bUzLsky8Vu-NQfe+ZsYxTO8Q@mail.gmail.com>
 <CAPgF-fopQ-DXp_yxnjEAOjR05_nL-7_6ZEWt85DcXuOy5OpLZQ@mail.gmail.com>
Message-ID: <CABAODRc2RnEq-TttJyRHy3y+aJR=v_6+sZjwW2jBMJGwj267Dw@mail.gmail.com>

Hi,
I will, I think it is just a question. So I wont put it on bugs.launchpad.
Thank you.
Nguyen Huu Khoi


On Tue, Sep 19, 2023 at 6:01?PM Satish Patel <satish.txt at gmail.com> wrote:

> You should open feature request or improvement bug report here and
> assigned it to yourself https://bugs.launchpad.net/skyline-apiserver
>
> Sometimes people lose thread in mailing lists.
>
> On Tue, Sep 19, 2023 at 4:53?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello.
>> I resolve my problem by add some things related with new menu to
>>
>>
>> https://github.com/openstack/skyline-console/blob/master/src/pages/basic/routes/index.js
>>
>> I think we need update docs,
>>
>> Nguyen Huu Khoi
>>
>>
>> On Tue, Sep 19, 2023 at 1:10?PM Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com> wrote:
>>
>>> Hello guys.
>>> I update,
>>> When I do similarly things with user-menu. It worked. I just have
>>> problem when Add item on Console menu.
>>> Nguyen Huu Khoi
>>>
>>>
>>> On Sun, Sep 17, 2023 at 2:16?PM Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com> wrote:
>>>
>>>> Hello guys.
>>>>
>>>> I am working on Skyline and I followed
>>>>
>>>>
>>>> https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-12-Menu-introduction.md
>>>>
>>>>
>>>> https://github.com/openstack/skyline-console/blob/master/docs/en/develop/3-13-Route-introduction.md
>>>>
>>>> I add layouts/menu.jsx
>>>> #####
>>>>    {
>>>>       path: '/konitor',
>>>>       name: t('Konitor'),
>>>>       key: /konitor',
>>>>       icon: <DatabaseOutlined />,
>>>>       children: [
>>>>         {
>>>>           path: '/konitor/konitork',
>>>>           name: t('Konitork'),
>>>>           key: 'konitork',
>>>>           level: 1,
>>>>         }
>>>>       ],
>>>>     }
>>>>
>>>> I put my component in
>>>>
>>>> pages/konitor/containers/Konitork/index.jsx
>>>>
>>>> #######
>>>> import React, { Component } from 'react';
>>>> import { inject, observer } from 'mobx-react';
>>>>
>>>>
>>>> export class Konitork extends Component {
>>>>    render() {
>>>>     return (
>>>>       <div>nhk oi</div>
>>>>     );
>>>>   }
>>>> }
>>>> export default observer(Konitork);
>>>>
>>>> Here is my routes/index.js
>>>>
>>>> #####
>>>>
>>>> import BaseLayout from '../../../layouts/Basic';
>>>> import Konitork from '../containers/Konitork';
>>>> import Instance from  '../containers/Instance';
>>>> const PATH = '/konitor';
>>>> export default [
>>>>   {
>>>>     path: PATH,
>>>>     component: BaseLayout,
>>>>     routes: [
>>>>       { path: `${PATH}/konitork`, component: Konitork, exact: true },
>>>>     ],
>>>>   },
>>>> ];
>>>>
>>>> When click on Menu. Konitor>>Konitork. It return 404. although I have
>>>> x.x.x.x:9999/konitor/konitork.
>>>>
>>>> Pls correct me. Thank you much.
>>>>
>>>> Nguyen Huu Khoi
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/e4672fcb/attachment.htm>

From hanguangyu2 at gmail.com  Tue Sep 19 11:32:09 2023
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Tue, 19 Sep 2023 11:32:09 +0000
Subject: Advice on Openstack installer
In-Reply-To: <01c301d9eae2$21b04950$6510dbf0$@gmail.com>
References: <CAK8S=-sZFGk4wHBJ1grcR_VwLC_zj8oyu725hvdEePC60YVixg@mail.gmail.com>
 <01c301d9eae2$21b04950$6510dbf0$@gmail.com>
Message-ID: <CAOirdiXGE=xSSnPgBSjoDyt9M2MGbizabzDBp6w==4jUX5qpKw@mail.gmail.com>

+1 Maybe you can try kolla-ansible[1]?

I have always been able to deploy an environment with it very easily.

[1] https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html

<berndbausch at gmail.com> ?2023?9?19??? 11:15???

> Your problem description is extremely vague. Which versions did you try,
> what were the symptoms, what did your configuration files look like?
>
>
>
> The most recent version of OpenStack that I installed with Devstack was
> Zed. It was successful. Have you tried Kolla-Ansible?
>
>
>
> Bernd.
>
>
>
> *From:* Felipe Mogollon <fmogollon at vicomtech.org>
> *Sent:* Tuesday, September 19, 2023 5:24 PM
> *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
> *Subject:* Advice on Openstack installer
>
>
>
> Hello to everyone,
>
>
>
> I have some experience in installing Openstack but I am having some weird
> problems lately.
>
>
>
> I have installed Openstack Victoria previously using packstack and
> everything was working fine.
>
>
>
> Some days ago I tried to deploy a more updated version of Openstack and
> previous configuration that I was using with packstack is not working. I
> have tried to deploy a new Openstack with packstack and devstack and none
> of them were working.
>
>
>
> I would like to ask you if you kown a running installer because I have run
> out of ideas about what to do.
>
>
>
> Regards
>
>
>
> Felipe
>
>
> --
>
> [image: Vicomtech] <https://www.vicomtech.org/>
>
> Industry Division
>
> *Juan Felipe Mogoll?n Rodr?guez*
> Researcher
> Digital Media
> fmogollon at vicomtech.org
> +(34) 943 30 92 30
>
> The information contained in this electronic message is intended only for
> the personal and confidential use of the recipients. If you have received
> this e-mail by mistake, please, notify us and delete it.
>  Avoid printing this message if it is not strictly necessary.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/0a2fc852/attachment.htm>

From xek at redhat.com  Tue Sep 19 11:42:32 2023
From: xek at redhat.com (Grzegorz Grasza)
Date: Tue, 19 Sep 2023 13:42:32 +0200
Subject: [barbican] PTO - Canceling meetings
Message-ID: <CAPGYNFvobCkyOAUMmZWs07HBgh9xcKvy-ERba-qO7Crr=BYCdw@mail.gmail.com>

Hi all,
 I'm canceling today's barbican meeting, since I'm still on
unscheduled PTO. I also won't be able to attend next week's meeting
(September 26). So see y'all next month.

In the meantime, if something needs urgent attention, please contact
dmendiza or alee.

/ Greg



From noonedeadpunk at gmail.com  Tue Sep 19 11:44:46 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 19 Sep 2023 13:44:46 +0200
Subject: Advice on Openstack installer
In-Reply-To: <CAOirdiXGE=xSSnPgBSjoDyt9M2MGbizabzDBp6w==4jUX5qpKw@mail.gmail.com>
References: <CAK8S=-sZFGk4wHBJ1grcR_VwLC_zj8oyu725hvdEePC60YVixg@mail.gmail.com>
 <01c301d9eae2$21b04950$6510dbf0$@gmail.com>
 <CAOirdiXGE=xSSnPgBSjoDyt9M2MGbizabzDBp6w==4jUX5qpKw@mail.gmail.com>
Message-ID: <CAPd_6AvzineAwCj5ZR5W9tAzQ2t6FO=qBEZR7jUxF5+RcjmdMA@mail.gmail.com>

Then I can also suggest using OpenStack-Ansible :p

I would start from all-in-one deployment:
https://docs.openstack.org/openstack-ansible/latest/user/aio/quickstart.html

On Tue, Sep 19, 2023, 13:37 ??? <hanguangyu2 at gmail.com> wrote:

> +1 Maybe you can try kolla-ansible[1]?
>
> I have always been able to deploy an environment with it very easily.
>
> [1] https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html
>
> <berndbausch at gmail.com> ?2023?9?19??? 11:15???
>
>> Your problem description is extremely vague. Which versions did you try,
>> what were the symptoms, what did your configuration files look like?
>>
>>
>>
>> The most recent version of OpenStack that I installed with Devstack was
>> Zed. It was successful. Have you tried Kolla-Ansible?
>>
>>
>>
>> Bernd.
>>
>>
>>
>> *From:* Felipe Mogollon <fmogollon at vicomtech.org>
>> *Sent:* Tuesday, September 19, 2023 5:24 PM
>> *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
>> *Subject:* Advice on Openstack installer
>>
>>
>>
>> Hello to everyone,
>>
>>
>>
>> I have some experience in installing Openstack but I am having some weird
>> problems lately.
>>
>>
>>
>> I have installed Openstack Victoria previously using packstack and
>> everything was working fine.
>>
>>
>>
>> Some days ago I tried to deploy a more updated version of Openstack and
>> previous configuration that I was using with packstack is not working. I
>> have tried to deploy a new Openstack with packstack and devstack and none
>> of them were working.
>>
>>
>>
>> I would like to ask you if you kown a running installer because I have
>> run out of ideas about what to do.
>>
>>
>>
>> Regards
>>
>>
>>
>> Felipe
>>
>>
>> --
>>
>> [image: Vicomtech] <https://www.vicomtech.org/>
>>
>> Industry Division
>>
>> *Juan Felipe Mogoll?n Rodr?guez*
>> Researcher
>> Digital Media
>> fmogollon at vicomtech.org
>> +(34) 943 30 92 30
>>
>> The information contained in this electronic message is intended only for
>> the personal and confidential use of the recipients. If you have received
>> this e-mail by mistake, please, notify us and delete it.
>>  Avoid printing this message if it is not strictly necessary.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/3c49d778/attachment-0001.htm>

From pi3.14 at tuta.io  Tue Sep 19 12:03:22 2023
From: pi3.14 at tuta.io (pi3.14 at tuta.io)
Date: Tue, 19 Sep 2023 14:03:22 +0200 (CEST)
Subject: Virtual hardware Watchdog for Windows VMs
Message-ID: <NehJhOG--3-9@tuta.io>

Hello,

Is it possible to use virtual hardware watchdog in Windows VMs?
I am emulating the "i6300esb" with QEMU in Linux instances and?
everything works as expected. But when creating Windows?
instances, this device does not show up in the device manager.

- Has anyone tried/tested this before??
- Is this supported?
- Are additional drivers needed?
- I found the following old bug. Has anything changed since then or
are there still no suitable drivers?
https://bugzilla.redhat.com/show_bug.cgi?id=610063


From ygk.kmr at gmail.com  Tue Sep 19 12:08:42 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Tue, 19 Sep 2023 17:38:42 +0530
Subject: Enquiry
Message-ID: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>

Hi All,

Is there any discussion going on among the developers or architects of this
community to change the coding language from Python to Go in the near
future by any chance ? Or, are there any such suggestions from the
community so far,  given the better speed of Go over Python in execution
times ?


Thanks
Y.G,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/c07daa39/attachment.htm>

From satish.txt at gmail.com  Tue Sep 19 12:12:29 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 19 Sep 2023 08:12:29 -0400
Subject: Advice on Openstack installer
In-Reply-To: <CAPd_6AvzineAwCj5ZR5W9tAzQ2t6FO=qBEZR7jUxF5+RcjmdMA@mail.gmail.com>
References: <CAPd_6AvzineAwCj5ZR5W9tAzQ2t6FO=qBEZR7jUxF5+RcjmdMA@mail.gmail.com>
Message-ID: <0745CD6C-DCD6-45A8-90FA-6F0CA3575602@gmail.com>

An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/fce2ec71/attachment.htm>

From satish.txt at gmail.com  Tue Sep 19 12:15:01 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 19 Sep 2023 08:15:01 -0400
Subject: Enquiry
In-Reply-To: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
References: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
Message-ID: <2F630F65-E3AE-4BA6-94A5-10E483B72AB0@gmail.com>

Oh really, first time I heard this. Is it that easy to just convert python to go ?

Agreed on speed though we have switch many applications from py to go just because of multi threading requirement and speeeeeed 

Sent from my iPhone

> On Sep 19, 2023, at 8:11 AM, Gk Gk <ygk.kmr at gmail.com> wrote:
> 
> ?
> Hi All,
> 
> Is there any discussion going on among the developers or architects of this community to change the coding language from Python to Go in the near future by any chance ? Or, are there any such suggestions from the community so far,  given the better speed of Go over Python in execution times ?
> 
> 
> Thanks
> Y.G,


From fungi at yuggoth.org  Tue Sep 19 12:31:34 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 19 Sep 2023 12:31:34 +0000
Subject: Enquiry
In-Reply-To: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
References: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
Message-ID: <20230919123133.snrntkjhpjgu6i5l@yuggoth.org>

On 2023-09-19 17:38:42 +0530 (+0530), Gk Gk wrote:
> Is there any discussion going on among the developers or architects of this
> community to change the coding language from Python to Go in the near
> future by any chance ? Or, are there any such suggestions from the
> community so far,  given the better speed of Go over Python in execution
> times ?

Not really, no. Completely rewriting software in a different
language is a massive undertaking, and when you consider it's taken
13 years to build the software to its current state that's a lot to
rewrite from scratch. There was, at one point, an attempt to replace
a performance-critical subservice of Swift with something written in
Go (called Hummingbird), and while that plan seemed to hold promise
the work on integrating it eventually dried up. Perhaps someone from
that team can speak more to the reasons it didn't take off (pun
intended).

Keep in mind that most of OpenStack's own software is often not in
performance-critical paths, it frequently calls out to other
programs in userspace that are already written in "faster"
languages, so the relative slowness of the Python parts of that
system doesn't necessarily create much additional overhead anyway,
therefore the benefits of rewriting them might not always be as
great as you anticipate. It comes down to a cost vs. benefit ratio,
where the cost of rewriting is very high and the benefits aren't, or
can't clearly be proven as, good enough to outweigh those costs.

Python (well, the popular CPython interpreter anyway) is itself
getting faster too, it's just not been a high priority for their
community until the last few years, but more recently they've
invested a lot of effort in making efficiency and performance
improvements. Take a look at the speed improvements which came out
of the Faster CPython effort in 3.10 and 3.11 as well as the 3.12
release candidates for example, or the free-threading/no-GIL work
for PEP 703. Why rewrite everything into a faster language when you
could instead just make the language it's already written in faster
instead?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/c940bdb5/attachment.sig>

From dtantsur at protonmail.com  Tue Sep 19 12:32:41 2023
From: dtantsur at protonmail.com (Dmitry Tantsur)
Date: Tue, 19 Sep 2023 12:32:41 +0000
Subject: Enquiry
In-Reply-To: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
References: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
Message-ID: <d75625af-8f07-16a2-368e-f6c0808a9a79@protonmail.com>

Hi,

On 9/19/23 14:08, Gk Gk wrote:
> Hi All,
> 
> Is there any discussion going on among the developers or architects of 
> this community to change the coding language from Python to Go in the 
> near future by any chance ? Or, are there any such suggestions from the 
> community so far,? given the better speed of Go over Python in execution 
> times ?

If we're after speed, we need to look at Rust instead (and let the flame 
war begin!)

On a serious note, I don't believe any increment in speed will 
realistically justify the many years (!) of work to replace the existing 
code base exactly.

And many projects won't see much increment of speed at all - namely, all 
projects that are mostly bound by external communications. Take Ironic. 
It may take well over 10 seconds to issue a power on request via IPMI. 
Any win we can make in the surrounding glue code is simply negligible 
compared to that.

I know that Swift was looking at Go because of their specific I/O 
operation requirements, but that's probably it.

At the same time, OpenStack simply don't have enough people to make that 
happen. Nor can we expect the participating companies to spend their 
money on that.

Dmitry

P.S.
Just today, I could not compile a medium-sized Go project because my 
laptop has "only" 12 GiB of RAM, so the OOM killer kicks in. Talk about 
efficiency and performance...

> 
> 
> Thanks
> Y.G,



From namanjain at fynd-external.com  Mon Sep 18 12:47:30 2023
From: namanjain at fynd-external.com (Naman Jain)
Date: Mon, 18 Sep 2023 18:17:30 +0530
Subject: Regarding issues in openstack magnum deployment
Message-ID: <CADRa5GEDGjbQjsWCbcuEiNZ-CZX9NUmiNYitwn94zJdzT6tgSA@mail.gmail.com>

HI


I am creating an openstack cluster where i have deployed, i am followinf
victoria release of installation
https://docs.openstack.org/victoria/install/ keystone placement glance nova
neutron

i have created an vm instance inside my openstack cluster which is working
fine for both inbound and outbound connectivity

now i want to deploy the kubernetes service for which i have installed heat
and magnum when i am creating the kubernetes service using magnum it is
getting stuck in kube_master resource to create for an hour and then gets
failed attaching the SS for reference what could be the reason for this

i am expecting the kubernetes creation process by magnum in openstack

-- 
This email and any attachments may contain confidential, proprietary, or 
legally privileged information and are for the intended recipient only. Any 
other use of emails, such as unauthorized access, disclosure, copying, 
distribution, or reliance on any contents by anyone else, is prohibited and 
unlawful. If you are not the intended recipient, please notify the sender 
immediately and delete the email
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/539528bf/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-09-18 at 4.41.53 PM.png
Type: image/png
Size: 1158493 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230918/539528bf/attachment-0001.png>

From smooney at redhat.com  Tue Sep 19 13:11:32 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Tue, 19 Sep 2023 14:11:32 +0100
Subject: Virtual hardware Watchdog for Windows VMs
In-Reply-To: <NehJhOG--3-9@tuta.io>
References: <NehJhOG--3-9@tuta.io>
Message-ID: <c29e4cbe0cceb585c23339c75492045fb09ab2ed.camel@redhat.com>

On Tue, 2023-09-19 at 14:03 +0200, pi3.14 at tuta.io wrote:
> Hello,
> 
> Is it possible to use virtual hardware watchdog in Windows VMs?
> I am emulating the "i6300esb" with QEMU in Linux instances and?
> everything works as expected. But when creating Windows?
> instances, this device does not show up in the device manager.

so upstream does not generally provide any support for workload runing on openstakc
inclduing the os. the watchdog device model is not currently expsoted as a tunable
via a flavor or image property so configurign it is not currently supprot by nova.
it is hardcoded to?i6300esb so if your windows guest does not have the correct dirver
then it wont work.
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L2458

it looks like libvirt does supprot other models
https://libvirt.org/formatdomain.html#watchdog-devices

and 'itco'is included by default with q35 machine type Since 9.1.0

but its still not clear if windows would even supprot that if we were to make this configurable

you could try setting the machine type to q35 see if that works for you

"""
Having multiple watchdogs is usually not something very common, but be aware that this might happen, for example, when
an implicit watchdog device is added as part of another device. For example the iTCO watchdog being part of the ich9
southbridge, which is used with the q35 machine type. Since 9.1.0
"""
im not sure if the watchdog action would affect the implict iTCO watchdog or not
the default is 'reset' - default, forcefully reset the guest

> 
> - Has anyone tried/tested this before??
this is not test upstream or downstream
we have no windows guest testing upstream and this
is not an offically supported fature in redhats downstream although it
not offically unsupproted meaning you can use it if it works for your use case
but we do not test it with any sepecic os.
> - Is this supported?
offically we support exposing a watchdog device to a guest but that is where our supprot
ends. upstream nova does not provide support for the integration fo a watchdong in any given os.
> - Are additional drivers needed?
this is likely the issue you are encountering
windows is proably misssing the i6300esb driver
> - I found the following old bug. Has anything changed since then or
> are there still no suitable drivers?
> https://bugzilla.redhat.com/show_bug.cgi?id=610063
> 
quickly googleing i dont see refence to one so i woudl assume tha tis still the case 



From satish.txt at gmail.com  Tue Sep 19 13:18:50 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 19 Sep 2023 09:18:50 -0400
Subject: Regarding issues in openstack magnum deployment
In-Reply-To: <CADRa5GEDGjbQjsWCbcuEiNZ-CZX9NUmiNYitwn94zJdzT6tgSA@mail.gmail.com>
References: <CADRa5GEDGjbQjsWCbcuEiNZ-CZX9NUmiNYitwn94zJdzT6tgSA@mail.gmail.com>
Message-ID: <CAPgF-fqGAGViH1AwwKfbwcLCiUWsdMTKTuKWUiCNRbY-a9siBQ@mail.gmail.com>

You should get on to vm itself and check logs. I am sure it will tell you
lots of stories about why it failed. I have found only specific fedora
images work with specific versions of the kube version. There are some
compatibility lists somewhere if you google. After a couple of hits and
trying some images I found only specific images that work with my Xena
deployment.

On Tue, Sep 19, 2023 at 9:13?AM Naman Jain <namanjain at fynd-external.com>
wrote:

> HI
>
>
> I am creating an openstack cluster where i have deployed, i am followinf
> victoria release of installation
> https://docs.openstack.org/victoria/install/ keystone placement glance
> nova neutron
>
> i have created an vm instance inside my openstack cluster which is working
> fine for both inbound and outbound connectivity
>
> now i want to deploy the kubernetes service for which i have installed
> heat and magnum when i am creating the kubernetes service using magnum it
> is getting stuck in kube_master resource to create for an hour and then
> gets failed attaching the SS for reference what could be the reason for this
>
> i am expecting the kubernetes creation process by magnum in openstack
>
> This email and any attachments may contain confidential, proprietary, or
> legally privileged information and are for the intended recipient only. Any
> other use of emails, such as unauthorized access, disclosure, copying,
> distribution, or reliance on any contents by anyone else, is prohibited and
> unlawful. If you are not the intended recipient, please notify the sender
> immediately and delete the email
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/a5527372/attachment.htm>

From damian at bulira.pl  Tue Sep 19 13:19:44 2023
From: damian at bulira.pl (Damian Bulira)
Date: Tue, 19 Sep 2023 15:19:44 +0200
Subject: [barbican][cinder] Business Software License in new Vault
In-Reply-To: <e1795d129c022f5699c3c7307f2ac39c27c8efc5.camel@redhat.com>
References: <CANoT_xuBZvLTZNTYwtV0Zfbwq3ekPSQBpbz7JeiLGFck2OmAww@mail.gmail.com>
 <e1795d129c022f5699c3c7307f2ac39c27c8efc5.camel@redhat.com>
Message-ID: <CANoT_xs+XLA=MZzqKejC4LqZRqY4-4ZaMvXp8rQz+FcLetMGUQ@mail.gmail.com>

Thanks Sean for the input regarding the code base.

I would highly appreciate it if anyone has any input regarding Vault as a
backend and BSL from the cloud provider perspective.

Cheers,
Damian

pon., 18 wrz 2023 o 12:07 <smooney at redhat.com> napisa?(a):

> On Sun, 2023-09-17 at 18:52 +0200, Damian Bulira wrote:
> > Hi Guys,
> >
> > Recently Hashicorp changed their product licensing from MPL to BSL. Did
> any
> > of you carry out research on the impact of this change in regard to using
> > Vault as a backend in Barbican and/or Cinder for both private and public
> > clouds? Any thoughts about that?
>
> im not that familiar with vault or barbican but unless we are importing
> code form
> vault it should nova no impact on the licensing of the barbican code base.
>
> i belive we actully use https://github.com/openstack/castellan as an
> indirection layer
> in any openstack project that talks to vault.
>
> if the BSL which is not generally accpted as a opensouce lisnce is
> incompatble with apache2
> we woudl have to drop vault support if we were now calling any bsl code.
>
> assumign we are using non CLIs or non bsl clinent libs we shoudl be
> unaffected by the chagne
> however it may have implicatoins for deployers both new and existing.
>
> looking at it looks like its written in terms of vaults http api.
>
> https://github.com/openstack/castellan/blob/master/castellan/key_manager/vault_key_manager.py
> as a result castellan should be insulated form this change and proejcts
> like nova that only interact
> via castallan should be fine.  barbincan appears to be using castellan at
> first glance too
>
> https://github.com/openstack/barbican/blob/c8e3dc14e6225f1d400131434e8afec0aa410ae7/barbican/plugin/vault_secret_store.py#L65
>
> so i think form a code licening point of view we are ok.
> that does not mean we hould nessisarly endorce the use of vault going
> forward but i honestly dont
> know enough about the politic or details of the bsl change to really
> comment on that.
>
> if its not already a cpabality of barbican now might be a good time to
> investiage support for secrete migration between
> secrete backends...
>
>
> >
> > Cheers,
> > Damian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/e7eb7a79/attachment-0001.htm>

From jay at gr-oss.io  Tue Sep 19 14:46:16 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Tue, 19 Sep 2023 07:46:16 -0700
Subject: [tc] Technical Committee next weekly meeting Today, September 19, 2023
Message-ID: <CA+sTGNe1NsptNRW2AeYcTuXoyowqc7mjKaH1xReZgnV-M8if9g@mail.gmail.com>

Hi all,

This is a reminder that the next weekly Technical Committee meeting is to
be held today on Tuesday, September 12 2023 at 1800 UTC on #openstack-tc on
OFTC IRC.

Please find the agenda below:


   - Roll call
   - Follow up on past action items
      - No action items last meeting
   - Gate health check
   - 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,
Jay Faulkner
TC Vice-Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/3eb5b75c/attachment.htm>

From kieske at osism.tech  Tue Sep 19 15:55:07 2023
From: kieske at osism.tech (Sven Kieske)
Date: Tue, 19 Sep 2023 17:55:07 +0200
Subject: Enquiry
In-Reply-To: <20230919123133.snrntkjhpjgu6i5l@yuggoth.org>
References: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
 <20230919123133.snrntkjhpjgu6i5l@yuggoth.org>
Message-ID: <f0674fd7e741008d3a0a9ff87c717200df04d1ce.camel@osism.tech>

Am Dienstag, dem 19.09.2023 um 12:31 +0000 schrieb Jeremy Stanley:
> Not really, no. Completely rewriting software in a different
> language is a massive undertaking, and when you consider it's taken
> 13 years to build the software to its current state that's a lot to
> rewrite from scratch. 

agreed

> 
> Keep in mind that most of OpenStack's own software is often not in
> performance-critical paths, it frequently calls out to other
> programs in userspace that are already written in "faster"
> languages, so the relative slowness of the Python parts of that
> system doesn't necessarily create much additional overhead anyway,
> therefore the benefits of rewriting them might not always be as
> great as you anticipate. It comes down to a cost vs. benefit ratio,
> where the cost of rewriting is very high and the benefits aren't, or
> can't clearly be proven as, good enough to outweigh those costs.
> 
> Python (well, the popular CPython interpreter anyway) is itself
> getting faster too, it's just not been a high priority for their
> community until the last few years, but more recently they've
> invested a lot of effort in making efficiency and performance
> improvements. Take a look at the speed improvements which came out
> of the Faster CPython effort in 3.10 and 3.11 as well as the 3.12
> release candidates for example, or the free-threading/no-GIL work
> for PEP 703. Why rewrite everything into a faster language when you
> could instead just make the language it's already written in faster
> instead?

well, if you have ever run any moderate sized openstack cluster
you must disagree here. of course many openstack components
*are* performance sensitive, especially if you run k8s on top of it
which can hammer the api servers with thousands requests per second.

I don't even want to go into arguments about general efficiency of
computing, preservation of resources and "green it" [0].

a good rewrite would possibly use rust instead of golang (there, I said
it), because it's easier to integrate with python[1] as it has a better
FFI story than golang, from what I read online. This way this could be
done in an incremental way. This would imho be the only feasible
approach, which could also yield new developers interested in
openstack/cloud computing.

e.g. Artem rewrote the current openstack cli client in rust and while
the current cli in python is really slow for larger clouds, it is fast
in rust[2]. So there is some work being done, although it's very very
early days.

the results of the poc where shown at the last public cloud sig
meeting, which was quite interesting.

But I do agree, as said above, that it's hard to do, and there seems
sadly to be not much buy-in from the community at large just yet.

[0]:
https://thenewstack.io/which-programming-languages-use-the-least-electricity/
[1]: https://pyo3.rs
[2]:
https://lists.openstack.org/pipermail/openstack-discuss/2023-August/034934.html

kind regards

-- 
Sven Kieske
Senior Cloud Engineer

Mail: kieske at osism.tech
Web: https://osism.tech

OSISM GmbH
Teckstra?e 62 / 70190 Stuttgart / Deutschland

Gesch?ftsf?hrer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139



From fungi at yuggoth.org  Tue Sep 19 16:13:48 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 19 Sep 2023 16:13:48 +0000
Subject: Enquiry
In-Reply-To: <f0674fd7e741008d3a0a9ff87c717200df04d1ce.camel@osism.tech>
References: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
 <20230919123133.snrntkjhpjgu6i5l@yuggoth.org>
 <f0674fd7e741008d3a0a9ff87c717200df04d1ce.camel@osism.tech>
Message-ID: <20230919161348.sestcd3q4hc2wjhv@yuggoth.org>

On 2023-09-19 17:55:07 +0200 (+0200), Sven Kieske wrote:
[...]
> e.g. Artem rewrote the current openstack cli client in rust and
> while the current cli in python is really slow for larger clouds,
> it is fast in rust[2]. So there is some work being done, although
> it's very very early days.
> 
> the results of the poc where shown at the last public cloud sig
> meeting, which was quite interesting.
[...]

It's worth keeping in mind that any rewrite, even into the same
language, is likely to yield performance improvements. When redoing
an application from scratch you have the opportunity to make
different architectural/design decisions, free yourself from cruft
and historical baggage, and so on. It's hard to say "OpenStackCLI
rewritten in Rust is faster because Rust is faster than Python"
unless the design is architecturally the same (which is also almost
impossible to achieve between different languages anyway). Most of
the current CLI's startup slowness is because of the mechanism it
relies on for finding plugins, and even just redoing that with a
more performant alternative would make a huge difference.

Regardless, that's a cool feat, and like I said focusing on bits in
performance-critical paths which can take advantage of specific
language features makes more sense than blindly rewriting everything
we've got in another language. But also Python is getting better. It
would be cool to try comparing DevStack/Tempest job durations and
resource consumption between 3.8 and 3.11 for example (or 3.12 once
we can).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/3a1eee23/attachment.sig>

From jay at gr-oss.io  Tue Sep 19 19:02:00 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Tue, 19 Sep 2023 12:02:00 -0700
Subject: [elections] Deadline to vote approaching!
Message-ID: <CA+sTGNcuUrLJFkN1SbVK7T0Wi+dd1_LrS1+RhBfnOrJcwk5Lng@mail.gmail.com>

Hey all,

There is a little over 24 hours remaining in the election for OpenStack
Technical Committee and for OpenStack-Helm PTL. Eligible voters who have
opted-in to election email should have a ballot in their inbox from civs at
cornell dot edu. Ballots are documented to close Sep 20, 2023 23:45 UTC.

Thanks for participating!

--
Jay Faulkner
TC Vice-Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/d4eea957/attachment.htm>

From kennelson11 at gmail.com  Tue Sep 19 21:45:19 2023
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 19 Sep 2023 16:45:19 -0500
Subject: [ptls][URGENT] Bobcat Release: DPUs, GPUs, and FGPAs, oh my!
Message-ID: <CAJ6yrQhk=2zao92dbrGWDb2zO9E5P=o9DONZe3R7Sd0jCROs8g@mail.gmail.com>

Hello folks!

So, as the OpenInfra Foundation has begun putting together the release
marking materials for the Bobcat release, we noticed a trend focused on
enabling hardware and increasing utilization. Ironic in particular had an
excellent cycle highlight about DPUs[1]. We wanted to quickly reach out and
see if there were any cycle highlights that projects maybe haven't
published in a review, but are related to this topic. Please respond ASAP
as we are moving fast on finalizing the press release.

Also, if there is anything related coming in Caracal, we might be able to
call that out as well, though I know it's quite early to know what might be
landing in 2024.1.

If there are other cycle highlights that should get called out as well,
definitely push the patches and add me as a reviewer!

-Kendall Nelson

[1] https://releases.openstack.org/bobcat/highlights.html#ironic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230919/694aa054/attachment.htm>

From ygk.kmr at gmail.com  Wed Sep 20 07:10:08 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Wed, 20 Sep 2023 12:40:08 +0530
Subject: Enquiry
In-Reply-To: <2F630F65-E3AE-4BA6-94A5-10E483B72AB0@gmail.com>
References: <CAJreVFz4LcDNnKNMKeEZ02dd+oeb2KX0phYa+XT6NwTzXnKfvg@mail.gmail.com>
 <2F630F65-E3AE-4BA6-94A5-10E483B72AB0@gmail.com>
Message-ID: <CAJreVFxOYbz465V4yGT=Mi7Bw=iBDjctgnj=fcP+qNyg05ba=g@mail.gmail.com>

I am just asking the community if there are any such plans for the future.
I am not saying that it is decided on .

On Tue, Sep 19, 2023 at 5:45?PM Satish Patel <satish.txt at gmail.com> wrote:

> Oh really, first time I heard this. Is it that easy to just convert python
> to go ?
>
> Agreed on speed though we have switch many applications from py to go just
> because of multi threading requirement and speeeeeed
>
> Sent from my iPhone
>
> > On Sep 19, 2023, at 8:11 AM, Gk Gk <ygk.kmr at gmail.com> wrote:
> >
> > ?
> > Hi All,
> >
> > Is there any discussion going on among the developers or architects of
> this community to change the coding language from Python to Go in the near
> future by any chance ? Or, are there any such suggestions from the
> community so far,  given the better speed of Go over Python in execution
> times ?
> >
> >
> > Thanks
> > Y.G,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/15e3f0d5/attachment-0001.htm>

From kamil.madac at gmail.com  Wed Sep 20 07:51:21 2023
From: kamil.madac at gmail.com (Kamil Madac)
Date: Wed, 20 Sep 2023 09:51:21 +0200
Subject: [neutron] Static ip address of subnet dhcp server
Message-ID: <CAP9pT+Ggux5KqiZVNbDtG_5fD_TkDQRHYNTfzj1sTXbQvsvnfA@mail.gmail.com>

Hello OpenStack community,

I'd like to ask whether it's possible to set a static fixed IP address for
a DHCP server within a subnet, especially when using the OVN driver. While
I've come across a blueprint that addresses this topic, I haven't been able
to find any pertinent details in the documentation.

Our primary use case is to maintain IP addresses during the migration of
VMs between two OpenStack clouds.

Any guidance or suggestions would be greatly appreciated.

Thank you!

-- 
Kamil Madac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/5f86f1a8/attachment.htm>

From thierry at openstack.org  Wed Sep 20 08:17:28 2023
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 20 Sep 2023 10:17:28 +0200
Subject: [largescale-sig] Next meeting: September 20, 8utc
In-Reply-To: <38ff495a-68e5-2f00-fa7f-8e643a555e9d@openstack.org>
References: <38ff495a-68e5-2f00-fa7f-8e643a555e9d@openstack.org>
Message-ID: <1dcf1d16-7894-4a98-932e-bf3f580381ce@openstack.org>

Here is the summary of our SIG meeting today.

Attendance was limited so we mostly discussed last-minute details for 
our next OpenInfra Live episode, a deep dive into NIPA Cloud deployment 
tomorrow.

You can read the detailed meeting logs at:

https://meetings.opendev.org/meetings/large_scale_sig/2023/large_scale_sig.2023-09-20-08.00.html

Our next IRC meeting will be Oct 4, 15:00UTC on #openstack-operators on 
OFTC.

Regards,

-- 
-- 
Thierry Carrez (ttx)



From ralonsoh at redhat.com  Wed Sep 20 08:22:27 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Wed, 20 Sep 2023 10:22:27 +0200
Subject: [neutron] Static ip address of subnet dhcp server
In-Reply-To: <CAP9pT+Ggux5KqiZVNbDtG_5fD_TkDQRHYNTfzj1sTXbQvsvnfA@mail.gmail.com>
References: <CAP9pT+Ggux5KqiZVNbDtG_5fD_TkDQRHYNTfzj1sTXbQvsvnfA@mail.gmail.com>
Message-ID: <CAECr9X6cL2k6TuMuTrYziLNvPtyumSTsoRoNbkMYPyCWgMyYSg@mail.gmail.com>

Hello Kamil:

I'm not sure what you are asking for, sorry. In ML2/OVN, the DHCP server is
local (in the same compute node where the VM is spawned) and has no IP
address. The local OVS instance will capture the DHCP requests and reply to
them.

If you are asking for a VM port with a static IP address, this is something
you can currently do creating a port and setting the fixed IP address [1].

Can you share the blueprint you are referring to? How do you plan to
migrate VMs to a different cloud?

Regards.

[1]https://paste.opendev.org/show/bl87sEpUnZttIMxN9fyc/

On Wed, Sep 20, 2023 at 9:52?AM Kamil Madac <kamil.madac at gmail.com> wrote:

> Hello OpenStack community,
>
> I'd like to ask whether it's possible to set a static fixed IP address for
> a DHCP server within a subnet, especially when using the OVN driver. While
> I've come across a blueprint that addresses this topic, I haven't been able
> to find any pertinent details in the documentation.
>
> Our primary use case is to maintain IP addresses during the migration of
> VMs between two OpenStack clouds.
>
> Any guidance or suggestions would be greatly appreciated.
>
> Thank you!
>
> --
> Kamil Madac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/1d1722b5/attachment.htm>

From ralonsoh at redhat.com  Wed Sep 20 09:29:31 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Wed, 20 Sep 2023 11:29:31 +0200
Subject: [ptls][URGENT] Bobcat Release: DPUs, GPUs, and FGPAs, oh my!
In-Reply-To: <CAJ6yrQhk=2zao92dbrGWDb2zO9E5P=o9DONZe3R7Sd0jCROs8g@mail.gmail.com>
References: <CAJ6yrQhk=2zao92dbrGWDb2zO9E5P=o9DONZe3R7Sd0jCROs8g@mail.gmail.com>
Message-ID: <CAECr9X6iT2LZnFYjQHx2g9-XBFA-4y53wpw3ieY2NaUAyfzTdw@mail.gmail.com>

Hello Kendall:

I can confirm that hardware offload (datapath offload in ML2/OVS and
ML2/OVN) is currently used in several deployments and it's being tested
internally in my company. However there are no upstream specific highlights
about this topic right now. In the next cycle (or cycles) our plan is to
create an external CI testing both mechanism drivers with HW NICs.

Regards.

On Tue, Sep 19, 2023 at 11:46?PM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> Hello folks!
>
> So, as the OpenInfra Foundation has begun putting together the release
> marking materials for the Bobcat release, we noticed a trend focused on
> enabling hardware and increasing utilization. Ironic in particular had an
> excellent cycle highlight about DPUs[1]. We wanted to quickly reach out and
> see if there were any cycle highlights that projects maybe haven't
> published in a review, but are related to this topic. Please respond ASAP
> as we are moving fast on finalizing the press release.
>
> Also, if there is anything related coming in Caracal, we might be able to
> call that out as well, though I know it's quite early to know what might be
> landing in 2024.1.
>
> If there are other cycle highlights that should get called out as well,
> definitely push the patches and add me as a reviewer!
>
> -Kendall Nelson
>
> [1] https://releases.openstack.org/bobcat/highlights.html#ironic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/878a1609/attachment.htm>

From kamil.madac at gmail.com  Wed Sep 20 09:35:58 2023
From: kamil.madac at gmail.com (Kamil Madac)
Date: Wed, 20 Sep 2023 11:35:58 +0200
Subject: [neutron] Static ip address of subnet dhcp server
In-Reply-To: <CAECr9X6cL2k6TuMuTrYziLNvPtyumSTsoRoNbkMYPyCWgMyYSg@mail.gmail.com>
References: <CAP9pT+Ggux5KqiZVNbDtG_5fD_TkDQRHYNTfzj1sTXbQvsvnfA@mail.gmail.com>
 <CAECr9X6cL2k6TuMuTrYziLNvPtyumSTsoRoNbkMYPyCWgMyYSg@mail.gmail.com>
Message-ID: <CAP9pT+FkdyWDFCR1Kqkp=B7=yq9-mtuMvFK4CdKxWN3i+=YVkA@mail.gmail.com>

Hi Rodolfo,

Thanks for the response, and sorry for the confusion which can be caused by
my lack of knowledge about how ovn is implemented in openstack. I have seen
following blueprint (not for OVN obviosly):

https://wiki.openstack.org/wiki/Neutron/enable-to-set-dhcp-port-attributes

and somehow thought that dhcp has an ip address assigned also in OVN.

When I checked it once more I found out that device_id of the port has
prefix ovnmeta-, which means that it is not dhcp but metadata agent or
proxy:

$ openstack port show -f table -c id -c fixed_ips -c device_id
4f70acdf-59e9-4252-9f0c-c71eb68baa9a
+-----------+---------------------------------------------------------------------------+
| Field     | Value
            |
+-----------+---------------------------------------------------------------------------+
| device_id | ovnmeta-61d55c5b-adeb-440e-a029-796e783fdc02
             |
| fixed_ips | ip_address='172.16.0.1',
subnet_id='4632d9e5-6918-415e-b752-9f828e57404c' |
| id        | 4f70acdf-59e9-4252-9f0c-c71eb68baa9a
             |
+-----------+---------------------------------------------------------------------------+

Is it possible to set another ip address of this port during creation of
the subnet, or afterwards?

Thanks

On Wed, Sep 20, 2023 at 10:22?AM Rodolfo Alonso Hernandez <
ralonsoh at redhat.com> wrote:

> Hello Kamil:
>
> I'm not sure what you are asking for, sorry. In ML2/OVN, the DHCP server
> is local (in the same compute node where the VM is spawned) and has no IP
> address. The local OVS instance will capture the DHCP requests and reply to
> them.
>
> If you are asking for a VM port with a static IP address, this is
> something you can currently do creating a port and setting the fixed IP
> address [1].
>
> Can you share the blueprint you are referring to? How do you plan to
> migrate VMs to a different cloud?
>
> Regards.
>
> [1]https://paste.opendev.org/show/bl87sEpUnZttIMxN9fyc/
>
> On Wed, Sep 20, 2023 at 9:52?AM Kamil Madac <kamil.madac at gmail.com> wrote:
>
>> Hello OpenStack community,
>>
>> I'd like to ask whether it's possible to set a static fixed IP address
>> for a DHCP server within a subnet, especially when using the OVN driver.
>> While I've come across a blueprint that addresses this topic, I haven't
>> been able to find any pertinent details in the documentation.
>>
>> Our primary use case is to maintain IP addresses during the migration of
>> VMs between two OpenStack clouds.
>>
>> Any guidance or suggestions would be greatly appreciated.
>>
>> Thank you!
>>
>> --
>> Kamil Madac
>>
>

-- 
Kamil Madac <https://kmadac.github.io/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/a4224cca/attachment-0001.htm>

From smooney at redhat.com  Wed Sep 20 11:15:49 2023
From: smooney at redhat.com (smooney at redhat.com)
Date: Wed, 20 Sep 2023 12:15:49 +0100
Subject: [ptls][URGENT] Bobcat Release: DPUs, GPUs, and FGPAs, oh my!
In-Reply-To: <CAECr9X6iT2LZnFYjQHx2g9-XBFA-4y53wpw3ieY2NaUAyfzTdw@mail.gmail.com>
References: <CAJ6yrQhk=2zao92dbrGWDb2zO9E5P=o9DONZe3R7Sd0jCROs8g@mail.gmail.com>
 <CAECr9X6iT2LZnFYjQHx2g9-XBFA-4y53wpw3ieY2NaUAyfzTdw@mail.gmail.com>
Message-ID: <782d35ca7b1fa4693ff096ab5b5d4042a8bc01d1.camel@redhat.com>

On Wed, 2023-09-20 at 11:29 +0200, Rodolfo Alonso Hernandez wrote:
> Hello Kendall:
> 
> I can confirm that hardware offload (datapath offload in ML2/OVS and
> ML2/OVN) is currently used in several deployments and it's being tested
> internally in my company. However there are no upstream specific highlights
> about this topic right now. In the next cycle (or cycles) our plan is to
> create an external CI testing both mechanism drivers with HW NICs.
nova also added suport for DPU in yoga
https://specs.openstack.org/openstack/nova-specs/specs/yoga/implemented/integration-with-off-path-network-backends.html
but there has been significant changes in this area recently.

there may be some new enabling of intel/napatech dpus/smartnice for dpdk based hardware offloads
in both neutorn/nova next cycle. In bobcat 
https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/support-napatech-linkvirtualization-smartnic.html
was prospoed but not completed due to technial reasons. it made some progress but realistically there is more work in
ovs to be done before that is sutable to merge upstream. as it stands the current approach is rather vendor specific
but they are working to make a more vendor neutral approach work so i expect that to continue in caracal or D
while this is relevent to this mail thread i dont think it should be included in any marketing matiral.

you could note that nova/neutron booth already support off-path dpus but i woudl likely omit the napatech spec
since that is still in flux. "off-path" means that the contol plane of the dpu is runing on the dpu not the linux host
wehere nova/neutron runs, in the case of the previous intergration ovn is the contolplane and it runs on the dpu and is
integrated with ml2/ovn in neutron and nova's pci tracker. in the context of the ironic enhancement ironic woudl be used
to provision both the host server OS and the linux/frimware image (with ovn) onto the dpu. that would then be configured
by external tooling (i.e. ansible) to be integrated with neutron ml2/ovn backend and nova.

one low light is a lot of the work around nova <=> cycborg interaction has more or less stopped since the
pandemic and i don't really see that changing anytime soon. The ironic enhancement kind of puts ironic and
cyborg in competition for the management of the dpu lifecycle since that was inteneded to be managed via cycborg not
ironic. It is the reason that cyborg has a rest api to manage the programing of a dpu os image and firmware.
form a nova/neutron point of veiw it does not impact us as we just assume the lifecycle of the dpu is
externally managed and wethere that si ironic or cyborg does not directly impact our usage of the dpu.
> 
> Regards.
> 
> On Tue, Sep 19, 2023 at 11:46?PM Kendall Nelson <kennelson11 at gmail.com>
> wrote:
> 
> > Hello folks!
> > 
> > So, as the OpenInfra Foundation has begun putting together the release
> > marking materials for the Bobcat release, we noticed a trend focused on
> > enabling hardware and increasing utilization. Ironic in particular had an
> > excellent cycle highlight about DPUs[1]. We wanted to quickly reach out and
> > see if there were any cycle highlights that projects maybe haven't
> > published in a review, but are related to this topic. Please respond ASAP
> > as we are moving fast on finalizing the press release.
> > 
> > Also, if there is anything related coming in Caracal, we might be able to
> > call that out as well, though I know it's quite early to know what might be
> > landing in 2024.1.
> > 
> > If there are other cycle highlights that should get called out as well,
> > definitely push the patches and add me as a reviewer!
> > 
> > -Kendall Nelson
> > 
> > [1] https://releases.openstack.org/bobcat/highlights.html#ironic
> > 



From vrook at wikimedia.org  Wed Sep 20 11:21:56 2023
From: vrook at wikimedia.org (Vivian Rook)
Date: Wed, 20 Sep 2023 07:21:56 -0400
Subject: [kolla] change default domain
Message-ID: <CAKxn-9RfFFYsriO-Wv_LG8VKJVxhK_E35TibP5BZnoH4vWoebw@mail.gmail.com>

I'm looking for a setting to change the default domain name from "default"
to "kolla" Does such an option exist in globals.yml?

Thank you!
-- 

*Vivian Rook (They/Them)*
Site Reliability Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/52357ffd/attachment.htm>

From kamil.madac at gmail.com  Wed Sep 20 12:09:03 2023
From: kamil.madac at gmail.com (Kamil Madac)
Date: Wed, 20 Sep 2023 14:09:03 +0200
Subject: [neutron] Static ip address of subnet dhcp server
In-Reply-To: <CAP9pT+FkdyWDFCR1Kqkp=B7=yq9-mtuMvFK4CdKxWN3i+=YVkA@mail.gmail.com>
References: <CAP9pT+Ggux5KqiZVNbDtG_5fD_TkDQRHYNTfzj1sTXbQvsvnfA@mail.gmail.com>
 <CAECr9X6cL2k6TuMuTrYziLNvPtyumSTsoRoNbkMYPyCWgMyYSg@mail.gmail.com>
 <CAP9pT+FkdyWDFCR1Kqkp=B7=yq9-mtuMvFK4CdKxWN3i+=YVkA@mail.gmail.com>
Message-ID: <CAP9pT+GxhmjYtoDhyYQWAdRXVyy+isDxE0S4X-s+QRoN9_ANtw@mail.gmail.com>

OK, I found a solution, so I will post it here if anyone has the same issue.

after creation of new subnet, we need to set new ip address and unset old
one on ovnmeta port:

openstack port set --fixed-ip subnet=<subnet_id>,ip-address=172.16.2.3
<ovnmeta_port_id>
openstack port unset --fixed-ip subnet=<subnet_id>,ip-address=172.16.2.1
<ovnmeta_port_id>

Then when VM is created on compute node, metadata agent sets new IP
in ovnmeta namespace.
If namespace already exists, restart of ovn metadata agent updates the IP
in ovnmeta namespace.



On Wed, Sep 20, 2023 at 11:35?AM Kamil Madac <kamil.madac at gmail.com> wrote:

> Hi Rodolfo,
>
> Thanks for the response, and sorry for the confusion which can be caused
> by my lack of knowledge about how ovn is implemented in openstack. I have
> seen following blueprint (not for OVN obviosly):
>
> https://wiki.openstack.org/wiki/Neutron/enable-to-set-dhcp-port-attributes
>
> and somehow thought that dhcp has an ip address assigned also in OVN.
>
> When I checked it once more I found out that device_id of the port has
> prefix ovnmeta-, which means that it is not dhcp but metadata agent or
> proxy:
>
> $ openstack port show -f table -c id -c fixed_ips -c device_id
> 4f70acdf-59e9-4252-9f0c-c71eb68baa9a
>
> +-----------+---------------------------------------------------------------------------+
> | Field     | Value
>               |
>
> +-----------+---------------------------------------------------------------------------+
> | device_id | ovnmeta-61d55c5b-adeb-440e-a029-796e783fdc02
>              |
> | fixed_ips | ip_address='172.16.0.1',
> subnet_id='4632d9e5-6918-415e-b752-9f828e57404c' |
> | id        | 4f70acdf-59e9-4252-9f0c-c71eb68baa9a
>              |
>
> +-----------+---------------------------------------------------------------------------+
>
> Is it possible to set another ip address of this port during creation of
> the subnet, or afterwards?
>
> Thanks
>
> On Wed, Sep 20, 2023 at 10:22?AM Rodolfo Alonso Hernandez <
> ralonsoh at redhat.com> wrote:
>
>> Hello Kamil:
>>
>> I'm not sure what you are asking for, sorry. In ML2/OVN, the DHCP server
>> is local (in the same compute node where the VM is spawned) and has no IP
>> address. The local OVS instance will capture the DHCP requests and reply to
>> them.
>>
>> If you are asking for a VM port with a static IP address, this is
>> something you can currently do creating a port and setting the fixed IP
>> address [1].
>>
>> Can you share the blueprint you are referring to? How do you plan to
>> migrate VMs to a different cloud?
>>
>> Regards.
>>
>> [1]https://paste.opendev.org/show/bl87sEpUnZttIMxN9fyc/
>>
>> On Wed, Sep 20, 2023 at 9:52?AM Kamil Madac <kamil.madac at gmail.com>
>> wrote:
>>
>>> Hello OpenStack community,
>>>
>>> I'd like to ask whether it's possible to set a static fixed IP address
>>> for a DHCP server within a subnet, especially when using the OVN driver.
>>> While I've come across a blueprint that addresses this topic, I haven't
>>> been able to find any pertinent details in the documentation.
>>>
>>> Our primary use case is to maintain IP addresses during the migration of
>>> VMs between two OpenStack clouds.
>>>
>>> Any guidance or suggestions would be greatly appreciated.
>>>
>>> Thank you!
>>>
>>> --
>>> Kamil Madac
>>>
>>
>
> --
> Kamil Madac <https://kmadac.github.io/>
>


-- 
Kamil Madac <https://kmadac.github.io/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/759c1bc7/attachment.htm>

From maximilian.stinsky at german-edge-cloud.io  Wed Sep 20 10:00:55 2023
From: maximilian.stinsky at german-edge-cloud.io (Maximilian Stinsky)
Date: Wed, 20 Sep 2023 10:00:55 +0000
Subject: [octavia] state of taskflow jobboards
Message-ID: <a90e61f6f61c434f96a147c7dd0a1549@german-edge-cloud.io>

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_flow.jobboard_enabled
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/6bd5bba1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7944 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/6bd5bba1/attachment-0001.bin>

From juliaashleykreger at gmail.com  Wed Sep 20 13:39:31 2023
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Wed, 20 Sep 2023 06:39:31 -0700
Subject: [ptls][URGENT] Bobcat Release: DPUs, GPUs, and FGPAs, oh my!
In-Reply-To: <CAJ6yrQhk=2zao92dbrGWDb2zO9E5P=o9DONZe3R7Sd0jCROs8g@mail.gmail.com>
References: <CAJ6yrQhk=2zao92dbrGWDb2zO9E5P=o9DONZe3R7Sd0jCROs8g@mail.gmail.com>
Message-ID: <CAF7gwdipSj3yvzQMeD7ma8e_UhdsqcFbw0x4JCU_noZe_-soMA@mail.gmail.com>

Realistically the work Ironic has completed this cycle is to enable an
operator to execute steps against a node and a DPU as part of the same
deployment operation. This work is unrelated to past work in ironic to
support "smart nics" (the original marketing name used for DPUs), which was
more about the deploy time networking interactions. Unfortunately, we're
not entirely there as most of this was the underlying substrate and
workflow capabilities. We expect this to begin to be extended to aspects
such as firmware management of the DPU, and we already have reports of
operators using ironic separately to deploy the OS on some DPU models. The
issue is before now, they were entirely disjointed. We expect this to
improve over the next few years, but is also going to take standardization
across the DPU vendor market to really enable. The OPI[0] community is
working on trying to drive standardization, but many of the features and
requirements being discussed will likely force revision in the silicon, in
other words it might be a few years before we see the standardization we're
trying to drive there reach a usable state.

That being said, we anticipate continued work in Caracal.

[0]: https://opiproject.org/

On Tue, Sep 19, 2023 at 2:49?PM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> Hello folks!
>
> So, as the OpenInfra Foundation has begun putting together the release
> marking materials for the Bobcat release, we noticed a trend focused on
> enabling hardware and increasing utilization. Ironic in particular had an
> excellent cycle highlight about DPUs[1]. We wanted to quickly reach out and
> see if there were any cycle highlights that projects maybe haven't
> published in a review, but are related to this topic. Please respond ASAP
> as we are moving fast on finalizing the press release.
>
> Also, if there is anything related coming in Caracal, we might be able to
> call that out as well, though I know it's quite early to know what might be
> landing in 2024.1.
>
> If there are other cycle highlights that should get called out as well,
> definitely push the patches and add me as a reviewer!
>
> -Kendall Nelson
>
> [1] https://releases.openstack.org/bobcat/highlights.html#ironic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/1ee1699b/attachment.htm>

From dwilde at redhat.com  Wed Sep 20 14:26:26 2023
From: dwilde at redhat.com (Dave Wilde)
Date: Wed, 20 Sep 2023 09:26:26 -0500
Subject: [keystone] Meeting cancelled this week
References: <b3f275d8-6262-40b0-ba66-55e3c95a9879@Spark>
Message-ID: <14506418-c080-4e80-92f5-84eead2be4bf@Spark>

Hi folks,

Due to some unforeseen circumstances I need to cancel the Keystone meeting this week.??Please reach out on IRC or via the mailing list if you need anything.

Thanks!

/Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/ea45c381/attachment.htm>

From jobernar at redhat.com  Wed Sep 20 14:38:38 2023
From: jobernar at redhat.com (Jon Bernard)
Date: Wed, 20 Sep 2023 14:38:38 +0000
Subject: Cinder Bug Report 2023-09-20
Message-ID: <ZQsD7hPRXUgJCNb3@localhost>

Hello Argonauts,

Cinder Bug Meeting Etherpad
<https://etherpad.opendev.org/p/cinder-bug-squad-meeting>

Cinder / Undecided

- [Pure Storage] Missing replication pod can cause driver failure on restart
  <https://bugs.launchpad.net/cinder/+bug/2035404>
  - Status: In Progress
- NetApp NFS driver for Cinder may over-provision pools in an active-active configuration
  <https://bugs.launchpad.net/cinder/+bug/2036457>
  - Status: New

OS-Brick / Undecided

- hostnqn file not created automatically
  <https://bugs.launchpad.net/os-brick/+bug/2035606>
  - Status: In Progress
- NVMe-oF cannot connect
  <https://bugs.launchpad.net/os-brick/+bug/2035695>
  - Status: In Progress
- NVMe-oF cannot connect on newer CentOS 9 stream
  <https://bugs.launchpad.net/os-brick/+bug/2035811>
  - Status: In Progress

Thanks,

-- 
Jon



From kristin at openinfra.dev  Wed Sep 20 15:25:32 2023
From: kristin at openinfra.dev (Kristin Barrientos)
Date: Wed, 20 Sep 2023 10:25:32 -0500
Subject: OpenInfra Live - Sept. 21 at 9 a.m. CT / 1400 UTC
Message-ID: <77A8AE78-8902-4689-82A7-3966B2B7B74F@openinfra.dev>

Hi everyone,

This week?s OpenInfra Live episode is brought to you by the OpenStack Large Scale SIG.

Episode: Large Scale Ops Deep Dive: NIPA Cloud

In the "Large Scale Ops Deep Dive" series, a panel of OpenStack operators invites special guests to talk about their deployment and discuss their operations. For this episode, our guests will be Dr. Abhisak Chulya and Charnsilp Chinprasert from NIPA Cloud, Thailand's largest OpenStack public cloud provider.

Speakers: Dr. Abhisak Chulya, Charnsilp Chinprasert, Arnaud Morin, Felix Huettner, Thierry Carrez, Kristin Barrientos

Date and time: Sept. 21 at 9 a.m. CT / 1400 UTC

You can watch us live on:
YouTube: https://www.youtube.com/watch?v=ir9v_UK_MIA
LinkedIn: https://www.linkedin.com/events/7085718563113603072/comments/
WeChat: recording will be posted on OpenStack WeChat after the live stream

Have an idea for a future episode? Share it now at ideas.openinfra.live.

Thanks, 

Kristin Barrientos
Marketing Coordinator 
OpenInfra Foundation




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/ad67d68f/attachment-0001.htm>

From kristin at openinfra.dev  Wed Sep 20 15:28:03 2023
From: kristin at openinfra.dev (Kristin Barrientos)
Date: Wed, 20 Sep 2023 10:28:03 -0500
Subject: [ptls][Bobcat] OpenInfra Live: OpenStack Bobcat 
Message-ID: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/44cb1075/attachment.htm>

From sbauza at redhat.com  Wed Sep 20 16:01:03 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Wed, 20 Sep 2023 18:01:03 +0200
Subject: [ptls][Bobcat] OpenInfra Live: OpenStack Bobcat
In-Reply-To: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>
References: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>
Message-ID: <CALOCmum0g20eqJgM3cxWJkEniYzdGeCwV92s4uYUi4FLqr-z-Q@mail.gmail.com>

Le mer. 20 sept. 2023 ? 17:36, Kristin Barrientos <kristin at openinfra.dev> a
?crit :

> 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.
>
>
Like before, you can count on me for Nova.

-Sylvain


> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/63be18a6/attachment.htm>

From ces.eduardo98 at gmail.com  Wed Sep 20 16:15:12 2023
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Wed, 20 Sep 2023 13:15:12 -0300
Subject: [ptls][Bobcat] OpenInfra Live: OpenStack Bobcat
In-Reply-To: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>
References: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>
Message-ID: <CAE51gQL9UeUGsLWKD-18aH6Sg19V8fkvdYaEVvj_cU-5RjpT-A@mail.gmail.com>

Hello! I'm happy to share the Manila cycle highlights.

Thanks,
carloss

Em qua., 20 de set. de 2023 ?s 12:34, Kristin Barrientos <
kristin at openinfra.dev> escreveu:

> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/de93805d/attachment.htm>

From jay at gr-oss.io  Wed Sep 20 18:03:52 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Wed, 20 Sep 2023 11:03:52 -0700
Subject: [ptls][Bobcat] OpenInfra Live: OpenStack Bobcat
In-Reply-To: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>
References: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>
Message-ID: <CA+sTGNd+nBDtJNN5zod5hHAmK7tQmyQF=pgzDqYbdXsMpzKd2w@mail.gmail.com>

Always happy to talk about Ironic!

-
Jay Faulkner
Ironic PTL

On Wed, Sep 20, 2023 at 8:36?AM Kristin Barrientos <kristin at openinfra.dev>
wrote:

> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230920/8b73a980/attachment-0001.htm>

From rdhasman at redhat.com  Wed Sep 20 22:35:55 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 21 Sep 2023 04:05:55 +0530
Subject: [ptls][Bobcat] OpenInfra Live: OpenStack Bobcat
In-Reply-To: <CA+sTGNd+nBDtJNN5zod5hHAmK7tQmyQF=pgzDqYbdXsMpzKd2w@mail.gmail.com>
References: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>
 <CA+sTGNd+nBDtJNN5zod5hHAmK7tQmyQF=pgzDqYbdXsMpzKd2w@mail.gmail.com>
Message-ID: <CAARK8KQHToR5o85LSqyuOStNByKOBfpaJNeZ1ij2qDhaik1PYQ@mail.gmail.com>

I can volunteer for Cinder like last time.

-
Rajat Dhasmana

On Thu, Sep 21, 2023 at 12:06?AM Jay Faulkner <jay at gr-oss.io> wrote:

> Always happy to talk about Ironic!
>
> -
> Jay Faulkner
> Ironic PTL
>
> On Wed, Sep 20, 2023 at 8:36?AM Kristin Barrientos <kristin at openinfra.dev>
> wrote:
>
>> 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
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/893de4f8/attachment.htm>

From tony at bakeyournoodle.com  Wed Sep 20 23:51:47 2023
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Thu, 21 Sep 2023 09:51:47 +1000
Subject: [all][elections][tc] Technical Committee Election Results
Message-ID: <CAFT5D2T3JRGAEydvngkBF3Q=ysCoQ=6=P-2Sakc_66UAk4aHvg@mail.gmail.com>

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.


From tony at bakeyournoodle.com  Wed Sep 20 23:53:25 2023
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Thu, 21 Sep 2023 09:53:25 +1000
Subject: [all][elections][ptl] Project Team Lead Election Conclusion and
 Results
Message-ID: <CAFT5D2ShvXfMPO+U+BVDCbwipsPLdaCGZ+dWgva0F9ZhLFCm2Q@mail.gmail.com>

Thank you to the electorate, to all those who voted and to all
candidates who put their name forward for Project Team Lead (PTL) in
this election. A healthy, open process breeds trust in our decision
making capability thank you to all those who make this process
possible.

Now for the results of the PTL election process, please join me in
extending congratulations to the following PTLs:

* Adjutant : Dale Smith
* Barbican : Grzegorz Grasza
* Blazar : Pierre Riteau
* Cinder : Rajat Dhasmana
* Cloudkitty : Rafael Weingartner
* Designate : Michael Johnson
* Freezer : ge cong
* Glance : Pranali Deore
* Heat : Takashi Kajinami
* Horizon : Vishal Manchanda
* Ironic : Jay Faulkner
* Keystone : Dave Wilde
* Kolla : Michal Nasiadka
* Kuryr : Roman Dobosz
* Magnum : Jake Yip
* Manila : Carlos Silva
* Masakari : sam sue
* Murano : Rong Zhu
* Neutron : Brian Haley
* Nova : Sylvain Bauza
* Octavia : Gregory Thiemonge
* OpenStack Charms : Felipe Reyes
* OpenStack Helm : Vladimir Kozhukalov
* OpenStackAnsible : Dmitriy Rabotyagov
* OpenStackSDK : Artem Goncharov
* Puppet OpenStack : Takashi Kajinami
* Quality Assurance : Martin Kopec
* Solum : Rong Zhu
* Storlets : Takashi Kajinami
* Swift : Tim Burke
* Tacker : Yasufumi Ogawa
* Telemetry : Erno Kuvaja
* Vitrage : Dmitriy Rabotyagov
* Watcher : chen ke
* Zaqar : Hao Wang
* Zun : Hongbin Lu

Elections:
* OpenStack_Helm: https://civs1.civs.us/cgi-bin/results.pl?id=E_3cf498bb10adc5b8

Election process details and results are also available here:
https://governance.openstack.org/election/

Thank you to all involved in the PTL election process,

Yours Tony.


From songwenping at inspur.com  Thu Sep 21 06:41:51 2023
From: songwenping at inspur.com (=?utf-8?B?QWxleCBTb25nICjlrovmloflubMp?=)
Date: Thu, 21 Sep 2023 06:41:51 +0000
Subject: =?utf-8?B?562U5aSNOiBbYWxsXVtlbGVjdGlvbnNdW3B0bF0gUHJvamVjdCBUZWFtIExl?=
 =?utf-8?Q?ad_Election_Conclusion_and_Results?=
In-Reply-To: <CAFT5D2ShvXfMPO+U+BVDCbwipsPLdaCGZ+dWgva0F9ZhLFCm2Q@mail.gmail.com>
References: <CAFT5D2ShvXfMPO+U+BVDCbwipsPLdaCGZ+dWgva0F9ZhLFCm2Q@mail.gmail.com>
Message-ID: <c12fab49d687481d98e10d2dc7d52636@inspur.com>

Hi Tony,

	I have voted for the PTL election for Cyborg projects. The commits donnot merged as below, please accept my election.
	Cyborg: https://review.opendev.org/c/openstack/election/+/893300 
	
Thanks,
Alex

-----????-----
???: Tony Breeds [mailto:tony at bakeyournoodle.com] 
????: 2023?9?21? 7:53
???: OpenStack Discuss <openstack-discuss at lists.openstack.org>; openstack-announce at lists.openstack.org
??: [all][elections][ptl] Project Team Lead Election Conclusion and Results

Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible.

Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs:

* Adjutant : Dale Smith
* Barbican : Grzegorz Grasza
* Blazar : Pierre Riteau
* Cinder : Rajat Dhasmana
* Cloudkitty : Rafael Weingartner
* Designate : Michael Johnson
* Freezer : ge cong
* Glance : Pranali Deore
* Heat : Takashi Kajinami
* Horizon : Vishal Manchanda
* Ironic : Jay Faulkner
* Keystone : Dave Wilde
* Kolla : Michal Nasiadka
* Kuryr : Roman Dobosz
* Magnum : Jake Yip
* Manila : Carlos Silva
* Masakari : sam sue
* Murano : Rong Zhu
* Neutron : Brian Haley
* Nova : Sylvain Bauza
* Octavia : Gregory Thiemonge
* OpenStack Charms : Felipe Reyes
* OpenStack Helm : Vladimir Kozhukalov
* OpenStackAnsible : Dmitriy Rabotyagov
* OpenStackSDK : Artem Goncharov
* Puppet OpenStack : Takashi Kajinami
* Quality Assurance : Martin Kopec
* Solum : Rong Zhu
* Storlets : Takashi Kajinami
* Swift : Tim Burke
* Tacker : Yasufumi Ogawa
* Telemetry : Erno Kuvaja
* Vitrage : Dmitriy Rabotyagov
* Watcher : chen ke
* Zaqar : Hao Wang
* Zun : Hongbin Lu

Elections:
* OpenStack_Helm: https://civs1.civs.us/cgi-bin/results.pl?id=E_3cf498bb10adc5b8

Election process details and results are also available here:
https://governance.openstack.org/election/

Thank you to all involved in the PTL election process,

Yours Tony.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3774 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/44989468/attachment.bin>

From songwenping at inspur.com  Thu Sep 21 06:44:26 2023
From: songwenping at inspur.com (=?utf-8?B?QWxleCBTb25nICjlrovmloflubMp?=)
Date: Thu, 21 Sep 2023 06:44:26 +0000
Subject: =?utf-8?B?562U5aSNOiBbYWxsXVtlbGVjdGlvbnNdW3B0bF0gUHJvamVjdCBUZWFtIExl?=
 =?utf-8?Q?ad_Election_Conclusion_and_Results?=
In-Reply-To: <CAFT5D2ShvXfMPO+U+BVDCbwipsPLdaCGZ+dWgva0F9ZhLFCm2Q@mail.gmail.com>
References: <CAFT5D2ShvXfMPO+U+BVDCbwipsPLdaCGZ+dWgva0F9ZhLFCm2Q@mail.gmail.com>
Message-ID: <480c409f0c8f412d93a859d86e1ea3db@inspur.com>

Hi Tony,

	I have voted for the PTL election for Cyborg project. The commit donnot merged as below, please accept my election.
	Cyborg: https://review.opendev.org/c/openstack/election/+/893300 
	
Thanks,
Alex

-----????-----
???: Tony Breeds [mailto:tony at bakeyournoodle.com] 
????: 2023?9?21? 7:53
???: OpenStack Discuss <openstack-discuss at lists.openstack.org>; openstack-announce at lists.openstack.org
??: [all][elections][ptl] Project Team Lead Election Conclusion and Results

Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible.

Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs:

* Adjutant : Dale Smith
* Barbican : Grzegorz Grasza
* Blazar : Pierre Riteau
* Cinder : Rajat Dhasmana
* Cloudkitty : Rafael Weingartner
* Designate : Michael Johnson
* Freezer : ge cong
* Glance : Pranali Deore
* Heat : Takashi Kajinami
* Horizon : Vishal Manchanda
* Ironic : Jay Faulkner
* Keystone : Dave Wilde
* Kolla : Michal Nasiadka
* Kuryr : Roman Dobosz
* Magnum : Jake Yip
* Manila : Carlos Silva
* Masakari : sam sue
* Murano : Rong Zhu
* Neutron : Brian Haley
* Nova : Sylvain Bauza
* Octavia : Gregory Thiemonge
* OpenStack Charms : Felipe Reyes
* OpenStack Helm : Vladimir Kozhukalov
* OpenStackAnsible : Dmitriy Rabotyagov
* OpenStackSDK : Artem Goncharov
* Puppet OpenStack : Takashi Kajinami
* Quality Assurance : Martin Kopec
* Solum : Rong Zhu
* Storlets : Takashi Kajinami
* Swift : Tim Burke
* Tacker : Yasufumi Ogawa
* Telemetry : Erno Kuvaja
* Vitrage : Dmitriy Rabotyagov
* Watcher : chen ke
* Zaqar : Hao Wang
* Zun : Hongbin Lu

Elections:
* OpenStack_Helm: https://civs1.civs.us/cgi-bin/results.pl?id=E_3cf498bb10adc5b8

Election process details and results are also available here:
https://governance.openstack.org/election/

Thank you to all involved in the PTL election process,

Yours Tony.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3774 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/11d934a7/attachment-0001.bin>

From noonedeadpunk at gmail.com  Thu Sep 21 06:51:48 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Thu, 21 Sep 2023 08:51:48 +0200
Subject: [all][elections][ptl] Project Team Lead Election Conclusion and
 Results
In-Reply-To: <c12fab49d687481d98e10d2dc7d52636@inspur.com>
References: <CAFT5D2ShvXfMPO+U+BVDCbwipsPLdaCGZ+dWgva0F9ZhLFCm2Q@mail.gmail.com>
 <c12fab49d687481d98e10d2dc7d52636@inspur.com>
Message-ID: <CAPd_6AvQCTfGGoiRiDMJ7jPrzW0Mu5o4bVfT0rCOzUOWSeRdog@mail.gmail.com>

Hi,

Your candidacy has been submitted after the nomination period is over,
which is the reason why it wasn't merged.
During upcoming TC meetings there would be a discussion about leaderless
projects, and I assume that you will be appointed by TC to this role as a
volunteer to lead the project.

So don't worry much that Cyborg not in the list for now, but kindly push
nominations during required timeline in the future:)

On Thu, Sep 21, 2023, 08:46 Alex Song (???) <songwenping at inspur.com> wrote:

> Hi Tony,
>
>         I have voted for the PTL election for Cyborg projects. The commits
> donnot merged as below, please accept my election.
>         Cyborg: https://review.opendev.org/c/openstack/election/+/893300
>
> Thanks,
> Alex
>
> -----????-----
> ???: Tony Breeds [mailto:tony at bakeyournoodle.com]
> ????: 2023?9?21? 7:53
> ???: OpenStack Discuss <openstack-discuss at lists.openstack.org>;
> openstack-announce at lists.openstack.org
> ??: [all][elections][ptl] Project Team Lead Election Conclusion and Results
>
> Thank you to the electorate, to all those who voted and to all candidates
> who put their name forward for Project Team Lead (PTL) in this election. A
> healthy, open process breeds trust in our decision making capability thank
> you to all those who make this process possible.
>
> Now for the results of the PTL election process, please join me in
> extending congratulations to the following PTLs:
>
> * Adjutant : Dale Smith
> * Barbican : Grzegorz Grasza
> * Blazar : Pierre Riteau
> * Cinder : Rajat Dhasmana
> * Cloudkitty : Rafael Weingartner
> * Designate : Michael Johnson
> * Freezer : ge cong
> * Glance : Pranali Deore
> * Heat : Takashi Kajinami
> * Horizon : Vishal Manchanda
> * Ironic : Jay Faulkner
> * Keystone : Dave Wilde
> * Kolla : Michal Nasiadka
> * Kuryr : Roman Dobosz
> * Magnum : Jake Yip
> * Manila : Carlos Silva
> * Masakari : sam sue
> * Murano : Rong Zhu
> * Neutron : Brian Haley
> * Nova : Sylvain Bauza
> * Octavia : Gregory Thiemonge
> * OpenStack Charms : Felipe Reyes
> * OpenStack Helm : Vladimir Kozhukalov
> * OpenStackAnsible : Dmitriy Rabotyagov
> * OpenStackSDK : Artem Goncharov
> * Puppet OpenStack : Takashi Kajinami
> * Quality Assurance : Martin Kopec
> * Solum : Rong Zhu
> * Storlets : Takashi Kajinami
> * Swift : Tim Burke
> * Tacker : Yasufumi Ogawa
> * Telemetry : Erno Kuvaja
> * Vitrage : Dmitriy Rabotyagov
> * Watcher : chen ke
> * Zaqar : Hao Wang
> * Zun : Hongbin Lu
>
> Elections:
> * OpenStack_Helm:
> https://civs1.civs.us/cgi-bin/results.pl?id=E_3cf498bb10adc5b8
>
> Election process details and results are also available here:
> https://governance.openstack.org/election/
>
> Thank you to all involved in the PTL election process,
>
> Yours Tony.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/d1979adb/attachment.htm>

From songwenping at inspur.com  Thu Sep 21 07:18:02 2023
From: songwenping at inspur.com (=?utf-8?B?QWxleCBTb25nICjlrovmloflubMp?=)
Date: Thu, 21 Sep 2023 07:18:02 +0000
Subject: =?utf-8?B?562U5aSNOiBbYWxsXVtlbGVjdGlvbnNdW3B0bF0gUHJvamVjdCBUZWFtIExl?=
 =?utf-8?Q?ad_Election_Conclusion_and_Results?=
In-Reply-To: <CAPd_6AvQCTfGGoiRiDMJ7jPrzW0Mu5o4bVfT0rCOzUOWSeRdog@mail.gmail.com>
References: <179ce21e3a29c29915df31f5c724c0ce21-9-23gmail.com@g.corp-email.com>
 <CAPd_6AvQCTfGGoiRiDMJ7jPrzW0Mu5o4bVfT0rCOzUOWSeRdog@mail.gmail.com>
Message-ID: <a5dcea31e706412b9bc2f90163a9a5a4@inspur.com>

 

Thanks,  Dmitriy

 

???: Dmitriy Rabotyagov [mailto:noonedeadpunk at gmail.com] 
????: 2023?9?21? 14:52
???: Alex Song (???) <songwenping at inspur.com>
??: Tony Breeds <tony at bakeyournoodle.com>; openstack-discuss <openstack-discuss at lists.openstack.org>
??: Re: [all][elections][ptl] Project Team Lead Election Conclusion and Results

 

Hi,

 

Your candidacy has been submitted after the nomination period is over, which is the reason why it wasn't merged.

During upcoming TC meetings there would be a discussion about leaderless projects, and I assume that you will be appointed by TC to this role as a volunteer to lead the project.

 

So don't worry much that Cyborg not in the list for now, but kindly push nominations during required timeline in the future:)

On Thu, Sep 21, 2023, 08:46 Alex Song (???) <songwenping at inspur.com <mailto:songwenping at inspur.com> > wrote:

Hi Tony,

        I have voted for the PTL election for Cyborg projects. The commits donnot merged as below, please accept my election.
        Cyborg: https://review.opendev.org/c/openstack/election/+/893300 

Thanks,
Alex

-----????-----
???: Tony Breeds [mailto:tony at bakeyournoodle.com <mailto:tony at bakeyournoodle.com> ] 
????: 2023?9?21? 7:53
???: OpenStack Discuss <openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org> >; openstack-announce at lists.openstack.org <mailto:openstack-announce at lists.openstack.org> 
??: [all][elections][ptl] Project Team Lead Election Conclusion and Results

Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible.

Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs:

* Adjutant : Dale Smith
* Barbican : Grzegorz Grasza
* Blazar : Pierre Riteau
* Cinder : Rajat Dhasmana
* Cloudkitty : Rafael Weingartner
* Designate : Michael Johnson
* Freezer : ge cong
* Glance : Pranali Deore
* Heat : Takashi Kajinami
* Horizon : Vishal Manchanda
* Ironic : Jay Faulkner
* Keystone : Dave Wilde
* Kolla : Michal Nasiadka
* Kuryr : Roman Dobosz
* Magnum : Jake Yip
* Manila : Carlos Silva
* Masakari : sam sue
* Murano : Rong Zhu
* Neutron : Brian Haley
* Nova : Sylvain Bauza
* Octavia : Gregory Thiemonge
* OpenStack Charms : Felipe Reyes
* OpenStack Helm : Vladimir Kozhukalov
* OpenStackAnsible : Dmitriy Rabotyagov
* OpenStackSDK : Artem Goncharov
* Puppet OpenStack : Takashi Kajinami
* Quality Assurance : Martin Kopec
* Solum : Rong Zhu
* Storlets : Takashi Kajinami
* Swift : Tim Burke
* Tacker : Yasufumi Ogawa
* Telemetry : Erno Kuvaja
* Vitrage : Dmitriy Rabotyagov
* Watcher : chen ke
* Zaqar : Hao Wang
* Zun : Hongbin Lu

Elections:
* OpenStack_Helm: https://civs1.civs.us/cgi-bin/results.pl?id=E_3cf498bb10adc5b8

Election process details and results are also available here:
https://governance.openstack.org/election/

Thank you to all involved in the PTL election process,

Yours Tony.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/05473569/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3774 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/05473569/attachment-0001.bin>

From dtantsur at protonmail.com  Thu Sep 21 07:32:58 2023
From: dtantsur at protonmail.com (Dmitry Tantsur)
Date: Thu, 21 Sep 2023 07:32:58 +0000
Subject: [all] [diversity] Call for Outreachy mentors & projects
Message-ID: <65394ff1-e718-6f0a-cc86-6134437da68d@protonmail.com>

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.



From ralonsoh at redhat.com  Thu Sep 21 07:54:56 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Thu, 21 Sep 2023 09:54:56 +0200
Subject: [ptls][Bobcat] OpenInfra Live: OpenStack Bobcat
In-Reply-To: <CAARK8KQHToR5o85LSqyuOStNByKOBfpaJNeZ1ij2qDhaik1PYQ@mail.gmail.com>
References: <306DB1B3-7890-48D3-8E34-B7D003B6E30D@openinfra.dev>
 <CA+sTGNd+nBDtJNN5zod5hHAmK7tQmyQF=pgzDqYbdXsMpzKd2w@mail.gmail.com>
 <CAARK8KQHToR5o85LSqyuOStNByKOBfpaJNeZ1ij2qDhaik1PYQ@mail.gmail.com>
Message-ID: <CAECr9X7qpLHFZG5Njbj6-Sx-FX5AHyJRxF2MasT4erwg7Di0Lg@mail.gmail.com>

Same for Neutron, I'll be glad to provide last cycle highlights.


On Thu, Sep 21, 2023 at 12:37?AM Rajat Dhasmana <rdhasman at redhat.com> wrote:

> I can volunteer for Cinder like last time.
>
> -
> Rajat Dhasmana
>
> On Thu, Sep 21, 2023 at 12:06?AM Jay Faulkner <jay at gr-oss.io> wrote:
>
>> Always happy to talk about Ironic!
>>
>> -
>> Jay Faulkner
>> Ironic PTL
>>
>> On Wed, Sep 20, 2023 at 8:36?AM Kristin Barrientos <kristin at openinfra.dev>
>> wrote:
>>
>>> 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
>>>
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/4b2be35b/attachment.htm>

From derekokeeffe85 at yahoo.ie  Thu Sep 21 08:53:29 2023
From: derekokeeffe85 at yahoo.ie (Derek O keeffe)
Date: Thu, 21 Sep 2023 08:53:29 +0000 (UTC)
Subject: Problem with Barbican
References: <1503834122.6866945.1695286409426.ref@mail.yahoo.com>
Message-ID: <1503834122.6866945.1695286409426@mail.yahoo.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/565d86de/attachment.htm>

From gthiemonge at redhat.com  Thu Sep 21 11:28:23 2023
From: gthiemonge at redhat.com (Gregory Thiemonge)
Date: Thu, 21 Sep 2023 13:28:23 +0200
Subject: [octavia] state of taskflow jobboards
In-Reply-To: <a90e61f6f61c434f96a147c7dd0a1549@german-edge-cloud.io>
References: <a90e61f6f61c434f96a147c7dd0a1549@german-edge-cloud.io>
Message-ID: <CAKsmYT11r+hZ3egVoWtB06Tupj4ke=X_QrZFNECsJEMmA80oiw@mail.gmail.com>

Hi,

This is a very interesting question, I think we need to reevaluate the
status of this feature.
When we introduced jobboard, a few bugs were reported and fixed, but IIRC
we haven't had any new jobboard-related bugs for a long time (12/18 months
maybe?)
I know that some operators have been using it, we would like to get their
feedback before marking it as production-ready.
I will try to reach them in the next few weeks (or maybe during the PTG),

Greg

On Wed, Sep 20, 2023 at 3:39?PM Maximilian Stinsky <
maximilian.stinsky at german-edge-cloud.io> wrote:

> 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_flow.jobboard_enabled
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/cd33879a/attachment-0001.htm>

From knikolla at bu.edu  Thu Sep 21 14:04:50 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Thu, 21 Sep 2023 14:04:50 +0000
Subject: R: [all][elections][tc] Technical Committee Election Results
In-Reply-To: <CAFT5D2T3JRGAEydvngkBF3Q=ysCoQ=6=P-2Sakc_66UAk4aHvg@mail.gmail.com>
References: <CAFT5D2T3JRGAEydvngkBF3Q=ysCoQ=6=P-2Sakc_66UAk4aHvg@mail.gmail.com>
Message-ID: <BL0PR03MB4227E6C19D99CEAEF9AA242FBEF8A@BL0PR03MB4227.namprd03.prod.outlook.com>

Congratulations! Thank you to all the candidates and everyone who voted.

Kristi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/74696d0a/attachment.htm>

From stephenfin at redhat.com  Thu Sep 21 14:40:31 2023
From: stephenfin at redhat.com (Stephen Finucane)
Date: Thu, 21 Sep 2023 15:40:31 +0100
Subject: [all] oslo.db 14.0.0 breaks at least 4 projects (was:
 SQLAlchemy 2.x support in Bobcat)
In-Reply-To: <0e3a7928-26f4-1767-5305-42a86882e1e2@debian.org>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
 <dc035bef4b93d0048aacad02aa08bf4b4ecf1a34.camel@redhat.com>
 <b9c5699e-d5d2-5a22-7782-2e2b9b35321d@debian.org>
 <c431a5cafdd2d38f3469e75e75010c72be9cc56c.camel@redhat.com>
 <0e3a7928-26f4-1767-5305-42a86882e1e2@debian.org>
Message-ID: <4144bfc73611ec5601a1dd11113521c5b7c80d22.camel@redhat.com>

On Fri, 2023-09-15 at 14:11 +0200, Thomas Goirand wrote:
> On 9/15/23 13:26, Stephen Finucane wrote:
> > On Fri, 2023-09-15 at 13:07 +0200, Thomas Goirand wrote:
> > > On 9/13/23 15:39, Stephen Finucane wrote:
> > > > On Wed, 2023-09-13 at 09:21 +0200, Thomas Goirand wrote:
> > > > > Hi,
> > > > > 
> > > > > As you may know, and to my great frustration, I'm not the maintainer of
> > > > > SQLAlchemy in Debian, even though OpenStack is the biggest consumer of
> > > > > it. The current maintainer insists that he wants to upload SQLA 2.x in
> > > > > Unstable, potentially breaking all of OpenStack.
> > > > > 
> > > > > At the present moment, if I understand correctly, we're not there yet,
> > > > > and Bobcat doesn't have such a support. It would be ok for me, *IF*
> > > > > there are patches available on master, that I could backport to Bobcat
> > > > > and maintain in the debian/patches folder of each project. However, the
> > > > > biggest current annoyance, is that I have no idea where we are at. Are
> > > > > we close to such a support? Is there a list of patches to apply on top
> > > > > of Bobcat that is maintained somewhere?
> > > > > 
> > > > > Please enlighten me... :)
> > > > 
> > > > I think you figured this out on IRC this morning, but the vast majority (though
> > > > not all) of the patches are available at the sqlalchemy-20 topic in Gerrit [1].
> > > > I've been working on this for almost 2 years now and have most of the core
> > > > projects well on their way but not everything is complete, as you'll tell from
> > > > that list. I have a canary patch [2] that I've been using to spot missing
> > > > services. I plan to pick up the Manila work again early in C, but could do with
> > > > help removing the use of autocommit in Heat and the weird test failures I'm
> > > > seeing in Cinder [3]. We also need reviews of the Masakri series (Is that
> > > > project dead? I can't tell). Once those are addressed, I _think_ we might be
> > > > done but who knows what else we'll find...
> > > > 
> > > > Cheers,
> > > > Stephen
> > > > 
> > > > [1] https://review.opendev.org/q/topic:sqlalchemy-20+is:open
> > > > [2] https://review.opendev.org/c/openstack/requirements/+/879743
> > > > [3] https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder
> > > 
> > > Thanks for your work, really!
> > > And thanks for the details above.
> > > 
> > > Now, not sure how much this is related, but I've seen that the new
> > > oslo.db 14.0.0 breaks:
> > > - freezer-api
> > > - trove
> > > - cloudkitty
> > > - watcher
> > > 
> > > Is there any plan to fix oslo.db, or the above projects? Maybe revert
> > > some commits in oslo.db? Can someone explain to me what's going on for
> > > this as well?
> > 
> > oslo.db has intentionally *not* been bumped to >= 13.0.0 in upper-constraints
> > because it introduces many breaking changes that are not compatible with
> > SQLAlchemy 2.x. Conversely, oslo.db < 13.0.0 is simply not compatible with
> > SQLAlchemy >= 2.x. As such, we can't bump oslo.db until the various projects
> > have been fixed which is the same as what we're seeing with SQLAlchemy 2.x.
> > 
> > Fortunately projects that adopt to I have been pushing patches to various
> > projects that add a "tips" job for testing main/master branches of SQLAlchemy,
> > Alembic, and oslo.db, e.g. [1][2][3][4]. The Neutron folks were well ahead of
> > the curve as usual and also have their own (which is where I got the idea from).
> > The projects you mention above could do with an equivalent job and my guess is
> > that the process of getting there will highlight quite a bit of work that they
> > need to do. They need to start at that asap (and tbh really should have started
> > at it a long time ago as they've had over 2 years of a warning [5]).
> > 
> > Cheers,
> > Stephen
> > 
> > [1] https://review.opendev.org/c/openstack/barbican/+/888308
> > [2] https://review.opendev.org/c/openstack/placement/+/886229
> > [3] https://review.opendev.org/c/openstack/cinder/+/886152
> > [4] https://review.opendev.org/c/openstack/glance/+/889066
> > [5] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html
> 
> FYI, I also fell into the trap of castellan 4.2.0. I'm writing this here 
> for others *not* to do the same mistake as me: do not upgrade, or Cinder 
> will fail its unit tests, and only 4.1.0 is the upper bound. Switching 
> back to 4.1.0 made Cinder build correctly for me.

That version bump should have been a major version bump, but it's a pity we had
to revert them: the fixes look to have been pretty simple.

https://review.opendev.org/c/openstack/cinder/+/896121
https://review.opendev.org/c/openstack/nova/+/896100

Stephen

> 
> The good thing with castellan is, I forgot to upload it to Experimental, 
> so to the contrary of oslo.db, it's okish for me ... :)
> 
> I hope that helps others,
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 



From hberaud at redhat.com  Thu Sep 21 14:44:06 2023
From: hberaud at redhat.com (Herve Beraud)
Date: Thu, 21 Sep 2023 16:44:06 +0200
Subject: [release][requirements][TC][oslo] how to manage divergence between
 runtime and doc?
Message-ID: <CAFDq9gXbAgjCpYk0_em7rnKYd1=jU6OYSc-N5dDrhorBQhXhLA@mail.gmail.com>

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-constraints.txt#L482
[2] https://releases.openstack.org/bobcat/index.html#bobcat-oslo-db
[3]
https://opendev.org/openstack/releases/src/branch/master/deliverables/antelope/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/035100.html
[8]
https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html
[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/115c3247b486c713176139422647144108101ca3
[13]
https://opendev.org/openstack/oslo.db/commit/4ee79141e601482fcde02f0cecfb561ecb79e1b6
[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-and-milestone-3

-- 
Herv? Beraud
Senior Software Engineer at Red Hat
irc: hberaud
https://github.com/4383/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/dbdfb92b/attachment-0001.htm>

From stephenfin at redhat.com  Thu Sep 21 14:50:17 2023
From: stephenfin at redhat.com (Stephen Finucane)
Date: Thu, 21 Sep 2023 15:50:17 +0100
Subject: [all] oslo.db 14.0.0 breaks at least 4 projects (was:
 SQLAlchemy 2.x support in Bobcat)
In-Reply-To: <c431a5cafdd2d38f3469e75e75010c72be9cc56c.camel@redhat.com>
References: <007fb398-0662-e1fe-7d0d-ebef6f54cbea@debian.org>
 <dc035bef4b93d0048aacad02aa08bf4b4ecf1a34.camel@redhat.com>
 <b9c5699e-d5d2-5a22-7782-2e2b9b35321d@debian.org>
 <c431a5cafdd2d38f3469e75e75010c72be9cc56c.camel@redhat.com>
Message-ID: <887f68643e62ef89530d96926ab452018325481f.camel@redhat.com>

On Fri, 2023-09-15 at 12:26 +0100, Stephen Finucane wrote:
> On Fri, 2023-09-15 at 13:07 +0200, Thomas Goirand wrote:
> > On 9/13/23 15:39, Stephen Finucane wrote:
> > > On Wed, 2023-09-13 at 09:21 +0200, Thomas Goirand wrote:
> > > > Hi,
> > > > 
> > > > As you may know, and to my great frustration, I'm not the maintainer of
> > > > SQLAlchemy in Debian, even though OpenStack is the biggest consumer of
> > > > it. The current maintainer insists that he wants to upload SQLA 2.x in
> > > > Unstable, potentially breaking all of OpenStack.
> > > > 
> > > > At the present moment, if I understand correctly, we're not there yet,
> > > > and Bobcat doesn't have such a support. It would be ok for me, *IF*
> > > > there are patches available on master, that I could backport to Bobcat
> > > > and maintain in the debian/patches folder of each project. However, the
> > > > biggest current annoyance, is that I have no idea where we are at. Are
> > > > we close to such a support? Is there a list of patches to apply on top
> > > > of Bobcat that is maintained somewhere?
> > > > 
> > > > Please enlighten me... :)
> > > 
> > > I think you figured this out on IRC this morning, but the vast majority (though
> > > not all) of the patches are available at the sqlalchemy-20 topic in Gerrit [1].
> > > I've been working on this for almost 2 years now and have most of the core
> > > projects well on their way but not everything is complete, as you'll tell from
> > > that list. I have a canary patch [2] that I've been using to spot missing
> > > services. I plan to pick up the Manila work again early in C, but could do with
> > > help removing the use of autocommit in Heat and the weird test failures I'm
> > > seeing in Cinder [3]. We also need reviews of the Masakri series (Is that
> > > project dead? I can't tell). Once those are addressed, I _think_ we might be
> > > done but who knows what else we'll find...
> > > 
> > > Cheers,
> > > Stephen
> > > 
> > > [1] https://review.opendev.org/q/topic:sqlalchemy-20+is:open
> > > [2] https://review.opendev.org/c/openstack/requirements/+/879743
> > > [3] https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder
> > 
> > Thanks for your work, really!
> > And thanks for the details above.
> > 
> > Now, not sure how much this is related, but I've seen that the new 
> > oslo.db 14.0.0 breaks:
> > - freezer-api
> > - trove
> > - cloudkitty
> > - watcher
> > 
> > Is there any plan to fix oslo.db, or the above projects? Maybe revert 
> > some commits in oslo.db? Can someone explain to me what's going on for 
> > this as well?
> 
> oslo.db has intentionally *not* been bumped to >= 13.0.0 in upper-constraints
> because it introduces many breaking changes that are not compatible with
> SQLAlchemy 2.x. Conversely, oslo.db < 13.0.0 is simply not compatible with
> SQLAlchemy >= 2.x. As such, we can't bump oslo.db until the various projects
> have been fixed which is the same as what we're seeing with SQLAlchemy 2.x.
> 
> Fortunately projects that adopt to I have been pushing patches to various
> projects that add a "tips" job for testing main/master branches of SQLAlchemy,
> Alembic, and oslo.db, e.g. [1][2][3][4]. The Neutron folks were well ahead of
> the curve as usual and also have their own (which is where I got the idea from).
> The projects you mention above could do with an equivalent job and my guess is
> that the process of getting there will highlight quite a bit of work that they
> need to do. They need to start at that asap (and tbh really should have started
> at it a long time ago as they've had over 2 years of a warning [5]).

Just closing this out, we reverted some of the removals of oslo.db functionality
that and cut a new 14.1.0 release. The 15.0.0 release will come out early in C
and re-remove these features. I'd ask that the outstanding projects that are
still facing issues with oslo.db merge the patches to address these issues asap.

Heat: https://review.opendev.org/q/topic:sqlalchemy-20+project:openstack/heat
   (note: There are intermittent failures due to random test order causing
   duplicate keys. Will be fixed shortly.)

Aodh: https://review.opendev.org/q/topic:sqlalchemy-20+project:openstack/aodh
   (note: Gate is broken. Have proposed a temporary fix [1])

Masakari: https://review.opendev.org/q/topic:sqlalchemy-20+project:openstack/masakari

Cheers,
Stephen

[1] https://review.opendev.org/c/openstack/aodh/+/896125

> 
> Cheers,
> Stephen
> 
> [1] https://review.opendev.org/c/openstack/barbican/+/888308
> [2] https://review.opendev.org/c/openstack/placement/+/886229
> [3] https://review.opendev.org/c/openstack/cinder/+/886152
> [4] https://review.opendev.org/c/openstack/glance/+/889066
> [5] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html
> 
> > 
> > Cheers,
> > 
> > Thomas Goirand (zigo)
> > 
> 



From kkloppenborg at resetdata.com.au  Thu Sep 21 15:19:51 2023
From: kkloppenborg at resetdata.com.au (Karl Kloppenborg)
Date: Thu, 21 Sep 2023 15:19:51 +0000
Subject: Cyborg nova reports mdev-capable resource is not available
Message-ID: <ME3P282MB08839BB30B52D097B8D40B07FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>

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 at 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 at Karls-Air ~ %

I can see the allocation candidate:
karl at 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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/36017b66/attachment-0001.htm>

From sbauza at redhat.com  Thu Sep 21 15:48:48 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Thu, 21 Sep 2023 17:48:48 +0200
Subject: Cyborg nova reports mdev-capable resource is not available
In-Reply-To: <ME3P282MB08839BB30B52D097B8D40B07FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
References: <ME3P282MB08839BB30B52D097B8D40B07FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
Message-ID: <CALOCmungy=Jd8nvYpRV-P4ngx9CWiKr-dgvxfRcCLsR1=47JzA@mail.gmail.com>

Le jeu. 21 sept. 2023 ? 17:27, Karl Kloppenborg <
kkloppenborg at resetdata.com.au> a ?crit :

> 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.
>
>
>

I don't exactly remember how Cyborg passes the devices to nova/libvirt but
this exception is because none of the available GPUs have either existing
mdevs or capability for creating mdevs.
You should first check sysfs to double-check the state of our GPU devices
in order to understand how much of vGPU capacity you still have.

-Sylvain

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 at 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 at Karls-Air ~ %
>
>
>
> I can see the allocation candidate:
>
> karl at 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 at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/e583832b/attachment.htm>

From jay at gr-oss.io  Thu Sep 21 15:50:05 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Thu, 21 Sep 2023 08:50:05 -0700
Subject: [all][elections][tc] Technical Committee Election Results
In-Reply-To: <CAFT5D2T3JRGAEydvngkBF3Q=ysCoQ=6=P-2Sakc_66UAk4aHvg@mail.gmail.com>
References: <CAFT5D2T3JRGAEydvngkBF3Q=ysCoQ=6=P-2Sakc_66UAk4aHvg@mail.gmail.com>
Message-ID: <CA+sTGNds8BdQveh-MbBxznW65jf-V+ydx7rxzTq-hAk+35PsQQ@mail.gmail.com>

Tony and the rest of the election officials, thank you for the work putting
on the election.

I encourage everyone in the community -- if you're seeing this email and
didn't vote; take action *today* to ensure you'll be setup for the next
election. We had over 600 contributors in the Antelope development cycle;
only 309 of those were eligible to receive a ballot and only 51 of those
voted. Over the last year we've heard a number of stories about parts of
the OSS -- and cloud ecosystems getting less open. I appreciate that we
operate OpenStack under the four opens; but with that comes the
responsibility to participate in the processes that help ensure we remain
open.

All that is to say: the requirements to be eligible to vote are simple, and
are enumerated here: https://governance.openstack.org/election/#electorate
-- the hard part, contributing to OpenStack, most of you have already done!
Please don't find yourself in six months wondering why you weren't able to
vote again; let's get it knocked out today!

Thanks,
Jay Faulkner
TC Member
Ironic PTL


On Wed, Sep 20, 2023 at 5:13?PM Tony Breeds <tony at bakeyournoodle.com> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/c213d9aa/attachment.htm>

From gmann at ghanshyammann.com  Thu Sep 21 16:11:54 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 21 Sep 2023 09:11:54 -0700
Subject: =?UTF-8?Q?Re:_=E7=AD=94=E5=A4=8D:_[all][elections][ptl]_Project_T?=
 =?UTF-8?Q?eam_Lead_Election_Conclusion_and_Results?=
In-Reply-To: <a5dcea31e706412b9bc2f90163a9a5a4@inspur.com>
References: <179ce21e3a29c29915df31f5c724c0ce21-9-23gmail.com@g.corp-email.com>
 <CAPd_6AvQCTfGGoiRiDMJ7jPrzW0Mu5o4bVfT0rCOzUOWSeRdog@mail.gmail.com>
 <a5dcea31e706412b9bc2f90163a9a5a4@inspur.com>
Message-ID: <18ab8831bb2.eff9601e1060142.2127745672408878122@ghanshyammann.com>

Hi Alex,

As next step, TC will be discussing it for leadership, and your late nomination is ack.

-gmann

 ---- On Thu, 21 Sep 2023 00:18:02 -0700  Alex Song (???)  wrote --- 
 > 
 > ?
 > Thanks, ?Dmitriy
 > ?
 > ???: Dmitriy Rabotyagov [mailto:noonedeadpunk at gmail.com] 
 > ????: 2023?9?21? 14:52
 > ???: Alex Song (???) songwenping at inspur.com>
 > ??: Tony Breeds tony at bakeyournoodle.com>; openstack-discuss openstack-discuss at lists.openstack.org>
 > ??: Re: [all][elections][ptl] Project Team Lead Election Conclusion and Results
 > ?
 > Hi,
 > ?
 > Your candidacy has been submitted after the nomination period is over, which is the reason why it wasn't merged.
 > During upcoming TC meetings there would be a discussion about leaderless projects, and I assume that you will be appointed by TC to this role as a volunteer to lead the project.
 > ?
 > So don't worry much that Cyborg not in the list for now, but kindly push nominations during required timeline in the future:)
 > On Thu, Sep 21, 2023, 08:46 Alex Song (???) songwenping at inspur.com> wrote:
 > Hi Tony,
 > 
 > ? ? ? ? I have voted for the PTL election for Cyborg projects. The commits donnot merged as below, please accept my election.
 > ? ? ? ? Cyborg: https://review.opendev.org/c/openstack/election/+/893300 
 > 
 > Thanks,
 > Alex
 > 
 > -----????-----
 > ???: Tony Breeds [mailto:tony at bakeyournoodle.com] 
 > ????: 2023?9?21? 7:53
 > ???: OpenStack Discuss openstack-discuss at lists.openstack.org>; openstack-announce at lists.openstack.org
 > ??: [all][elections][ptl] Project Team Lead Election Conclusion and Results
 > 
 > Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible.
 > 
 > Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs:
 > 
 > * Adjutant : Dale Smith
 > * Barbican : Grzegorz Grasza
 > * Blazar : Pierre Riteau
 > * Cinder : Rajat Dhasmana
 > * Cloudkitty : Rafael Weingartner
 > * Designate : Michael Johnson
 > * Freezer : ge cong
 > * Glance : Pranali Deore
 > * Heat : Takashi Kajinami
 > * Horizon : Vishal Manchanda
 > * Ironic : Jay Faulkner
 > * Keystone : Dave Wilde
 > * Kolla : Michal Nasiadka
 > * Kuryr : Roman Dobosz
 > * Magnum : Jake Yip
 > * Manila : Carlos Silva
 > * Masakari : sam sue
 > * Murano : Rong Zhu
 > * Neutron : Brian Haley
 > * Nova : Sylvain Bauza
 > * Octavia : Gregory Thiemonge
 > * OpenStack Charms : Felipe Reyes
 > * OpenStack Helm : Vladimir Kozhukalov
 > * OpenStackAnsible : Dmitriy Rabotyagov
 > * OpenStackSDK : Artem Goncharov
 > * Puppet OpenStack : Takashi Kajinami
 > * Quality Assurance : Martin Kopec
 > * Solum : Rong Zhu
 > * Storlets : Takashi Kajinami
 > * Swift : Tim Burke
 > * Tacker : Yasufumi Ogawa
 > * Telemetry : Erno Kuvaja
 > * Vitrage : Dmitriy Rabotyagov
 > * Watcher : chen ke
 > * Zaqar : Hao Wang
 > * Zun : Hongbin Lu
 > 
 > Elections:
 > * OpenStack_Helm: https://civs1.civs.us/cgi-bin/results.pl?id=E_3cf498bb10adc5b8
 > 
 > Election process details and results are also available here:
 > https://governance.openstack.org/election/
 > 
 > Thank you to all involved in the PTL election process,
 > 
 > Yours Tony.
 > 


From kkloppenborg at resetdata.com.au  Thu Sep 21 16:43:13 2023
From: kkloppenborg at resetdata.com.au (Karl Kloppenborg)
Date: Thu, 21 Sep 2023 16:43:13 +0000
Subject: Cyborg nova reports mdev-capable resource is not available
In-Reply-To: <CALOCmungy=Jd8nvYpRV-P4ngx9CWiKr-dgvxfRcCLsR1=47JzA@mail.gmail.com>
References: <ME3P282MB08839BB30B52D097B8D40B07FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
 <CALOCmungy=Jd8nvYpRV-P4ngx9CWiKr-dgvxfRcCLsR1=47JzA@mail.gmail.com>
Message-ID: <ME3P282MB08838692065842196EAF9A59FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>

Hi Sylvian,

Thanks for getting back to me.
So the vGPU is available and cyborg is allocating it using ARQ binding.
You can see Nova receives this request:

2023-09-21 16:38:51.889 1901814 DEBUG nova.compute.manager [None req-97062e9c-0c44-480e-9918-4a5a810175b2 78e83e5a446e4071ae43e823135dcb3c 21eb701c2a1f48b38dab8f34c0a20902 - - default default] ARQs for spec:{'2d60c353-0419-4b67-8cb7-913fc6f5cef9': {'uuid': '2d60c353-0419-4b67-8cb7-913fc6f5cef9', 'state': 'Bound', 'device_profile_name': 'VGPU_A40-Q48', 'device_profile_group_id': 0, 'hostname': 'gpu-c-01', 'device_rp_uuid': '229bf15f-5689-3d2c-b37b-5c8439ea6a71', 'instance_uuid': '1b090007-791b-4997-af89-0feb886cf11d', 'project_id': None, 'attach_handle_type': 'MDEV', 'attach_handle_uuid': '866bd6a5-b156-4251-a969-64fefb32f16f', 'attach_handle_info': {'asked_type': 'nvidia-566', 'bus': 'ca', 'device': '01', 'domain': '0000', 'function': '1', 'vgpu_mark': 'nvidia-566_0'}, 'links': [{'href': 'http://cyborg-api.openstack.svc.cluster.local:6666/accelerator/v2/accelerator_requests/2d60c353-0419-4b67-8cb7-913fc6f5cef9', 'rel': 'self'}], 'created_at': '2023-09-21T16:38:42+00:00', 'updated_at': '2023-09-21T16:38:42+00:00'}}, ARQs for network:{} _build_resources /var/lib/openstack/lib/python3.10/site-packages/nova/compute/manager.py:2680

So the mdev is then allocated in the resource providers at that point.

Is there some cyborg nova patching code I am missing?




From: Sylvain Bauza <sbauza at redhat.com>
Date: Friday, 22 September 2023 at 1:49 am
To: Karl Kloppenborg <kkloppenborg at resetdata.com.au>
Cc: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: Re: Cyborg nova reports mdev-capable resource is not available


Le jeu. 21 sept. 2023 ? 17:27, Karl Kloppenborg <kkloppenborg at resetdata.com.au<mailto:kkloppenborg at resetdata.com.au>> a ?crit :
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.


I don't exactly remember how Cyborg passes the devices to nova/libvirt but this exception is because none of the available GPUs have either existing mdevs or capability for creating mdevs.
You should first check sysfs to double-check the state of our GPU devices in order to understand how much of vGPU capacity you still have.

-Sylvain

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 at 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 at Karls-Air ~ %

I can see the allocation candidate:
karl at 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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/a9c8685e/attachment-0001.htm>

From ekuvaja at redhat.com  Thu Sep 21 16:55:51 2023
From: ekuvaja at redhat.com (Erno Kuvaja)
Date: Thu, 21 Sep 2023 17:55:51 +0100
Subject: Requirements FFE to return Sphinx to known working version
Message-ID: <CAKwVDDPa44BdkmBStVDcJc72-U-BjptPzaKLS6xHbBzSEtsVNg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/0ab9b104/attachment.htm>

From jay at gr-oss.io  Thu Sep 21 18:57:44 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Thu, 21 Sep 2023 11:57:44 -0700
Subject: [ironic] [ptl] Announcement of non-candidacy for D / 2024.2
Message-ID: <CA+sTGNcdv2F0kRQ+yrJnEUHAwjuji7ziog=nGc6T84i+7w6QZA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/3352abc5/attachment.htm>

From johnsomor at gmail.com  Thu Sep 21 21:27:48 2023
From: johnsomor at gmail.com (Michael Johnson)
Date: Thu, 21 Sep 2023 14:27:48 -0700
Subject: Requirements FFE to return Sphinx to known working version
In-Reply-To: <CAKwVDDPa44BdkmBStVDcJc72-U-BjptPzaKLS6xHbBzSEtsVNg@mail.gmail.com>
References: <CAKwVDDPa44BdkmBStVDcJc72-U-BjptPzaKLS6xHbBzSEtsVNg@mail.gmail.com>
Message-ID: <CAMH0Mg+eFb+cF0Rm88XVvCcyigPe=uATWf9aYoC1HVkPUjbSdQ@mail.gmail.com>

There are a few of us that keep an eye on wsme, so I would not say
it's unmaintained.

I too would lean towards a wsme release, but changing requirements
this late is problematic.

I think if we want to do this release we should do it now so that the
project teams can get any fixes needed before the final RCs next week.

Michael

On Thu, Sep 21, 2023 at 10:01?AM Erno Kuvaja <ekuvaja at redhat.com> wrote:
>
> 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


From nguyenhuukhoinw at gmail.com  Fri Sep 22 04:59:34 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Fri, 22 Sep 2023 11:59:34 +0700
Subject: [kolla-ansible][keystone][skyline] Keystone use SSO for authentication
Message-ID: <CABAODRfKte90m+RseXko_NPbXo-s5tmUR3ywXe8W5HsyQAivkw@mail.gmail.com>

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%20sso.md

I will try to contribute what I can for newbies and community.


Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/69cabb44/attachment.htm>

From ralonsoh at redhat.com  Fri Sep 22 07:33:52 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 22 Sep 2023 09:33:52 +0200
Subject: [neutron] Neutron drivers meeting cancelled
Message-ID: <CAECr9X7ESV=yKFuxgr--5zac6sQvTUXb0JN=nJ79oVEdGwCWaQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/3fd51871/attachment.htm>

From ralonsoh at redhat.com  Fri Sep 22 08:11:00 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 22 Sep 2023 10:11:00 +0200
Subject: [neutron] Thanks for the Bobcat release (and now let's continue
 working in Caracal)
Message-ID: <CAECr9X5O77MwBPxcj8jwfw=nAH1J9fRtwthyaYjm2HaHyArbeg@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/da89ae8b/attachment-0001.htm>

From stephenfin at redhat.com  Fri Sep 22 09:58:03 2023
From: stephenfin at redhat.com (Stephen Finucane)
Date: Fri, 22 Sep 2023 10:58:03 +0100
Subject: [aodh][mistral][solum][release][requirements] Feature freeze
 exception for wsme, sphinxcontrib-pecanwsme
Message-ID: <7628cd578cb9fc1a2299afd44cbbec01802f1da4.camel@redhat.com>

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/035190.html
[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



From jerome.becot at deveryware.com  Fri Sep 22 10:49:07 2023
From: jerome.becot at deveryware.com (=?UTF-8?B?SsOpcsO0bWUgQkVDT1Q=?=)
Date: Fri, 22 Sep 2023 12:49:07 +0200
Subject: [Nova][Neutron] Help troubleshooting metadata service error 404
 (Ussuri)
Message-ID: <1b4afce6-d860-821c-4909-546e0e8c1729@deveryware.com>

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/a8862ad7/attachment.htm>

From jerome.becot at deveryware.com  Fri Sep 22 11:41:42 2023
From: jerome.becot at deveryware.com (=?UTF-8?B?SsOpcsO0bWUgQkVDT1Q=?=)
Date: Fri, 22 Sep 2023 13:41:42 +0200
Subject: [Nova][Neutron] Help troubleshooting metadata service error 404
 (Ussuri)
In-Reply-To: <1b4afce6-d860-821c-4909-546e0e8c1729@deveryware.com>
References: <1b4afce6-d860-821c-4909-546e0e8c1729@deveryware.com>
Message-ID: <6c2c4707-27e8-0459-1367-94e0b3c3274e@deveryware.com>

After spending some time it seems that it is a problem in the 
instances... but still I don't have a clue: it works when running as 
root or sudo and doesn't with regular users ...

Le 22/09/2023 ? 12:49, J?r?me BECOT a ?crit?:
>
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/8451bffd/attachment.htm>

From auniyal at redhat.com  Fri Sep 22 11:53:51 2023
From: auniyal at redhat.com (Amit Uniyal)
Date: Fri, 22 Sep 2023 17:23:51 +0530
Subject: [Nova][Neutron] Help troubleshooting metadata service error 404
 (Ussuri)
In-Reply-To: <6c2c4707-27e8-0459-1367-94e0b3c3274e@deveryware.com>
References: <1b4afce6-d860-821c-4909-546e0e8c1729@deveryware.com>
 <6c2c4707-27e8-0459-1367-94e0b3c3274e@deveryware.com>
Message-ID: <CAMZr3i4TSHkHeMKKT3vrmWofwXL2=iTQ5Bu_SQQDAYCODuFGGw@mail.gmail.com>

Hello,

IIUC, you are running this from the guest instance, to see the metadata of
this instance,
but in your working example, you get it without full URI, i.e.
/opestack/latest/metadata.json.

Its 400, Can you please try $ curl 169.254.169.254/openstack once, along
with ovn-metadata-agent.log check for nova-metadata-api logs as well to see
what request went.

Also, can you tell how your setup is deployed? such as tripleO or
killa-ansible, etc..


Regards

On Fri, Sep 22, 2023 at 5:19?PM J?r?me BECOT <jerome.becot at deveryware.com>
wrote:

> After spending some time it seems that it is a problem in the instances...
> but still I don't have a clue: it works when running as root or sudo and
> doesn't with regular users ...
> Le 22/09/2023 ? 12:49, J?r?me BECOT a ?crit :
>
> 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/b75be9d9/attachment-0001.htm>

From kkloppenborg at resetdata.com.au  Thu Sep 21 15:15:17 2023
From: kkloppenborg at resetdata.com.au (Karl Kloppenborg)
Date: Thu, 21 Sep 2023 15:15:17 +0000
Subject: Cyborg nova reports mdev-capable resource is not available
Message-ID: <ME3P282MB088396CD3D2DE68808F897F8FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>

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 at 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 at Karls-Air ~ %

I can see the allocation candidate:
karl at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230921/73f1c31c/attachment-0001.htm>

From songwenping at inspur.com  Fri Sep 22 02:17:08 2023
From: songwenping at inspur.com (=?gb2312?B?QWxleCBTb25nICjLzs7Exr0p?=)
Date: Fri, 22 Sep 2023 02:17:08 +0000
Subject: =?gb2312?B?tPC4tDogQ3lib3JnIG5vdmEgcmVwb3J0cyBtZGV2LWNhcGFibGUgcmVzb3Vy?=
 =?gb2312?Q?ce_is_not_available?=
In-Reply-To: <ME3P282MB08838692065842196EAF9A59FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
References: <ME3P282MB08839BB30B52D097B8D40B07FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
 <CALOCmungy=Jd8nvYpRV-P4ngx9CWiKr-dgvxfRcCLsR1=47JzA@mail.gmail.com>
 <ME3P282MB08838692065842196EAF9A59FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
Message-ID: <6550e9110ec14bfb848af296389b8b3a@inspur.com>

A non-text attachment was scrubbed...
Name: smime.p7m
Type: application/pkcs7-mime
Size: 36613 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/b004afa0/attachment-0001.p7c>

From kkloppenborg at resetdata.com.au  Fri Sep 22 02:53:26 2023
From: kkloppenborg at resetdata.com.au (Karl Kloppenborg)
Date: Fri, 22 Sep 2023 02:53:26 +0000
Subject: Cyborg nova reports mdev-capable resource is not available
In-Reply-To: <6550e9110ec14bfb848af296389b8b3a@inspur.com>
References: <ME3P282MB08839BB30B52D097B8D40B07FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
 <CALOCmungy=Jd8nvYpRV-P4ngx9CWiKr-dgvxfRcCLsR1=47JzA@mail.gmail.com>
 <ME3P282MB08838692065842196EAF9A59FAF8A@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
 <6550e9110ec14bfb848af296389b8b3a@inspur.com>
Message-ID: <ME3P282MB08836664DA05E9ECCD58C75DFAFFA@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>

Ah thank you for pointing me towards that Alex.

I guess, I should probably look at the MIG pathway.
I wonder if it?s possible to do vGPU profiles in MIG configuration.

Have you any experience with this?

Thanks,
Karl.

From: Alex Song (???) <songwenping at inspur.com>
Date: Friday, 22 September 2023 at 12:17 pm
To: Karl Kloppenborg <kkloppenborg at resetdata.com.au>, sbauza at redhat.com <sbauza at redhat.com>
Cc: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: ??: Cyborg nova reports mdev-capable resource is not available

Hi Karl,
         Your problem is similar with the bug: https://bugs.launchpad.net/nova/+bug/2015892
         I guess you don?t split the mig if using A serial card.

???: Karl Kloppenborg [mailto:kkloppenborg at resetdata.com.au]
????: 2023?9?22? 0:43
???: Sylvain Bauza <sbauza at redhat.com>
??: openstack-discuss at lists.openstack.org
??: Re: Cyborg nova reports mdev-capable resource is not available

Hi Sylvian,

Thanks for getting back to me.
So the vGPU is available and cyborg is allocating it using ARQ binding.
You can see Nova receives this request:

2023-09-21 16:38:51.889 1901814 DEBUG nova.compute.manager [None req-97062e9c-0c44-480e-9918-4a5a810175b2 78e83e5a446e4071ae43e823135dcb3c 21eb701c2a1f48b38dab8f34c0a20902 - - default default] ARQs for spec:{'2d60c353-0419-4b67-8cb7-913fc6f5cef9': {'uuid': '2d60c353-0419-4b67-8cb7-913fc6f5cef9', 'state': 'Bound', 'device_profile_name': 'VGPU_A40-Q48', 'device_profile_group_id': 0, 'hostname': 'gpu-c-01', 'device_rp_uuid': '229bf15f-5689-3d2c-b37b-5c8439ea6a71', 'instance_uuid': '1b090007-791b-4997-af89-0feb886cf11d', 'project_id': None, 'attach_handle_type': 'MDEV', 'attach_handle_uuid': '866bd6a5-b156-4251-a969-64fefb32f16f', 'attach_handle_info': {'asked_type': 'nvidia-566', 'bus': 'ca', 'device': '01', 'domain': '0000', 'function': '1', 'vgpu_mark': 'nvidia-566_0'}, 'links': [{'href': 'http://cyborg-api.openstack.svc.cluster.local:6666/accelerator/v2/accelerator_requests/2d60c353-0419-4b67-8cb7-913fc6f5cef9', 'rel': 'self'}], 'created_at': '2023-09-21T16:38:42+00:00', 'updated_at': '2023-09-21T16:38:42+00:00'}}, ARQs for network:{} _build_resources /var/lib/openstack/lib/python3.10/site-packages/nova/compute/manager.py:2680

So the mdev is then allocated in the resource providers at that point.

Is there some cyborg nova patching code I am missing?




From: Sylvain Bauza <sbauza at redhat.com<mailto:sbauza at redhat.com>>
Date: Friday, 22 September 2023 at 1:49 am
To: Karl Kloppenborg <kkloppenborg at resetdata.com.au<mailto:kkloppenborg at resetdata.com.au>>
Cc: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org> <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Subject: Re: Cyborg nova reports mdev-capable resource is not available


Le jeu. 21 sept. 2023 ? 17:27, Karl Kloppenborg <kkloppenborg at resetdata.com.au<mailto:kkloppenborg at resetdata.com.au>> a ?crit :
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.


I don't exactly remember how Cyborg passes the devices to nova/libvirt but this exception is because none of the available GPUs have either existing mdevs or capability for creating mdevs.
You should first check sysfs to double-check the state of our GPU devices in order to understand how much of vGPU capacity you still have.

-Sylvain

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 at 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 at Karls-Air ~ %

I can see the allocation candidate:
karl at 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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/24775141/attachment-0001.htm>

From songwenping at inspur.com  Fri Sep 22 05:49:55 2023
From: songwenping at inspur.com (=?gb2312?B?QWxleCBTb25nICjLzs7Exr0p?=)
Date: Fri, 22 Sep 2023 05:49:55 +0000
Subject: =?gb2312?B?tPC4tDogQ3lib3JnIG5vdmEgcmVwb3J0cyBtZGV2LWNhcGFibGUgcmVzb3Vy?=
 =?gb2312?Q?ce_is_not_available?=
In-Reply-To: <ME3P282MB08836664DA05E9ECCD58C75DFAFFA@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
References: <30e9e7f98b79f82f215acaa9bafe220922-9-23resetdata.com.au@g.corp-email.com>
 <ME3P282MB08836664DA05E9ECCD58C75DFAFFA@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>
Message-ID: <d3e12f400bf14fb9b78c9b01fa532ea9@inspur.com>

A non-text attachment was scrubbed...
Name: smime.p7m
Type: application/pkcs7-mime
Size: 45996 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/f57ea0a4/attachment-0001.p7c>

From jerome.becot at deveryware.com  Fri Sep 22 11:39:50 2023
From: jerome.becot at deveryware.com (=?UTF-8?B?SsOpcsO0bWUgQkVDT1Q=?=)
Date: Fri, 22 Sep 2023 13:39:50 +0200
Subject: [Nova][Neutron] Help troubleshooting metadata service error 404
 (Ussuri)
In-Reply-To: <1b4afce6-d860-821c-4909-546e0e8c1729@deveryware.com>
References: <1b4afce6-d860-821c-4909-546e0e8c1729@deveryware.com>
Message-ID: <89ae9d42-1a2e-37b4-837f-59e6ac06f4ad@deveryware.com>

After spending some time it seems that it is a problem in the 
instances... but still I don't have a clue: it works when running as 
root and doesn't with other users ...

Le 22/09/2023 ? 12:49, J?r?me BECOT a ?crit?:
>
> 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>
-- 
*J?r?me BECOT*
Ing?nieur DevOps Infrastructure

T?l?phone fixe: 01 82 28 37 06
Mobile : +33 757 173 193
Deveryware - 43 rue Taitbout - 75009 PARIS
https://www.deveryware.com <https://www.deveryware.com>

Deveryware_Logo
<https://www.deveryware.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/4b556b23/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baniere_signature_dw_2022.png
Type: image/png
Size: 471995 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/4b556b23/attachment-0001.png>

From finarffin at gmail.com  Fri Sep 22 13:04:05 2023
From: finarffin at gmail.com (Jan Wasilewski)
Date: Fri, 22 Sep 2023 15:04:05 +0200
Subject: Problem with Barbican
In-Reply-To: <1503834122.6866945.1695286409426@mail.yahoo.com>
References: <1503834122.6866945.1695286409426.ref@mail.yahoo.com>
 <1503834122.6866945.1695286409426@mail.yahoo.com>
Message-ID: <CAN4DDNghjBoVDbTEHP3zTWgvRwyizYzdpKNsQ6eDXds1b1WBgw@mail.gmail.com>

Hi Derek,

Could you please share your 'barbican.conf' file along with information
about the operating system on which Docker and Barbican are running?
This additional information would shed more light on the topic and help
with further troubleshooting. There may be a configuration issue that needs
to be addressed.

/Jan Wasilewski

czw., 21 wrz 2023 o 11:54 Derek O keeffe <derekokeeffe85 at yahoo.ie>
napisa?(a):

> 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!
> <https://paste.openstack.org/show/bU1E0joDdf4eWiV8wjlj/>
>
> Paste #bU1E0joDdf4eWiV8wjlj | LodgeIt!
>
> <https://paste.openstack.org/show/bU1E0joDdf4eWiV8wjlj/>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/56bd0190/attachment.htm>

From jerome.becot at deveryware.com  Fri Sep 22 14:10:54 2023
From: jerome.becot at deveryware.com (=?UTF-8?B?SsOpcsO0bWUgQkVDT1Q=?=)
Date: Fri, 22 Sep 2023 16:10:54 +0200
Subject: [Nova][Neutron] Help troubleshooting metadata service error 404
 (Ussuri)
In-Reply-To: <6c2c4707-27e8-0459-1367-94e0b3c3274e@deveryware.com>
References: <1b4afce6-d860-821c-4909-546e0e8c1729@deveryware.com>
 <6c2c4707-27e8-0459-1367-94e0b3c3274e@deveryware.com>
Message-ID: <49e0dba7-e4cd-74dd-5ebe-4ebad183a586@deveryware.com>

It finally turned out that the impacted machines deployed a proxy 
configuration that is loaded in the environment. We added an exception 
for 169.254.169.254 and it now works fine.

Regards

Le 22/09/2023 ? 13:41, J?r?me BECOT a ?crit?:
>
> After spending some time it seems that it is a problem in the 
> instances... but still I don't have a clue: it works when running as 
> root or sudo and doesn't with regular users ...
>
> Le 22/09/2023 ? 12:49, J?r?me BECOT a ?crit?:
>>
>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/1381bcfa/attachment.htm>

From hberaud at redhat.com  Fri Sep 22 14:59:28 2023
From: hberaud at redhat.com (Herve Beraud)
Date: Fri, 22 Sep 2023 16:59:28 +0200
Subject: [release] Release countdown for week R-1 Sept 25-29
Message-ID: <CAFDq9gXbASkq01oG-1fBbAgH=_Hf2tLeG4KBWziQTRJFwguTXA@mail.gmail.com>

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/ba4a1985/attachment-0001.htm>

From ekuvaja at redhat.com  Fri Sep 22 15:04:14 2023
From: ekuvaja at redhat.com (Erno Kuvaja)
Date: Fri, 22 Sep 2023 16:04:14 +0100
Subject: [aodh][mistral][solum][release][requirements] Feature freeze
 exception for wsme, sphinxcontrib-pecanwsme
In-Reply-To: <7628cd578cb9fc1a2299afd44cbbec01802f1da4.camel@redhat.com>
References: <7628cd578cb9fc1a2299afd44cbbec01802f1da4.camel@redhat.com>
Message-ID: <CAKwVDDPLvZKz+AuOoqz3FhZ__7n43Hr86wS0Bq_FXUtrbG76pQ@mail.gmail.com>

On Fri, 22 Sept 2023 at 11:04, Stephen Finucane <stephenfin at redhat.com>
wrote:

> 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/035190.html
> [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
>
>
+1

Thanks Stephen for whipping up this all together so quickly!

- Erno "jokke" Kuvaja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/6bcd973e/attachment.htm>

From jerome.becot at deveryware.com  Fri Sep 22 14:10:25 2023
From: jerome.becot at deveryware.com (=?UTF-8?B?SsOpcsO0bWUgQkVDT1Q=?=)
Date: Fri, 22 Sep 2023 16:10:25 +0200
Subject: [Nova][Neutron] Help troubleshooting metadata service error 404
 (Ussuri)
In-Reply-To: <6c2c4707-27e8-0459-1367-94e0b3c3274e@deveryware.com>
References: <1b4afce6-d860-821c-4909-546e0e8c1729@deveryware.com>
 <6c2c4707-27e8-0459-1367-94e0b3c3274e@deveryware.com>
Message-ID: <05b2792a-f94b-1576-b7d9-90a8ce054260@deveryware.com>

It finally turned out that the impacted machines deployed a proxy 
configuration that is loaded in the environment. We added an exception 
for 169.254.169.254 and it now works fine.

Regards

Le 22/09/2023 ? 13:41, J?r?me BECOT a ?crit?:
>
> After spending some time it seems that it is a problem in the 
> instances... but still I don't have a clue: it works when running as 
> root or sudo and doesn't with regular users ...
>
> Le 22/09/2023 ? 12:49, J?r?me BECOT a ?crit?:
>>
>> 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>
-- 
*J?r?me BECOT*
Ing?nieur DevOps Infrastructure

T?l?phone fixe: 01 82 28 37 06
Mobile : +33 757 173 193
Deveryware - 43 rue Taitbout - 75009 PARIS
https://www.deveryware.com <https://www.deveryware.com>

Deveryware_Logo
<https://www.deveryware.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/ecab5052/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baniere_signature_dw_2022.png
Type: image/png
Size: 471995 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230922/ecab5052/attachment-0001.png>

From gmann at ghanshyammann.com  Fri Sep 22 19:35:29 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 22 Sep 2023 12:35:29 -0700
Subject: [all][tc] python 3.11 testing plan
In-Reply-To: <18a7062b69d.d3f024e6645938.1764325247310912451@ghanshyammann.com>
References: <18a19500dda.1179e4341294220.8475553822244831650@ghanshyammann.com>
 <18a7062b69d.d3f024e6645938.1764325247310912451@ghanshyammann.com>
Message-ID: <18abe63da6e.e7d9cd381153099.9192783874404964687@ghanshyammann.com>

 ---- On Thu, 07 Sep 2023 09:03:52 -0700  Ghanshyam Mann  wrote --- 
 >  ---- On Mon, 21 Aug 2023 11:16:31 -0700  Ghanshyam Mann  wrote --- 
 >  > Hi All,
 > Hello Everyone,
 > 
 > Many projects still need to fix the py3.11 job[1]. I started fixing a few of them, so changes are up
 > for review of those projects.
 > 
 > NOTE: The deadline to fix is the 2023.2 release (Oct 6th); after that, this job will become voting on the
 > master (2024.1 dev cycle but remain non-voting on stable/2023.2) and will block the master gate.
 > 
 > [1] https://zuul.openstack.org/builds?job_name=openstack-tox-py311+&result=RETRY_LIMIT&result=RETRY&result=CONFIG_ERROR&result=FAILURE&skip=0&limit=100

Hello Everyone,

This a gentle reminder to fix your project py3.11 job if failing ^^

This job will become voting right after the 2023.2 release on October 4th.

-gmann

 > 
 > 
 > -gmann
 > 
 >  > 
 >  > 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
 >  > 
 >  > 
 > 


From satish.txt at gmail.com  Sun Sep 24 10:49:37 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Sun, 24 Sep 2023 06:49:37 -0400
Subject: [kolla-ansible][keystone][skyline] Keystone use SSO for
 authentication
In-Reply-To: <CABAODRfKte90m+RseXko_NPbXo-s5tmUR3ywXe8W5HsyQAivkw@mail.gmail.com>
References: <CABAODRfKte90m+RseXko_NPbXo-s5tmUR3ywXe8W5HsyQAivkw@mail.gmail.com>
Message-ID: <33BC7D20-ABA0-4421-8C60-1C851515337D@gmail.com>

Good work man!! 

Sent from my iPhone

> On Sep 22, 2023, at 1:02 AM, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
> 
> ?
> 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%20sso.md
> 
> I will try to contribute what I can for newbies and community.
> 
> 
> Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230924/2d328d6c/attachment.htm>

From danish52.jmi at gmail.com  Sun Sep 24 17:27:46 2023
From: danish52.jmi at gmail.com (Danish Khan)
Date: Sun, 24 Sep 2023 22:57:46 +0530
Subject: [openstack-ansible][manila deployment] error: No valid host was found
Message-ID: <CABWYFkz8tgYLSD3aMYrY747HL8p49vY_MJi2hfhm-zf3Lnx4TA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230924/02d0eeaa/attachment.htm>

From kkloppenborg at resetdata.com.au  Sun Sep 24 23:10:29 2023
From: kkloppenborg at resetdata.com.au (Karl Kloppenborg)
Date: Sun, 24 Sep 2023 23:10:29 +0000
Subject: [kolla-ansible][keystone][skyline] Keystone use SSO for
 authentication
In-Reply-To: <33BC7D20-ABA0-4421-8C60-1C851515337D@gmail.com>
References: <CABAODRfKte90m+RseXko_NPbXo-s5tmUR3ywXe8W5HsyQAivkw@mail.gmail.com>
 <33BC7D20-ABA0-4421-8C60-1C851515337D@gmail.com>
Message-ID: <ME3P282MB08831F16D2AA2C25BA4673AEFAFDA@ME3P282MB0883.AUSP282.PROD.OUTLOOK.COM>

Yeah that?s really good work!
Interesting SSO implementation!

From: Satish Patel <satish.txt at gmail.com>
Date: Sunday, 24 September 2023 at 9:01 pm
To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [kolla-ansible][keystone][skyline] Keystone use SSO for authentication
Good work man!!
Sent from my iPhone


On Sep 22, 2023, at 1:02 AM, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
?
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%20sso.md

I will try to contribute what I can for newbies and community.


Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230924/ba791f53/attachment.htm>

From pierre at stackhpc.com  Mon Sep 25 07:42:26 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Mon, 25 Sep 2023 09:42:26 +0200
Subject: [all][tc] python 3.11 testing plan
In-Reply-To: <18abe63da6e.e7d9cd381153099.9192783874404964687@ghanshyammann.com>
References: <18a19500dda.1179e4341294220.8475553822244831650@ghanshyammann.com>
 <18a7062b69d.d3f024e6645938.1764325247310912451@ghanshyammann.com>
 <18abe63da6e.e7d9cd381153099.9192783874404964687@ghanshyammann.com>
Message-ID: <CA+ny2sydEvTwX0LPGBXz5uRFXM4rUoqLzafpRDeDCQrF3x=dYg@mail.gmail.com>

Je On Fri, 22 Sept 2023 at 21:39, Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- On Thu, 07 Sep 2023 09:03:52 -0700  Ghanshyam Mann  wrote ---
>  >  ---- On Mon, 21 Aug 2023 11:16:31 -0700  Ghanshyam Mann  wrote ---
>  >  > Hi All,
>  > Hello Everyone,
>  >
>  > Many projects still need to fix the py3.11 job[1]. I started fixing a
> few of them, so changes are up
>  > for review of those projects.
>  >
>  > NOTE: The deadline to fix is the 2023.2 release (Oct 6th); after that,
> this job will become voting on the
>  > master (2024.1 dev cycle but remain non-voting on stable/2023.2) and
> will block the master gate.
>  >
>  > [1]
> https://zuul.openstack.org/builds?job_name=openstack-tox-py311+&result=RETRY_LIMIT&result=RETRY&result=CONFIG_ERROR&result=FAILURE&skip=0&limit=100
>
> Hello Everyone,
>
> This a gentle reminder to fix your project py3.11 job if failing ^^
>
> This job will become voting right after the 2023.2 release on October 4th.
>
> -gmann


Many projects initially fail on bindep trying to install mysql-client,
which doesn't exist in bookworm. Fixing this was enough to make the py3.11
job successful in Blazar.

Are there templates to follow for these bindep requirements? I checked
projects such as Cinder, Glance, Neutron and Nova: they are using similar
package lists but with small differences.

And is it useful to keep testing with MySQL on Ubuntu, so we have coverage
for both MySQL and MariaDB?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230925/502cda30/attachment-0001.htm>

From ralonsoh at redhat.com  Mon Sep 25 08:10:58 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Mon, 25 Sep 2023 10:10:58 +0200
Subject: [all][tc] python 3.11 testing plan
In-Reply-To: <CA+ny2sydEvTwX0LPGBXz5uRFXM4rUoqLzafpRDeDCQrF3x=dYg@mail.gmail.com>
References: <18a19500dda.1179e4341294220.8475553822244831650@ghanshyammann.com>
 <18a7062b69d.d3f024e6645938.1764325247310912451@ghanshyammann.com>
 <18abe63da6e.e7d9cd381153099.9192783874404964687@ghanshyammann.com>
 <CA+ny2sydEvTwX0LPGBXz5uRFXM4rUoqLzafpRDeDCQrF3x=dYg@mail.gmail.com>
Message-ID: <CAECr9X53iGwon6UMmF2UNTn4GhYT2ywmW_wOAnyu2NDcF-5K6g@mail.gmail.com>

Hello all:

The errors present in this list related to Neutron belong to failed
patches. In all cases, the same errors are present in py310 and py38. I've
pushed [1] and all UT jobs are passing.

Regards.

[1]https://review.opendev.org/c/openstack/neutron/+/896351

On Mon, Sep 25, 2023 at 9:44?AM Pierre Riteau <pierre at stackhpc.com> wrote:

> Je On Fri, 22 Sept 2023 at 21:39, Ghanshyam Mann <gmann at ghanshyammann.com>
> wrote:
>
>>  ---- On Thu, 07 Sep 2023 09:03:52 -0700  Ghanshyam Mann  wrote ---
>>  >  ---- On Mon, 21 Aug 2023 11:16:31 -0700  Ghanshyam Mann  wrote ---
>>  >  > Hi All,
>>  > Hello Everyone,
>>  >
>>  > Many projects still need to fix the py3.11 job[1]. I started fixing a
>> few of them, so changes are up
>>  > for review of those projects.
>>  >
>>  > NOTE: The deadline to fix is the 2023.2 release (Oct 6th); after that,
>> this job will become voting on the
>>  > master (2024.1 dev cycle but remain non-voting on stable/2023.2) and
>> will block the master gate.
>>  >
>>  > [1]
>> https://zuul.openstack.org/builds?job_name=openstack-tox-py311+&result=RETRY_LIMIT&result=RETRY&result=CONFIG_ERROR&result=FAILURE&skip=0&limit=100
>>
>> Hello Everyone,
>>
>> This a gentle reminder to fix your project py3.11 job if failing ^^
>>
>> This job will become voting right after the 2023.2 release on October 4th.
>>
>> -gmann
>
>
> Many projects initially fail on bindep trying to install mysql-client,
> which doesn't exist in bookworm. Fixing this was enough to make the py3.11
> job successful in Blazar.
>
> Are there templates to follow for these bindep requirements? I checked
> projects such as Cinder, Glance, Neutron and Nova: they are using similar
> package lists but with small differences.
>
> And is it useful to keep testing with MySQL on Ubuntu, so we have coverage
> for both MySQL and MariaDB?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230925/abe3b4a5/attachment.htm>

From bcafarel at redhat.com  Mon Sep 25 08:26:12 2023
From: bcafarel at redhat.com (Bernard Cafarelli)
Date: Mon, 25 Sep 2023 10:26:12 +0200
Subject: [neutron] Bug deputy report (week starting on September 18)
Message-ID: <CABHdKwo-tdtj911gb=Vk9BQzY3zedunmuGnHkcVqe0US2DkC6g@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230925/8ce2e5b9/attachment.htm>

From dhana.sys at gmail.com  Mon Sep 25 13:40:50 2023
From: dhana.sys at gmail.com (Dhanasekar Kandasamy)
Date: Mon, 25 Sep 2023 19:10:50 +0530
Subject: [openstack][neutron] OpenStack deployment
Message-ID: <CA+eBsZYdHSMptCY8f0=tx_6B+eKG5qtUDWQSBH7q_+mPsEQNow@mail.gmail.com>

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/20230925/fa10de65/attachment.htm>

From fungi at yuggoth.org  Mon Sep 25 13:43:24 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 25 Sep 2023 13:43:24 +0000
Subject: [all][tc] python 3.11 testing plan
In-Reply-To: <CA+ny2sydEvTwX0LPGBXz5uRFXM4rUoqLzafpRDeDCQrF3x=dYg@mail.gmail.com>
References: <18a19500dda.1179e4341294220.8475553822244831650@ghanshyammann.com>
 <18a7062b69d.d3f024e6645938.1764325247310912451@ghanshyammann.com>
 <18abe63da6e.e7d9cd381153099.9192783874404964687@ghanshyammann.com>
 <CA+ny2sydEvTwX0LPGBXz5uRFXM4rUoqLzafpRDeDCQrF3x=dYg@mail.gmail.com>
Message-ID: <20230925134323.r6uvp733qneljyyu@yuggoth.org>

On 2023-09-25 09:42:26 +0200 (+0200), Pierre Riteau wrote:
[...]
> Many projects initially fail on bindep trying to install
> mysql-client, which doesn't exist in bookworm. Fixing this was
> enough to make the py3.11 job successful in Blazar.

As you indicate, in that particular case it's nothing to do with the
version of Python, but rather changes in the distribution platforms
you're testing on. You don't have to remove mysql-client from
bindep.txt, for example you can just specify that it should only be
installed on Ubuntu and not Debian, and that mariadb-client should
be installed only on Debian. Alternatively, you can switch to
installing default-mysql-client on both Debian and Ubuntu, which is
a metapackage depending on mariadb-client on Debian and mysql-client
on Ubuntu.

> Are there templates to follow for these bindep requirements? I
> checked projects such as Cinder, Glance, Neutron and Nova: they
> are using similar package lists but with small differences.

Not really, no. Every project has different things they need to
install for testing purposes, and the requirement description
language bindep uses is expressive enough that there are multiple
ways to go about describing the relationships you want. The only
real guidance that might be important is to, where possible, use
exclusions for old platforms where newer package choices aren't
available and inclusions for old platforms on the old packages which
aren't available on newer platforms, so that you avoid unnecessary
churn on existing entries every time you want to start testing a
newer release of some distro and it's clearer what you can clean up.

A good example can be found in https://review.opendev.org/895699
which installs dnf on dpkg-based platforms except if they're older,
and installs yum-utils exclusively on older platforms. In the
future, as the old distributions are cleaned up from the bindep.txt,
the result will be that dnf is installed on all dpkg-based platforms
and yum-utils is no longer listed.

> And is it useful to keep testing with MySQL on Ubuntu, so we have
> coverage for both MySQL and MariaDB?

If projects are using the clients directly, or directly querying
databases, then interface and syntax differences between them might
matter. Ideally, with everything going through an ORM, you shouldn't
have to care which one is used as long as their differences are
abstracted away by the ORM (with the expectation that the
maintainers of that ORM are thoroughly testing with both supported
backends anyway).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230925/3d5812eb/attachment.sig>

From ces.eduardo98 at gmail.com  Mon Sep 25 15:19:26 2023
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Mon, 25 Sep 2023 12:19:26 -0300
Subject: [openstack-ansible][manila deployment] error: No valid host was
 found
In-Reply-To: <CABWYFkz8tgYLSD3aMYrY747HL8p49vY_MJi2hfhm-zf3Lnx4TA@mail.gmail.com>
References: <CABWYFkz8tgYLSD3aMYrY747HL8p49vY_MJi2hfhm-zf3Lnx4TA@mail.gmail.com>
Message-ID: <CAE51gQK1Fe57NA6gCtgudSs7AsCOVkv-qOJihSKSsfk2uRWXbQ@mail.gmail.com>

Hello!


Em dom., 24 de set. de 2023 ?s 14:33, Danish Khan <danish52.jmi at gmail.com>
escreveu:

> 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.
>
> Apparently, it is failing to schedule the shares. One exercise you could
do is try to run this command using admin credentials:
$ manila pool-list --share-type <your-share-type-name-or-id>

This will use the scheduler to filter backends matching the share type you
provided. If nothing is returned, it means that your share type and backend
declarations aren't matching. But I believe the issue is related to the
other issue you pointed out...

>
> 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.
>

This `driver_handles_share_servers` config opt should be set either to True
or False in the backend configuration. If nothing is set, Manila can't
identify which driver mode you will use and will fail to schedule shares,
so please ensure that the `driver_handles_share_servers` flag is properly
configured in the backend stanza in the manila.conf file.If it is not, it
might be missing from your deployment, and you must set it.

Also, please ensure that the backend capabilities match your share type
capabilities [1].

[1]
https://docs.openstack.org/manila/latest/admin/capabilities_and_extra_specs.html

Regards,
carloss


>
> Thanks in advance.
>
> Regards,
> Danish
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230925/fd0902a5/attachment.htm>

From gmann at ghanshyammann.com  Mon Sep 25 17:03:35 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 25 Sep 2023 10:03:35 -0700
Subject: [all][tc] python 3.11 testing plan
In-Reply-To: <CA+ny2sydEvTwX0LPGBXz5uRFXM4rUoqLzafpRDeDCQrF3x=dYg@mail.gmail.com>
References: <18a19500dda.1179e4341294220.8475553822244831650@ghanshyammann.com>
 <18a7062b69d.d3f024e6645938.1764325247310912451@ghanshyammann.com>
 <18abe63da6e.e7d9cd381153099.9192783874404964687@ghanshyammann.com>
 <CA+ny2sydEvTwX0LPGBXz5uRFXM4rUoqLzafpRDeDCQrF3x=dYg@mail.gmail.com>
Message-ID: <18acd4bdaa1.adc80cb11260047.6535059815791577073@ghanshyammann.com>

---- On Mon, 25 Sep 2023 00:42:26 -0700  Pierre Riteau  wrote --- 
 > Je On Fri, 22 Sept 2023 at 21:39, Ghanshyam Mann gmann at ghanshyammann.com> wrote:
 > ?---- On Thu, 07 Sep 2023 09:03:52 -0700? Ghanshyam Mann? wrote --- 
 > ?>? ---- On Mon, 21 Aug 2023 11:16:31 -0700? Ghanshyam Mann? wrote --- 
 > ?>? > Hi All,
 > ?> Hello Everyone,
 > ?> 
 > ?> Many projects still need to fix the py3.11 job[1]. I started fixing a few of them, so changes are up
 > ?> for review of those projects.
 > ?> 
 > ?> NOTE: The deadline to fix is the 2023.2 release (Oct 6th); after that, this job will become voting on the
 > ?> master (2024.1 dev cycle but remain non-voting on stable/2023.2) and will block the master gate.
 > ?> 
 > ?> [1] https://zuul.openstack.org/builds?job_name=openstack-tox-py311+&result=RETRY_LIMIT&result=RETRY&result=CONFIG_ERROR&result=FAILURE&skip=0&limit=100
 > 
 > Hello Everyone,
 > 
 > This a gentle reminder to fix your project py3.11 job if failing ^^
 > 
 > This job will become voting right after the 2023.2 release on October 4th.
 > 
 > -gmann
 > Many projects initially fail on bindep trying to install mysql-client, which doesn't exist in bookworm. Fixing this was enough to make the py3.11 job successful in Blazar.
 > Are there templates to follow for these bindep requirements? I checked projects such as Cinder, Glance, Neutron and Nova: they are using similar package lists but with small differences.

Most of it are change in mysql-client not to install for debian and add maridb client, but there are some code
failure too for example Tacker - https://review.opendev.org/c/openstack/tacker/+/893867

You can see the required changes with the below gerrit topic and can get idea of what all different
changes are applied to projects. 

- https://review.opendev.org/q/topic:py311

-gmann

 > And is it useful to keep testing with MySQL on Ubuntu, so we have coverage for both MySQL and MariaDB?


From james.page at canonical.com  Tue Sep 26 08:30:36 2023
From: james.page at canonical.com (James Page)
Date: Tue, 26 Sep 2023 09:30:36 +0100
Subject: [all][elections][ptl] Project Team Lead Election Conclusion and
 Results
In-Reply-To: <CAFT5D2ShvXfMPO+U+BVDCbwipsPLdaCGZ+dWgva0F9ZhLFCm2Q@mail.gmail.com>
References: <CAFT5D2ShvXfMPO+U+BVDCbwipsPLdaCGZ+dWgva0F9ZhLFCm2Q@mail.gmail.com>
Message-ID: <CAG1bqQqFk8vwQ86VpsxHCXUKSUd24T6frsQk4MKb9DLepDk2cg@mail.gmail.com>

Hi Tony

On Thu, Sep 21, 2023 at 12:57?AM Tony Breeds <tony at bakeyournoodle.com>
wrote:

> Thank you to the electorate, to all those who voted and to all
> candidates who put their name forward for Project Team Lead (PTL) in
> this election. A healthy, open process breeds trust in our decision
> making capability thank you to all those who make this process
> possible.
>
> Now for the results of the PTL election process, please join me in
> extending congratulations to the following PTLs:
>
> * Adjutant : Dale Smith
> * Barbican : Grzegorz Grasza
> * Blazar : Pierre Riteau
> * Cinder : Rajat Dhasmana
> * Cloudkitty : Rafael Weingartner
> * Designate : Michael Johnson
> * Freezer : ge cong
> * Glance : Pranali Deore
> * Heat : Takashi Kajinami
> * Horizon : Vishal Manchanda
> * Ironic : Jay Faulkner
> * Keystone : Dave Wilde
> * Kolla : Michal Nasiadka
> * Kuryr : Roman Dobosz
> * Magnum : Jake Yip
> * Manila : Carlos Silva
> * Masakari : sam sue
> * Murano : Rong Zhu
> * Neutron : Brian Haley
> * Nova : Sylvain Bauza
> * Octavia : Gregory Thiemonge
> * OpenStack Charms : Felipe Reyes
> * OpenStack Helm : Vladimir Kozhukalov
> * OpenStackAnsible : Dmitriy Rabotyagov
> * OpenStackSDK : Artem Goncharov
> * Puppet OpenStack : Takashi Kajinami
> * Quality Assurance : Martin Kopec
> * Solum : Rong Zhu
> * Storlets : Takashi Kajinami
> * Swift : Tim Burke
> * Tacker : Yasufumi Ogawa
> * Telemetry : Erno Kuvaja
> * Vitrage : Dmitriy Rabotyagov
> * Watcher : chen ke
> * Zaqar : Hao Wang
> * Zun : Hongbin Lu
>
> Elections:
> * OpenStack_Helm:
> https://civs1.civs.us/cgi-bin/results.pl?id=E_3cf498bb10adc5b8
>
> Election process details and results are also available here:
> https://governance.openstack.org/election/
>
> Thank you to all involved in the PTL election process,


I already mentioned in #openstack-tc that Sunbeam is not leaderless - I
just managed to miss that I needed to propose myself as PTL which was an
oversight on my behalf.

Please consider this email my candidacy for PTL of Sunbeam for the TC to
consider.

Thanks

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230926/ac9d18e8/attachment-0001.htm>

From hberaud at redhat.com  Tue Sep 26 10:05:02 2023
From: hberaud at redhat.com (Herve Beraud)
Date: Tue, 26 Sep 2023 12:05:02 +0200
Subject: [oslo][heat][requirements] RFE requested for oslo.messaging
Message-ID: <CAFDq9gWzuQcpm+XF=wwYMxiqPrqQvQbJAcVVcQYpRUc64FE3xw@mail.gmail.com>

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-constraints.txt#L164
[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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230926/2bf34ebf/attachment.htm>

From hberaud at redhat.com  Tue Sep 26 10:45:39 2023
From: hberaud at redhat.com (Herve Beraud)
Date: Tue, 26 Sep 2023 12:45:39 +0200
Subject: [release][requirements][TC][oslo] how to manage divergence
 between runtime and doc?
In-Reply-To: <CAFDq9gXbAgjCpYk0_em7rnKYd1=jU6OYSc-N5dDrhorBQhXhLA@mail.gmail.com>
References: <CAFDq9gXbAgjCpYk0_em7rnKYd1=jU6OYSc-N5dDrhorBQhXhLA@mail.gmail.com>
Message-ID: <CAFDq9gW=w_wnkyfOG1gr7gnM5Pk2tjV6X2_8r75j6QCYyjaVPg@mail.gmail.com>

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/035184.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 :

> 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-constraints.txt#L482
> [2] https://releases.openstack.org/bobcat/index.html#bobcat-oslo-db
> [3]
> https://opendev.org/openstack/releases/src/branch/master/deliverables/antelope/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/035100.html
> [8]
> https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html
> [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/115c3247b486c713176139422647144108101ca3
> [13]
> https://opendev.org/openstack/oslo.db/commit/4ee79141e601482fcde02f0cecfb561ecb79e1b6
> [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-and-milestone-3
>
> --
> Herv? Beraud
> Senior Software Engineer at Red Hat
> irc: hberaud
> https://github.com/4383/
>
>

-- 
Herv? Beraud
Senior Software Engineer at Red Hat
irc: hberaud
https://github.com/4383/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230926/02bdeebe/attachment-0001.htm>

From satish.txt at gmail.com  Tue Sep 26 12:06:47 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 26 Sep 2023 08:06:47 -0400
Subject: [openstack][neutron] OpenStack deployment
In-Reply-To: <CA+eBsZYdHSMptCY8f0=tx_6B+eKG5qtUDWQSBH7q_+mPsEQNow@mail.gmail.com>
References: <CA+eBsZYdHSMptCY8f0=tx_6B+eKG5qtUDWQSBH7q_+mPsEQNow@mail.gmail.com>
Message-ID: <0695D533-7F6D-4B95-8148-E5A2336C8649@gmail.com>

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/20230926/a8696073/attachment.htm>

From knikolla at bu.edu  Tue Sep 26 13:38:18 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Tue, 26 Sep 2023 13:38:18 +0000
Subject: [tc][all] Please welcome Jay Faulkner as new Chair of Technical
 Committee
Message-ID: <BL0PR03MB4227BD4FB3C331EB22AEFEB2BEC3A@BL0PR03MB4227.namprd03.prod.outlook.com>

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/20230926/a22b2d42/attachment.htm>

From ralonsoh at redhat.com  Tue Sep 26 15:43:05 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Tue, 26 Sep 2023 17:43:05 +0200
Subject: [tc][all] Please welcome Jay Faulkner as new Chair of Technical
 Committee
In-Reply-To: <BL0PR03MB4227BD4FB3C331EB22AEFEB2BEC3A@BL0PR03MB4227.namprd03.prod.outlook.com>
References: <BL0PR03MB4227BD4FB3C331EB22AEFEB2BEC3A@BL0PR03MB4227.namprd03.prod.outlook.com>
Message-ID: <CAECr9X68em5moy2TUDkfYHFZWZC4z+2gbzrqWbqbhFpDDiBOtw@mail.gmail.com>

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/20230926/442f33d2/attachment.htm>

From gmann at ghanshyammann.com  Tue Sep 26 16:07:44 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 26 Sep 2023 09:07:44 -0700
Subject: [release][requirements][TC][oslo] how to manage divergence
 between runtime and doc?
In-Reply-To: <CAFDq9gW=w_wnkyfOG1gr7gnM5Pk2tjV6X2_8r75j6QCYyjaVPg@mail.gmail.com>
References: <CAFDq9gXbAgjCpYk0_em7rnKYd1=jU6OYSc-N5dDrhorBQhXhLA@mail.gmail.com>
 <CAFDq9gW=w_wnkyfOG1gr7gnM5Pk2tjV6X2_8r75j6QCYyjaVPg@mail.gmail.com>
Message-ID: <18ad23f1717.1112162185074.1090350270406337793@ghanshyammann.com>

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/035184.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-constraints.txt#L482
 > [2] https://releases.openstack.org/bobcat/index.html#bobcat-oslo-db
 > [3] https://opendev.org/openstack/releases/src/branch/master/deliverables/antelope/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/035100.html
 > [8] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html
 > [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/115c3247b486c713176139422647144108101ca3
 > [13] https://opendev.org/openstack/oslo.db/commit/4ee79141e601482fcde02f0cecfb561ecb79e1b6
 > [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-and-milestone-3
 > 
 > -- 
 > Herv? BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/
 > 
 > 


From knikolla at bu.edu  Tue Sep 26 16:27:59 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Tue, 26 Sep 2023 16:27:59 +0000
Subject: [tc] Technical Committee next weekly meeting Today on September 26,
 2023
Message-ID: <690E4235-EADC-4BC7-973A-B06CFA783DB0@bu.edu>

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

From asma.naz at techavenue.biz  Wed Sep 27 04:12:02 2023
From: asma.naz at techavenue.biz (Asma Naz Shariq)
Date: Wed, 27 Sep 2023 09:12:02 +0500
Subject: openstack- Deployment through kolla ansible
Message-ID: <000401d9f0f8$c51391d0$4f3ab570$@techavenue.biz>

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
*************************************************



From mnasiadka at gmail.com  Wed Sep 27 08:16:33 2023
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Wed, 27 Sep 2023 10:16:33 +0200
Subject: [magnum] Weekly meeting today (27th Sep 2023) cancelled
Message-ID: <39F22E60-E132-4717-BE11-62080D6A9AF8@gmail.com>

Hello,

Since key members are absent - let?s cancel this weeks (27th Sep 2023) meeting.

Best regards,
Michal

From nguyenhuukhoinw at gmail.com  Wed Sep 27 12:23:50 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 27 Sep 2023 19:23:50 +0700
Subject: [openstack][nova][cinder] how can we know instance disk usage
Message-ID: <CABAODRc2KXGD4Fg88O-otEJ6sOxU8B8bGB69OV0SsjjOu=WB1g@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230927/d086709a/attachment.htm>

From mkopec at redhat.com  Wed Sep 27 13:19:34 2023
From: mkopec at redhat.com (Martin Kopec)
Date: Wed, 27 Sep 2023 15:19:34 +0200
Subject: [qa][ptg] Virtual Caracal vPTG Planning
Message-ID: <CAKZGdE01+324+uG11aJKvgym4_YvX-AUnLLm+pb5fPQE-kz7Nw@mail.gmail.com>

Hello everyone,

here is [1] our etherpad for the 2024.1 Caracal virtual PTG. Please, add
your topics there if there is anything you would like to discuss / propose
...

You can also vote for time slots for our sessions so that they fit your
schedule at [2].

We will most likely go with 1-hour slot per day, as they usually fit easier
into everyone's schedule. The number of slots will depend on the number of
topics proposed in [1].

- [1] https://etherpad.opendev.org/p/oct2023-ptg-qa
[2] https://framadate.org/f26R3EcZ2BOo7r8Q

Thanks,
-- 
Martin Kopec
Principal Software Quality Engineer
Red Hat EMEA
IM: kopecmartin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230927/2ee88313/attachment.htm>

From mkopec at redhat.com  Wed Sep 27 13:24:35 2023
From: mkopec at redhat.com (Martin Kopec)
Date: Wed, 27 Sep 2023 15:24:35 +0200
Subject: [interop][ptg] Virtual Caracal vPTG Planning
Message-ID: <CAKZGdE2VNPyZUH-AGc63UMKHPmffe0WtG=DaiGmXek8XDUYpxw@mail.gmail.com>

Hello everyone,

here is [1] our etherpad for the 2024.1 Caracal virtual PTG. Please, add
your topics there if there is anything you would like to discuss / propose
...

You can also vote for time slots for our session(s), so that they fit your
schedule, at [2].

I have one topic I'd like to discuss - new view on interoperability
testing, see [3] and this [4] article for the background info.

[1] https://etherpad.opendev.org/p/oct2023-ptg-interop
[2] https://framadate.org/rNFvjKVkMnXPfObf
[3] https://etherpad.opendev.org/p/openstack-interop-2.0
[4]
https://superuser.openinfra.dev/articles/new-view-on-interoperability-in-openstack/

If you have any questions, feel free to reach out to me.

Thanks,
-- 
Martin Kopec
Principal Software Quality Engineer
Red Hat EMEA
IM: kopecmartin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230927/97786d85/attachment.htm>

From ygk.kmr at gmail.com  Wed Sep 27 14:11:13 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Wed, 27 Sep 2023 19:41:13 +0530
Subject: Wsgi in openstack
Message-ID: <CAJreVFx2th76R1kvfe_AnGRYbjjXjCr+J0R2jfBw6TBkPPYuAA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230927/5a466d2f/attachment.htm>

From Kburall at applied-insight.com  Wed Sep 27 14:35:03 2023
From: Kburall at applied-insight.com (Kyle Burall)
Date: Wed, 27 Sep 2023 14:35:03 +0000
Subject: [kolla-ansible] Deploying an kolla-ansible all-in-one to test
 enforce_scope
Message-ID: <SJ1PR12MB62921225D547C0E90DA54A95F4C2A@SJ1PR12MB6292.namprd12.prod.outlook.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230927/5df0be63/attachment-0001.htm>

From jobernar at redhat.com  Wed Sep 27 15:12:05 2023
From: jobernar at redhat.com (Jon Bernard)
Date: Wed, 27 Sep 2023 15:12:05 +0000
Subject: Cinder Bug Report 2023-09-27
Message-ID: <ZRRGRVCoJKA8kd21@localhost>

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



From stephenfin at redhat.com  Wed Sep 27 15:29:43 2023
From: stephenfin at redhat.com (Stephen Finucane)
Date: Wed, 27 Sep 2023 16:29:43 +0100
Subject: Wsgi in openstack
In-Reply-To: <CAJreVFx2th76R1kvfe_AnGRYbjjXjCr+J0R2jfBw6TBkPPYuAA@mail.gmail.com>
References: <CAJreVFx2th76R1kvfe_AnGRYbjjXjCr+J0R2jfBw6TBkPPYuAA@mail.gmail.com>
Message-ID: <73a9ae969326f53c49bcbb5c520fe1763900914d.camel@redhat.com>

On Wed, 2023-09-27 at 19:41 +0530, Gk Gk wrote:
> 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

Script for WSGI "entry points" are automatically generated by pbr, similar to
how standard setuptools builds scripts for console scripts:

https://github.com/openstack/pbr/blob/d03d617c09e7ba8ddf62d1e53d71685cd708e2da/pbr/packaging.py#L332-L384

If you build an sdist or wheel and extract it, you'll see the generated scripts
in there. You'll also see then in `bin` if you install e.g. nova and look at the
`nova-api` script.

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230927/93aa0984/attachment.htm>

From moonpiedumplings2 at gmail.com  Wed Sep 27 17:01:59 2023
From: moonpiedumplings2 at gmail.com (Moonpiedumplings TheSecond)
Date: Wed, 27 Sep 2023 10:01:59 -0700
Subject: [kolla-ansible][neutron] Kolla-ansible deployment where not all
 network nodes have access to the same external networks
Message-ID: <CAFhcaUAE9KrGkXt8vCc7Ja2+F=8NgCYtOYOK9vMaic6Jv8i9qQ@mail.gmail.com>

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,


From cyril at redhat.com  Wed Sep 27 18:28:36 2023
From: cyril at redhat.com (Cyril Roelandt)
Date: Wed, 27 Sep 2023 20:28:36 +0200
Subject: [all][tc] python 3.11 testing plan
In-Reply-To: <d8b79e02-95ae-311c-44c0-d2d79a716d4e@debian.org>
References: <18a19500dda.1179e4341294220.8475553822244831650@ghanshyammann.com>
 <d8b79e02-95ae-311c-44c0-d2d79a716d4e@debian.org>
Message-ID: <ZRR0VN53Ze5Xq2CQ@debian>

Hi,

On 2023-08-22 18:05, Thomas Goirand wrote:
> This is very nice, though, IMO, it's too late. Bookworm was released with
> OpenStack Zed, to which I already added Python 3.11 support (if you guys
> have some patches to add on top, let me know, but as much as I know, it was
> already functional).
> 
> So now, the current plan is to ... test on py3.11. Yeah, but from the Debian
> perspective, we're already on Python 3.12. The RC1 is already in Debian
> Experimental, and I expect 3.12 to reach Unstable by the end of this year.
> Once again, I'll be the sole person that will experimenting all the
> troubles. It's been YEARS like this. It's probably time to address it, no?
> 
> I'd really love it, if we could find a solution so that I stop to be the
> only person getting the shit in this world. :)

For what it's worth, I try to help test py3XX when the release
candidates come out. In the past I was able to find a regression in the
sqlite module[1] and propose some of the OpenStack py311 patches[2].

Regarding Python 3.12, I have been able to fix one of our
dependencies[3] and request a new package for another[4].

I run my tests by running "tox -repy312" on a bunch of OpenStack
projects using a 3.12rc2 container image. I often have to rebuild a few
wheels for dependencies that work with Python 3.12, but only on the
master/main branch, so I make sure to use these in my testing process. I
provide the image[5] for everyone to use, and intend to keep it updated
for the next release candidates of Python3.13+.


Regards,
Cyril

[1] https://github.com/python/cpython/issues/95132
[2] https://review.opendev.org/q/topic:py311
[3] https://github.com/ncclient/ncclient/pull/567
[4] https://github.com/sumerc/yappi/pull/148
[5] https://github.com/CyrilRoelandteNovance/py3-next-openstack



From gregory.orange at pawsey.org.au  Thu Sep 28 01:09:08 2023
From: gregory.orange at pawsey.org.au (Gregory Orange)
Date: Thu, 28 Sep 2023 09:09:08 +0800
Subject: [kolla] change default domain
In-Reply-To: <CAKxn-9RfFFYsriO-Wv_LG8VKJVxhK_E35TibP5BZnoH4vWoebw@mail.gmail.com>
References: <CAKxn-9RfFFYsriO-Wv_LG8VKJVxhK_E35TibP5BZnoH4vWoebw@mail.gmail.com>
Message-ID: <5059bebf-4137-91df-d995-e77dd42eea20@pawsey.org.au>

On 20/9/23 19:21, Vivian Rook wrote:
> I'm looking for a setting to change the default domain name from 
> "default" to "kolla" Does such an option exist in globals.yml?

Are you talking about the Horizon setting? We put this in globals.yml


horizon_keystone_domain_choices:
   pawsey: Pawsey
   Default: Default
horizon_keystone_multidomain: True


This results in a dropdown box for Domain at the login screen. Pawsey 
selected by default, although a browser cookie remembers which one users 
have most recently used.

HTH,
Greg.


From pdeore at redhat.com  Thu Sep 28 05:49:10 2023
From: pdeore at redhat.com (Pranali Deore)
Date: Thu, 28 Sep 2023 11:19:10 +0530
Subject: [Glance] Weekly Meeting Cancelled for Today
Message-ID: <CADkbuWhziq98AAS80GLgA3v7QnxBRdfscq2XbkvvuCDd3CU2rw@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230928/1bf0adf6/attachment-0001.htm>

From zigo at debian.org  Thu Sep 28 10:08:31 2023
From: zigo at debian.org (Thomas Goirand)
Date: Thu, 28 Sep 2023 12:08:31 +0200
Subject: [all][debian] First VM running under Bobcat pings: Debian Bobcat
 repository is ready!
Message-ID: <1fa1f7bb-de02-8778-ae82-e8254659a299@debian.org>

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)


From vrook at wikimedia.org  Thu Sep 28 10:24:43 2023
From: vrook at wikimedia.org (Vivian Rook)
Date: Thu, 28 Sep 2023 06:24:43 -0400
Subject: [kolla] change default domain
In-Reply-To: <5059bebf-4137-91df-d995-e77dd42eea20@pawsey.org.au>
References: <CAKxn-9RfFFYsriO-Wv_LG8VKJVxhK_E35TibP5BZnoH4vWoebw@mail.gmail.com>
 <5059bebf-4137-91df-d995-e77dd42eea20@pawsey.org.au>
Message-ID: <CAKxn-9RrXgZkDWpdJ5mVMVxCu_UWPiTQbMCcdMGqohzir9eHNQ@mail.gmail.com>

Thank you for your reply!

> Are you talking about the Horizon setting? We put this in globals.yml

No I mean the openstack domain, the kinds that I get when I run:
$ openstack --os-cloud=kolla-admin domain list
+----------------------------------+------------------+---------+-------------------------------------------+
| ID                               | Name             | Enabled |
Description                               |
+----------------------------------+------------------+---------+-------------------------------------------+
| 3a9492b526334a418a5ce328786c376c | magnum           | True    | Owns
users and projects created by magnum |
| default                          | Default          | True    | The
default domain                        |
| ff60f58e888742cd9974cd85d6c24e54 | heat_user_domain | True    |
                                |
+----------------------------------+------------------+---------+-------------------------------------------+

In this case I would like the "default" name to be called "surface"

Thank you!

On Wed, Sep 27, 2023 at 9:09?PM Gregory Orange <gregory.orange at pawsey.org.au>
wrote:

> On 20/9/23 19:21, Vivian Rook wrote:
> > I'm looking for a setting to change the default domain name from
> > "default" to "kolla" Does such an option exist in globals.yml?
>
> Are you talking about the Horizon setting? We put this in globals.yml
>
>
> horizon_keystone_domain_choices:
>    pawsey: Pawsey
>    Default: Default
> horizon_keystone_multidomain: True
>
>
> This results in a dropdown box for Domain at the login screen. Pawsey
> selected by default, although a browser cookie remembers which one users
> have most recently used.
>
> HTH,
> Greg.
>


-- 

*Vivian Rook (They/Them)*
Site Reliability Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230928/f18173ee/attachment.htm>

From tonykarera at gmail.com  Fri Sep 29 04:43:10 2023
From: tonykarera at gmail.com (Karera Tony)
Date: Fri, 29 Sep 2023 06:43:10 +0200
Subject: Masakari Issue
Message-ID: <CA+69TL3uKF+v_qdANbt5ZGyr9f5xaFGy93yCU-7nDZuyHSd4Og@mail.gmail.com>

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/066c5654-dd1a-4fa9-a664-dad10b89e202,
Host 066c5654-dd1a-4fa9-a664-dad10b89e202 can't be updated as it is in-use
to process notifications.

Regards

Tony Karera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230929/2e0af773/attachment.htm>

From tonykarera at gmail.com  Fri Sep 29 07:30:39 2023
From: tonykarera at gmail.com (Karera Tony)
Date: Fri, 29 Sep 2023 09:30:39 +0200
Subject: Masakari Issue
Message-ID: <CA+69TL2grWYeF1iUBYta0ZrM829_QDt+HqTagXqpsQ5qBVZt7g@mail.gmail.com>

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/hosts/066c5654-dd1a-4fa9-a664-dad10b89e202,
Host 066c5654-dd1a-4fa9-a664-dad10b89e202 can't be updated as it is in-use
to process notifications


Regards

Tony Karera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230929/6ecb5d66/attachment.htm>

From thierry at openstack.org  Fri Sep 29 09:44:14 2023
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 29 Sep 2023 11:44:14 +0200
Subject: [all][debian] First VM running under Bobcat pings: Debian Bobcat
 repository is ready!
In-Reply-To: <1fa1f7bb-de02-8778-ae82-e8254659a299@debian.org>
References: <1fa1f7bb-de02-8778-ae82-e8254659a299@debian.org>
Message-ID: <589722c2-6a3c-aa86-cb1b-038febf4498a@openstack.org>

Thomas Goirand wrote:
> 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.
> [...]

Thanks Thomas, it's always great for release managers to have outside 
confirmation that things we are about to release work in practical 
implementations beyond our continuous integration testing!

> Thanks to everyone that contributed to Bobcat, or that was involved in 
> this release,

Cheers!

-- 
Thierry


From ygk.kmr at gmail.com  Fri Sep 29 10:35:27 2023
From: ygk.kmr at gmail.com (Gk Gk)
Date: Fri, 29 Sep 2023 16:05:27 +0530
Subject: Wsgi in openstack
In-Reply-To: <73a9ae969326f53c49bcbb5c520fe1763900914d.camel@redhat.com>
References: <CAJreVFx2th76R1kvfe_AnGRYbjjXjCr+J0R2jfBw6TBkPPYuAA@mail.gmail.com>
 <73a9ae969326f53c49bcbb5c520fe1763900914d.camel@redhat.com>
Message-ID: <CAJreVFydbEmgKPxOGqg4R_tdtgCdYAyyW6Kd519wRkcH2v7Erw@mail.gmail.com>

Thanks for the response. But this is not the answer I was looking for. I am
asking how wsgi is implemented in the nova-api server. How to understand
these python classes ?

How does the flow of control go from one module to another ? Specifically
wsgi related. Is there any design doc which talks about this ? Are there
any resources on the internet along these lines?

On Wed, Sep 27, 2023 at 8:59?PM Stephen Finucane <stephenfin at redhat.com>
wrote:

> On Wed, 2023-09-27 at 19:41 +0530, Gk Gk wrote:
>
> 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
>
>
> Script for WSGI "entry points" are automatically generated by pbr, similar
> to how standard setuptools builds scripts for console scripts:
>
>
> https://github.com/openstack/pbr/blob/d03d617c09e7ba8ddf62d1e53d71685cd708e2da/pbr/packaging.py#L332-L384
>
> If you build an sdist or wheel and extract it, you'll see the generated
> scripts in there. You'll also see then in `bin` if you install e.g. nova
> and look at the `nova-api` script.
>
> Stephen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230929/41757873/attachment.htm>

From ralonsoh at redhat.com  Fri Sep 29 11:35:12 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 29 Sep 2023 13:35:12 +0200
Subject: [neutron] Neutron drivers meeting
Message-ID: <CAECr9X6K=t_Ydss0HmoA9h2yLTj_xfmy2Z87soCL9ks5VGcCVQ@mail.gmail.com>

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230929/0429e10f/attachment.htm>

From elod.illes at est.tech  Fri Sep 29 14:44:55 2023
From: elod.illes at est.tech (=?utf-8?B?RWzDtWQgSWxsw6lz?=)
Date: Fri, 29 Sep 2023 14:44:55 +0000
Subject: [release] Release countdown for week R+0, Oct 02-06
Message-ID: <VI1P18901MB0751BBADCDCB5FB43955446AFFC0A@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230929/f5240a30/attachment.htm>

From fungi at yuggoth.org  Fri Sep 29 23:55:23 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 29 Sep 2023 23:55:23 +0000
Subject: [all][infra][tact-sig] Mailman v3 migration for OpenStack mailing
 lists 2023-10-12
Message-ID: <20230929235523.gtxaxdw5jzxkh46n@yuggoth.org>

On Thursday, October 12 at 15:30 UTC, the OpenDev Collaboratory
systems administrators will be migrating the lists.openstack.org
mailing list site from the aging Mailman 2.1.29 server to a newer
Mailman 3.3.8 deployment. This maintenance window is expected to
last approximately four hours. The key takeaways are as follows:

  * There will be an extended outage for the site while DNS is
    updated and configuration, subscriber lists and message archives
    are imported, but incoming messages should correctly queue at
    the sender's end and arrive at the conclusion of our work

  * Because this is on a new server, there are new IP addresses from
    which list mail will be originating: 162.209.78.70 and
    2001:4800:7813:516:be76:4eff:fe04:5423

  * Moderation queues will not be copied to the new server, so
    moderators are encouraged to process any held messages prior to
    the migration time in order to avoid losing them

  * Anyone wishing to adjust their list subscriptions, or handle
    moderation or list configuration after the migration, needs to
    use the Sign Up button on the Web page to create a new account;
    it will be linked to your imported roles as soon as you confirm
    by following a URL from an E-mail message the server sends you,
    and is global for all sites on the server so you only need to do
    this once

  * The software providing Web front-ends for list management and
    archive browsing is entirely new in Mailman v3 and therefore has
    a much different appearance, though we've added appropriate
    redirects and frozen copies of old archives in order to
    accommodate existing hyperlinks

If you have any questions or concerns, feel free to follow up on the
service-discuss mailing list or find us in the #opendev channel on
the OFTC IRC network.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230929/4727b015/attachment.sig>

From sbauza at redhat.com  Sat Sep 30 12:26:59 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Sat, 30 Sep 2023 14:26:59 +0200
Subject: Wsgi in openstack
In-Reply-To: <CAJreVFydbEmgKPxOGqg4R_tdtgCdYAyyW6Kd519wRkcH2v7Erw@mail.gmail.com>
References: <CAJreVFx2th76R1kvfe_AnGRYbjjXjCr+J0R2jfBw6TBkPPYuAA@mail.gmail.com>
 <73a9ae969326f53c49bcbb5c520fe1763900914d.camel@redhat.com>
 <CAJreVFydbEmgKPxOGqg4R_tdtgCdYAyyW6Kd519wRkcH2v7Erw@mail.gmail.com>
Message-ID: <CALOCmukUBLzgfrByA8Xrxz9pENknXBoxy8jxB6RmqW+YrS5XwQ@mail.gmail.com>

Le ven. 29 sept. 2023, 12:41, Gk Gk <ygk.kmr at gmail.com> a ?crit :

> Thanks for the response. But this is not the answer I was looking for. I
> am asking how wsgi is implemented in the nova-api server. How to understand
> these python classes ?
>
> How does the flow of control go from one module to another ? Specifically
> wsgi related. Is there any design doc which talks about this ? Are there
> any resources on the internet along these lines?
>
>>
>>
Short answer : nova-api is a WSGI app. We use pastedeploy [1] for providing
WSGI pipelines [2]. Each of the pipelines verify WSGI middlewares one after
the other, and eventually it goes to the Nova APIRouterV21 WSGI middleware
[3]
The APIRouterV21 then calls the right HTTP controller related to the link,
as you can see in [4].

For example, the call of POST /servers in
https://docs.openstack.org/api-ref/compute/#create-server is then
eventually calling [5], depending on the microversion of course.

HTH,
-Sylvain

[1] https://pastedeploy.readthedocs.io
[2]
https://github.com/openstack/nova/blob/87d4807848bb9546c1fca972da2eb2eda13eb08d/etc/nova/api-paste.ini#L18-L43
[3]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/routes.py
[4]
https://github.com/openstack/nova/blob/87d4807848bb9546c1fca972da2eb2eda13eb08d/nova/api/openstack/compute/routes.py#L369C4-L842
[5]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L683


>> On Wed, Sep 27, 2023 at 8:59?PM Stephen Finucane <stephenfin at redhat.com>
> wrote:
>
>> On Wed, 2023-09-27 at 19:41 +0530, Gk Gk wrote:
>>
>> 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
>>
>>
>> Script for WSGI "entry points" are automatically generated by pbr,
>> similar to how standard setuptools builds scripts for console scripts:
>>
>>
>> https://github.com/openstack/pbr/blob/d03d617c09e7ba8ddf62d1e53d71685cd708e2da/pbr/packaging.py#L332-L384
>>
>> If you build an sdist or wheel and extract it, you'll see the generated
>> scripts in there. You'll also see then in `bin` if you install e.g. nova
>> and look at the `nova-api` script.
>>
>> Stephen
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230930/ea5574e1/attachment.htm>