From raubvogel at gmail.com  Tue Feb  1 03:42:02 2022
From: raubvogel at gmail.com (Mauricio Tavares)
Date: Mon, 31 Jan 2022 22:42:02 -0500
Subject: [Skyline] Project mascot to review
In-Reply-To: <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org>
References: <54D2CC84-6134-4B62-801D-3C6CB93CBC79@openstack.org>
 <A7C3C22B-43C1-4CEC-8574-5537DFD02B58@openstack.org>
 <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org>
Message-ID: <CAHEKYV4=B7UHh24mw9GCuqDVaMGXkC8NVE4NvEH=3Q4Bb_wZ+Q@mail.gmail.com>

I pick non-overlap because it is less busy. Also, it gives a feeling
that the different colour bits, while different in size and colour,
are all equally important in their contribution to what makes the
mascot the mascot.

On Mon, Jan 31, 2022 at 6:27 PM James Cole <james at openstack.org> wrote:
>
> Hi everyone,
>
> Thank you for the additional feedback over the weekend. I wanted to show you the white option both with overlapping spots (option 1) and without overlapping spots (option 2). Is there a clear winner between these two? PDF attached and viewable via Dropbox here.
>
> Thanks!
>
> -James
>
>
> On Jan 28, 2022, at 12:20 PM, James Cole <james at openstack.org> wrote:
>
> Hi again everyone,
>
> Thank you for all the feedback on this! The white background version has a definitive lead at the moment, but I will leave the discussion open over the weekend in case anyone else wants to chime in.
>
> @Sean Moony mentioned a preference for the triangle pattern on the yellow version since they aren?t overlapping. I?m curious if anyone else shares a preference for that triangle pattern button on the white background.
>
> Thank you again!
>
> -James
>
> On Jan 26, 2022, at 3:44 PM, James Cole <james at openstack.org> wrote:
>
> Greetings everyone,
>
> I?m James, a designer with the OpenInfra Foundation. We have a been working on a new project mascot for Skyline and wanted to share a couple of options with you.
>
> The reference we were provided alluded to a nine-color-deer, so we created a deer illustration in the style of the other project mascots. The two options are essentially the same, but one is white with spots and the other is yellow with spots. Let me know if you like one or the other?or if we?re totally off on the theme?and we will add the text to the logo and finalize the assets.
>
> There is a PDF attached to this message or you can view the document by visiting this link.
>
> Thank you!
>
> -James
>
> <20220120 Mascots Project.pdf>
>
>
>


From tobias.urdin at binero.com  Tue Feb  1 08:13:35 2022
From: tobias.urdin at binero.com (Tobias Urdin)
Date: Tue, 1 Feb 2022 08:13:35 +0000
Subject: [nova][placement] Openstack only building one VM per machine in
 cluster, then runs out of resources
In-Reply-To: <20220131122031.Horde.QTdLIRAWnRHZrs2_gSigDx3@webmail.nde.ag>
References: <20220131122031.Horde.QTdLIRAWnRHZrs2_gSigDx3@webmail.nde.ag>
Message-ID: <8B50194F-2E9D-40F8-A396-07E81A85E199@binero.com>

Hello,

We were hit by this issue October last year as well, was introduced when we upgraded MariaDB to 10.4.19 and was potentially
fixed in 10.4.20 (but we never verified), we downgraded back to 10.4.18 to workaround the regression.

Best regards

> On 31 Jan 2022, at 13:20, Eugen Block <eblock at nde.ag> wrote:
> 
> Hi all,
> 
> I would like to follow up on a discussion from last year [1] since the issue is still present.
> In a fresh Victoria deployment we faced the same issue and my colleague tracked it down to a reoccuring issue within MariaDB [2]. Quoting from his response to a different thread [3]:
> 
> ---snip---
> MariaDB is version 10.6.5.
> When running placement API in debug mode, its log reveals a message like
> 
> "Over capacity for VCPU on resource provider . Needed: 1, Used: 4118, Capacity: 768.0"
> 
> but checking the entries in the placement db / allocations table shows that "4118" is the sum of all resources for the resource provided, not only for the CPU class.
> 
> The problem results from errors in the DBMS handling the "outer join" with a subquery while retrieving the currently allocated resources.
> ---snip---
> 
> We found a workaround for this environment, but I wanted to bring some more attention to this, hoping that this will be fixed in MariaDB.
> 
> 
> Regards,
> Eugen
> 
> 
> [1] https://lists.openstack.org/pipermail/openstack-discuss/2021-July/023430.html
> [2] https://jira.mariadb.org/browse/MDEV-25714
> [3] https://serverfault.com/questions/1064579/openstack-only-building-one-vm-per-machine-in-cluster-then-runs-out-of-resource?noredirect=1#comment1386843_1064579
> 
> 



From strigazi at gmail.com  Tue Feb  1 08:13:46 2022
From: strigazi at gmail.com (Spyros Trigazis)
Date: Tue, 1 Feb 2022 09:13:46 +0100
Subject: [magnum] dropping mesos code
In-Reply-To: <CAFszKC6A=ZEioa2OTgB-AqZ5h9SDWuU=ibWi3PMk98BBPymJVg@mail.gmail.com>
References: <CAEs876iSe83oFc+37_hRHUvKomnioL2MMRTOVXy4x5xkdaMQKg@mail.gmail.com>
 <CAB9QTQaNqiq17X_W0J4bsmYBgMTurwCuZmYzhfXpZ7kHm8uUJA@mail.gmail.com>
 <E306493E-A5DE-4305-BD36-CB2378547F72@binero.com>
 <CAFszKC4jfoViB179d6gzw-QdeTG-Y15Z_50OT=HAH096+KxkmA@mail.gmail.com>
 <CAFszKC6A=ZEioa2OTgB-AqZ5h9SDWuU=ibWi3PMk98BBPymJVg@mail.gmail.com>
Message-ID: <CAB9QTQbhj+O4bHe2OXNXTKMth8TCso8yoJnc=Dr+U4-5-H2kPg@mail.gmail.com>

Hello Guilherme,

I'd say drop both, with a new patch, as you mention.

Cheers,
Spyros

On Mon, Jan 31, 2022 at 6:42 PM Guilherme Steinm?ller <
gsteinmuller at vexxhost.com> wrote:

> Hey everyone,
>
> @piotr suggested here dropping marathon as well
> https://review.opendev.org/c/openstack/magnum/+/821213 but since it's
> been used by dcos, does it make sense to remove it as well along with
> mesos?
>
> Maybe the correct question here would be: should we be dropping dcos as
> well? If so, maybe a new PR for would be more suitable.
>
> Regards,
> Guilherme Steinmuller
>
> On Wed, Dec 8, 2021 at 5:42 PM Guilherme Steinm?ller <
> gsteinmuller at vexxhost.com> wrote:
>
>> Hey there,
>>
>> I took the liberty to kick off a patch to start the mesos code removal
>> [1]. It's a lot of lines of code and files removed lol
>>
>> But I believe it's going to be an improvement on the current code as
>> mesos is not really being used out there.
>>
>> [1] https://review.opendev.org/c/openstack/magnum/+/821124
>>
>> Regards
>> Guilherme Steinmuller
>>
>> On Wed, Dec 8, 2021 at 11:54 AM Tobias Urdin <tobias.urdin at binero.com>
>> wrote:
>>
>>> Hello Mohammed,
>>>
>>> I agree, we should cleanup things that has been broken for years now.
>>>
>>> Best regards
>>> Tobias
>>>
>>> On 8 Dec 2021, at 15:35, Spyros Trigazis <strigazi at gmail.com> wrote:
>>>
>>> Hello Mohammed,
>>>
>>> I do not think anyone is interested in it anymore, we could just drop it.
>>> Even if resources are left behind they can be cleaned up with heat/other
>>> openstack APIs.
>>>
>>> Spyros
>>>
>>> On Sat, Dec 4, 2021 at 11:53 AM Mohammed Naser <mnaser at vexxhost.com>
>>> wrote:
>>>
>>>> Hi there,
>>>>
>>>> Does it make sense for us to drop the Mesos driver code from the code
>>>> base?
>>>>
>>>> I don't know of anyone that actually uses it and I believe it's likely
>>>> not been tested for years.
>>>>
>>>> Mohammed
>>>>
>>>> --
>>>> Mohammed Naser
>>>> VEXXHOST, Inc.
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/1307361d/attachment.htm>

From radoslaw.piliszek at gmail.com  Tue Feb  1 09:01:27 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Tue, 1 Feb 2022 10:01:27 +0100
Subject: [Skyline] Project mascot to review
In-Reply-To: <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org>
References: <54D2CC84-6134-4B62-801D-3C6CB93CBC79@openstack.org>
 <A7C3C22B-43C1-4CEC-8574-5537DFD02B58@openstack.org>
 <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org>
Message-ID: <CAKZ_x7_jGkDg3=BfGeGT5c7tM5SH9=AcJ8zkuaFcfbQzNHkhGw@mail.gmail.com>

Hi James,

Both are awesome but option 2 is more awesome (GMail suggested
"aesthetically pleasing" and I agree).
Non-overlapping variant feels more "in order", i.e., there is some
structure to what is offered and the pieces fit together (as opposed
to being randomly scattered).

-yoctozepto

On Tue, 1 Feb 2022 at 00:20, James Cole <james at openstack.org> wrote:
>
> Hi everyone,
>
> Thank you for the additional feedback over the weekend. I wanted to show you the white option both with overlapping spots (option 1) and without overlapping spots (option 2). Is there a clear winner between these two? PDF attached and viewable via Dropbox here.
>
> Thanks!
>
> -James
>
>
> On Jan 28, 2022, at 12:20 PM, James Cole <james at openstack.org> wrote:
>
> Hi again everyone,
>
> Thank you for all the feedback on this! The white background version has a definitive lead at the moment, but I will leave the discussion open over the weekend in case anyone else wants to chime in.
>
> @Sean Moony mentioned a preference for the triangle pattern on the yellow version since they aren?t overlapping. I?m curious if anyone else shares a preference for that triangle pattern button on the white background.
>
> Thank you again!
>
> -James
>
> On Jan 26, 2022, at 3:44 PM, James Cole <james at openstack.org> wrote:
>
> Greetings everyone,
>
> I?m James, a designer with the OpenInfra Foundation. We have a been working on a new project mascot for Skyline and wanted to share a couple of options with you.
>
> The reference we were provided alluded to a nine-color-deer, so we created a deer illustration in the style of the other project mascots. The two options are essentially the same, but one is white with spots and the other is yellow with spots. Let me know if you like one or the other?or if we?re totally off on the theme?and we will add the text to the logo and finalize the assets.
>
> There is a PDF attached to this message or you can view the document by visiting this link.
>
> Thank you!
>
> -James
>
> <20220120 Mascots Project.pdf>
>
>
>


From radoslaw.piliszek at gmail.com  Tue Feb  1 10:50:28 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Tue, 1 Feb 2022 11:50:28 +0100
Subject: [os-brick][nova][cinder][glance] Question about lock_path
Message-ID: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>

Hello Fellow OpenStackers!

I have noticed os-brick started using the file locks (in lock_path) to
avoid race conditions.
I have a question regarding that lock_path - it seems all the cases I
have found use separate lock_paths per service, yet the problematic
cases listed in the bug report (and the commit message of [1]) suggest
that, in case of co-hosted nova-compute, glance-api, cinder-volume and
cinder-backup services (or any combination thereof), the lock_path
should be shared.
Should the deployment projects adapt to actually fix the race condition issue?

[1] https://review.opendev.org/c/openstack/os-brick/+/814139

Kind regards,
-yoctozepto


From dbengt at redhat.com  Tue Feb  1 11:22:06 2022
From: dbengt at redhat.com (Daniel Mats Niklas Bengtsson)
Date: Tue, 1 Feb 2022 12:22:06 +0100
Subject: [infra] Issue with the new pip
In-Reply-To: <20220130190744.hru7khru534cqhbi@yuggoth.org>
References: <CAKZ_x7-kUesbjVZVqODfOMe1xvYKG5ZcW5pS4XCuvP9dYGTHDg@mail.gmail.com>
 <20220130190744.hru7khru534cqhbi@yuggoth.org>
Message-ID: <CAF+jc3XG6_pmq1DArcsM+5reyipbwfgKfNbz=5raBnYJaNG3CQ@mail.gmail.com>

On Sun, Jan 30, 2022 at 8:09 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
> Yes, that's due to the pip 22.0 release earlier today. The main
> issue we're dealing with is https://github.com/pypa/pip/issues/10825
> and have some changes up (one of which has already merged) under
> topic:pip-22 to hopefully address it. Unfortunately change 826969
> isn't going to take effect until the wheel cache indices are
> regenerated by the openstack/requirements periodic pipeline jobs.
I also have an error due to the new pip version on two jobs, the first
one[1] in ussuri and the second one[2] in train. I saw a patch[3] was
merged yesterday to support python 3.6 and use the right get-pip, I
will try a recheck.

[1] https://zuul.opendev.org/t/openstack/build/a37704d48ef34401bdad0418ad19fda4
[2] https://zuul.opendev.org/t/openstack/build/4e3ee8a01b4e4d4a81db52beb34610b9
[3] https://review.opendev.org/c/opendev/system-config/+/826968/1/playbooks/roles/pip3/tasks/bionic.yaml



From rlandy at redhat.com  Tue Feb  1 12:00:54 2022
From: rlandy at redhat.com (Ronelle Landy)
Date: Tue, 1 Feb 2022 07:00:54 -0500
Subject: [TripleO] Gate blocker - opstools repo
In-Reply-To: <CANnyimMvd-OvYzH_Pfyzu9_CRjQkViTTZqV1tZhmYAHcbnXy4Q@mail.gmail.com>
References: <CANnyimMvd-OvYzH_Pfyzu9_CRjQkViTTZqV1tZhmYAHcbnXy4Q@mail.gmail.com>
Message-ID: <CANnyimNja+E3P7qpLPk1F4r3w_WVJZ_dR3Ds8_n7WnFmpw983A@mail.gmail.com>

On Mon, Jan 31, 2022 at 3:50 PM Ronelle Landy <rlandy at redhat.com> wrote:

> Hello All,
>
> We have an issue with tripleo-ci-centos-8-content-provider
> <https://zuul.opendev.org/t/openstack/build/b05d7482835f4b4d83180c29b12973b0> among
> other tests failing in check/gate due to missing 'centos-opstools' repo.
>
> Details are in: https://bugs.launchpad.net/tripleo/+bug/1959619.
>
> There are a few patch in flight to try address this issue:
>
> https://review.rdoproject.org/r/c/rdo-infra/ansible-role-dlrn/+/38673 -
> Use opstools packages from trunk.rdoproject.org in cs8
>
> https://review.opendev.org/c/openstack/tripleo-quickstart/+/827111/ -
> Adds temporary rdoproject repo for collectd/opstools Centos-8
>
> Please hold rechecks until we manage to merge the fixes.
>

An update ...

We have cleared the above mentioned patches but now we have an issue
accessing ceph-nautilus - impacting train, ussuri and victoria jobs.

We are working on a similar temp repo fix and will reply when the gates are
clear again.




>
> Thank you!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/7ae6f71d/attachment.htm>

From james.slagle at gmail.com  Tue Feb  1 12:26:45 2022
From: james.slagle at gmail.com (James Slagle)
Date: Tue, 1 Feb 2022 07:26:45 -0500
Subject: [TripleO] Meeting Cancelled for February 1
Message-ID: <CAHV77z8CgR1NPP0=svB1a9YmvjnL01Nx2P67FnN1B5QTf9Lvjw@mail.gmail.com>

Hello TripleO'ers, with no items on the agenda for today's meeting, let's
go ahead and cancel it.

Please reach out on IRC if you need prioritized reviews. Thanks.

-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/f2d5719d/attachment.htm>

From fungi at yuggoth.org  Tue Feb  1 14:13:54 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 1 Feb 2022 14:13:54 +0000
Subject: [infra] Issue with the new pip
In-Reply-To: <CAF+jc3XG6_pmq1DArcsM+5reyipbwfgKfNbz=5raBnYJaNG3CQ@mail.gmail.com>
References: <CAKZ_x7-kUesbjVZVqODfOMe1xvYKG5ZcW5pS4XCuvP9dYGTHDg@mail.gmail.com>
 <20220130190744.hru7khru534cqhbi@yuggoth.org>
 <CAF+jc3XG6_pmq1DArcsM+5reyipbwfgKfNbz=5raBnYJaNG3CQ@mail.gmail.com>
Message-ID: <20220201141354.er742obifv4pzvp3@yuggoth.org>

On 2022-02-01 12:22:06 +0100 (+0100), Daniel Mats Niklas Bengtsson wrote:
> I also have an error due to the new pip version on two jobs, the first
> one[1] in ussuri and the second one[2] in train. I saw a patch[3] was
> merged yesterday to support python 3.6 and use the right get-pip, I
> will try a recheck.
> 
> [1] https://zuul.opendev.org/t/openstack/build/a37704d48ef34401bdad0418ad19fda4
> [2] https://zuul.opendev.org/t/openstack/build/4e3ee8a01b4e4d4a81db52beb34610b9
> [3] https://review.opendev.org/c/opendev/system-config/+/826968/1/playbooks/roles/pip3/tasks/bionic.yaml

The patch in system-config was for fixing some of the OpenDev
Collaboratory's service deployment testing, so wouldn't be much help
for the failures you linked. There is work underway to add a similar
fix to DevStack:

    https://review.opendev.org/c/openstack/devstack/+/827155

That will probably have to be backported to earlier branches once
it's working, but if you want to assist the QA team with
reviewing/improving the fix I'm sure they would appreciate the help.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/82da3e30/attachment.sig>

From smooney at redhat.com  Tue Feb  1 14:25:20 2022
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 01 Feb 2022 14:25:20 +0000
Subject: [Skyline] Project mascot to review
In-Reply-To: <CAKZ_x7_jGkDg3=BfGeGT5c7tM5SH9=AcJ8zkuaFcfbQzNHkhGw@mail.gmail.com>
References: <54D2CC84-6134-4B62-801D-3C6CB93CBC79@openstack.org>
 <A7C3C22B-43C1-4CEC-8574-5537DFD02B58@openstack.org>
 <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org>
 <CAKZ_x7_jGkDg3=BfGeGT5c7tM5SH9=AcJ8zkuaFcfbQzNHkhGw@mail.gmail.com>
Message-ID: <0076993f9a0ec7bcc336905121bfc682d7ffbfe2.camel@redhat.com>

On Tue, 2022-02-01 at 10:01 +0100, Rados?aw Piliszek wrote:
> Hi James,
> 
> Both are awesome but option 2 is more awesome (GMail suggested
> "aesthetically pleasing" and I agree).
> Non-overlapping variant feels more "in order", i.e., there is some
> structure to what is offered and the pieces fit together (as opposed
> to being randomly scattered).
ack that was partly how i felt intially too when i orginally provided that
feedback. the overlaping ones were just a little busy and my eyey were draw
to the noise it added.

with the non overlapping version i find my self looking at the mascot as a
whole rather then lookign at the colours primarlay 

both are pleaseing to see but i think its clear my prefernce lies with option 2 :)
james thanks for providign that for consideration.
> 
> -yoctozepto
> 
> On Tue, 1 Feb 2022 at 00:20, James Cole <james at openstack.org> wrote:
> > 
> > Hi everyone,
> > 
> > Thank you for the additional feedback over the weekend. I wanted to show you the white option both with overlapping spots (option 1) and without overlapping spots (option 2). Is there a clear winner between these two? PDF attached and viewable via Dropbox here.
> > 
> > Thanks!
> > 
> > -James
> > 
> > 
> > On Jan 28, 2022, at 12:20 PM, James Cole <james at openstack.org> wrote:
> > 
> > Hi again everyone,
> > 
> > Thank you for all the feedback on this! The white background version has a definitive lead at the moment, but I will leave the discussion open over the weekend in case anyone else wants to chime in.
> > 
> > @Sean Moony mentioned a preference for the triangle pattern on the yellow version since they aren?t overlapping. I?m curious if anyone else shares a preference for that triangle pattern button on the white background.
> > 
> > Thank you again!
> > 
> > -James
> > 
> > On Jan 26, 2022, at 3:44 PM, James Cole <james at openstack.org> wrote:
> > 
> > Greetings everyone,
> > 
> > I?m James, a designer with the OpenInfra Foundation. We have a been working on a new project mascot for Skyline and wanted to share a couple of options with you.
> > 
> > The reference we were provided alluded to a nine-color-deer, so we created a deer illustration in the style of the other project mascots. The two options are essentially the same, but one is white with spots and the other is yellow with spots. Let me know if you like one or the other?or if we?re totally off on the theme?and we will add the text to the logo and finalize the assets.
> > 
> > There is a PDF attached to this message or you can view the document by visiting this link.
> > 
> > Thank you!
> > 
> > -James
> > 
> > <20220120 Mascots Project.pdf>
> > 
> > 
> > 
> 



From fmogollon at vicomtech.org  Tue Feb  1 14:49:02 2022
From: fmogollon at vicomtech.org (Felipe Mogollon)
Date: Tue, 1 Feb 2022 15:49:02 +0100
Subject: Openstack VLAN provider Network
Message-ID: <CAK8S=-sRFaNVeEoPy4iPSE3VHT8RDWbypOnnmxveQT3347ixOg@mail.gmail.com>

I have deployed an OpenStack Victoria using packstack in a Centos 8 Stream
machine.

I have 3 NIC interfaces that are configured in the following way

eno1 -> VLAN 684 10.15.0.0/16
eno2 -> local network 192.168.235.0/24
eno3 -> local network 192.168.15.0/24

VLAN and local networks are working fine outside Openstack.

I have deployed Openstack using packstack and local networks work fine and
I can deploy instances inside openstack that get floating ips from those
ranges without problem and I can ping to them.

The problem is with VLAN network, I can deploy instances and I get floating
ips from VLAN network range but I can't ping them.

My packstack answer file is https://pastebin.com/GEqspMWu

I have created VLAN network using following commands:

neutron net-create vlan_network --provider:network_type vlan
--provider:physical_network vlan  --router:external=True --shared
--provider:segmentation_id=684

neutron subnet-create --name vlan_subnet --enable_dhcp=False
--allocation-pool=start=10.15.11.103,end=10.15.11.113
--gateway=10.15.11.1 vlan_network 10.15.11.0/24

Any ideas?


-- 
<https://www.vicomtech.org>

Juan Felipe Mogoll?n Rodr?guez
Researcher | Investigador

fmogollon at vicomtech.org
+[34] 943 30 92 30
Digital Media

<https://www.linkedin.com/company/vicomtech>
<https://www.youtube.com/user/VICOMTech>  <https://twitter.com/@Vicomtech>

member of:  <https://graphicsvision.ai/>

La informaci?n que contiene este mensaje y sus adjuntos son confidenciales
y est?n dirigidos exclusivamente a sus destinatarios. Si recibe este
mensaje por error, se ruega nos lo comunique y proceda a su borrado.

The information contained in this electronic message is intended only for
the personal and confidential use of the recipients designated in the
original message. If you have received this communication in error, please
notify us immediately by replying to the message and deleting it from your
computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/9891dc47/attachment-0001.htm>

From alifshit at redhat.com  Tue Feb  1 15:32:14 2022
From: alifshit at redhat.com (Artom Lifshitz)
Date: Tue, 1 Feb 2022 10:32:14 -0500
Subject: [nova][tempest] nova-next gate blocker
Message-ID: <CACqyMif5ezXRrBSKrUjkwg8hGxK9nA61U=73VgB0B6EgwduH3g@mail.gmail.com>

nova-next (and possibly others) is broken because of
https://bugs.launchpad.net/tempest/+bug/1959682

The fix is at https://review.opendev.org/c/openstack/tempest/+/827305,
with a Nova DNM patch to exercise it at
https://review.opendev.org/c/openstack/nova/+/827306

Please hold your rechecks until this is resolved.

Cheers!



From balazs.gibizer at est.tech  Tue Feb  1 15:57:34 2022
From: balazs.gibizer at est.tech (Balazs Gibizer)
Date: Tue, 01 Feb 2022 16:57:34 +0100
Subject: [os-brick][nova][cinder][glance] Question about lock_path
In-Reply-To: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
References: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
Message-ID: <YZUM6R.GG3LDYZYOQH83@est.tech>



On Tue, Feb 1 2022 at 11:50:28 AM +0100, Rados?aw Piliszek 
<radoslaw.piliszek at gmail.com> wrote:
> Hello Fellow OpenStackers!
> 
> I have noticed os-brick started using the file locks (in lock_path) to
> avoid race conditions.
> I have a question regarding that lock_path - it seems all the cases I
> have found use separate lock_paths per service, yet the problematic
> cases listed in the bug report (and the commit message of [1]) suggest
> that, in case of co-hosted nova-compute, glance-api, cinder-volume and
> cinder-backup services (or any combination thereof), the lock_path
> should be shared.
> Should the deployment projects adapt to actually fix the race 
> condition issue?

An alternative to that would be that os-brick has specific lock path 
config option regardless of which service is importing the lib. Then 
the oslo_concurrency.lockutils.lock() can be called with that os-brick 
specific path from os-brick.

Cheers,
gibi

> 
> [1] https://review.opendev.org/c/openstack/os-brick/+/814139
> 
> Kind regards,
> -yoctozepto
> 




From katonalala at gmail.com  Tue Feb  1 16:38:28 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Tue, 1 Feb 2022 17:38:28 +0100
Subject: [nova][tempest] nova-next gate blocker
In-Reply-To: <CACqyMif5ezXRrBSKrUjkwg8hGxK9nA61U=73VgB0B6EgwduH3g@mail.gmail.com>
References: <CACqyMif5ezXRrBSKrUjkwg8hGxK9nA61U=73VgB0B6EgwduH3g@mail.gmail.com>
Message-ID: <CALg0jKn53=u5o7kODcZn2ah_EV0p000OyD4ceHZ_4y5Yr4HkQQ@mail.gmail.com>

Hi,
Thanks for bringing this up, just for reference the current fix for this
issue is here:
https://review.opendev.org/c/openstack/tempest/+/827258

To make things harder we have to wait the solution for pip vs py36 issue:
https://bugs.launchpad.net/neutron/+bug/1959600
For this bug the solution/workaround is this patch:
https://review.opendev.org/c/openstack/devstack/+/827155

Perhaps there are other things, sorry for missing them :-)
Regards
Lajos Katona (lajoskatona)



Artom Lifshitz <alifshit at redhat.com> ezt ?rta (id?pont: 2022. febr. 1., K,
16:39):

> nova-next (and possibly others) is broken because of
> https://bugs.launchpad.net/tempest/+bug/1959682
>
> The fix is at https://review.opendev.org/c/openstack/tempest/+/827305,
> with a Nova DNM patch to exercise it at
> https://review.opendev.org/c/openstack/nova/+/827306
>
> Please hold your rechecks until this is resolved.
>
> Cheers!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/80070fa2/attachment.htm>

From openstack at nemebean.com  Tue Feb  1 17:07:07 2022
From: openstack at nemebean.com (Ben Nemec)
Date: Tue, 1 Feb 2022 11:07:07 -0600
Subject: [os-brick][nova][cinder][glance] Question about lock_path
In-Reply-To: <YZUM6R.GG3LDYZYOQH83@est.tech>
References: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
 <YZUM6R.GG3LDYZYOQH83@est.tech>
Message-ID: <b84166be-b6ad-d596-69fb-010677629556@nemebean.com>

General question: Are file locks even sufficient for this? If we're 
talking about multiple services coordinating access to a resource, do we 
know for certain that all of the processes accessing the resource are on 
the same system? If not, file locks can't solve this anyway.

If so, see my thoughts below.

On 2/1/22 09:57, Balazs Gibizer wrote:
> 
> 
> On Tue, Feb 1 2022 at 11:50:28 AM +0100, Rados?aw Piliszek 
> <radoslaw.piliszek at gmail.com> wrote:
>> Hello Fellow OpenStackers!
>>
>> I have noticed os-brick started using the file locks (in lock_path) to
>> avoid race conditions.
>> I have a question regarding that lock_path - it seems all the cases I
>> have found use separate lock_paths per service, yet the problematic
>> cases listed in the bug report (and the commit message of [1]) suggest
>> that, in case of co-hosted nova-compute, glance-api, cinder-volume and
>> cinder-backup services (or any combination thereof), the lock_path
>> should be shared.
>> Should the deployment projects adapt to actually fix the race 
>> condition issue?
> 
> An alternative to that would be that os-brick has specific lock path 
> config option regardless of which service is importing the lib. Then the 
> oslo_concurrency.lockutils.lock() can be called with that os-brick 
> specific path from os-brick.

The lock_path config opt is owned by oslo.concurrency so I don't think 
this is possible today. The simplest and least error-prone solution is 
to configure all of the users of os-brick to use the same lock path.

Even if we provided a way to override the lock path for just os-brick, 
you'd still need to add a config opt to each service that points at a 
common location and the deployment tools would need to configure that 
and create the shared directory. You don't save the deployment tools any 
effort this way.

Keeping a single lock path for everything running in a given service 
also eliminates the possibility that a lock gets used both in and out of 
os-brick, which would break if os-brick had a separate path. I don't 
know if that happens, but a single lock path means you never have to 
answer that question.

One drawback I can see to a single lock path for multiple services is 
possible collisions of lock names. Previously each service could name 
locks whatever they wanted as long as there were no duplicates within 
the service. If they start sharing lock path, there can be no duplicates 
between any of the services sharing the lock path. I can't say how much 
of a problem this would be, but we could probably come up with some way 
to look at the lock names used in a service and make sure there's no 
overlap.

Also, I _think_ even if there were a duplicate lock name in two 
services, the worst that would happen is some unnecessary lock 
contention.* You might introduce a performance problem, but not a race. 
Personally, that's a tradeoff I'd happily make.

*: If you had multiple duplicate locks being acquired in different 
orders between the two services, it's possible you could introduce a 
deadlock. A lot has to go wrong for that to happen, but in the interest 
of completeness it should be considered. Have I mentioned that 
concurrency is hard? ;-)


From balazs.gibizer at est.tech  Tue Feb  1 17:30:20 2022
From: balazs.gibizer at est.tech (Balazs Gibizer)
Date: Tue, 01 Feb 2022 18:30:20 +0100
Subject: [os-brick][nova][cinder][glance] Question about lock_path
In-Reply-To: <b84166be-b6ad-d596-69fb-010677629556@nemebean.com>
References: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
 <YZUM6R.GG3LDYZYOQH83@est.tech>
 <b84166be-b6ad-d596-69fb-010677629556@nemebean.com>
Message-ID: <KAZM6R.PMGVW2CFO3SR1@est.tech>



On Tue, Feb 1 2022 at 11:07:07 AM -0600, Ben Nemec 
<openstack at nemebean.com> wrote:
> General question: Are file locks even sufficient for this? If we're 
> talking about multiple services coordinating access to a resource, do 
> we know for certain that all of the processes accessing the resource 
> are on the same system? If not, file locks can't solve this anyway.
> 
> If so, see my thoughts below.
> 
> On 2/1/22 09:57, Balazs Gibizer wrote:
>> 
>> 
>> On Tue, Feb 1 2022 at 11:50:28 AM +0100, Rados?aw Piliszek 
>> <radoslaw.piliszek at gmail.com> wrote:
>>> Hello Fellow OpenStackers!
>>> 
>>> I have noticed os-brick started using the file locks (in lock_path) 
>>> to
>>> avoid race conditions.
>>> I have a question regarding that lock_path - it seems all the cases 
>>> I
>>> have found use separate lock_paths per service, yet the problematic
>>> cases listed in the bug report (and the commit message of [1]) 
>>> suggest
>>> that, in case of co-hosted nova-compute, glance-api, cinder-volume 
>>> and
>>> cinder-backup services (or any combination thereof), the lock_path
>>> should be shared.
>>> Should the deployment projects adapt to actually fix the race 
>>> condition issue?
>> 
>> An alternative to that would be that os-brick has specific lock path 
>> config option regardless of which service is importing the lib. 
>> Then the oslo_concurrency.lockutils.lock() can be called with that 
>> os-brick specific path from os-brick.
> 
> The lock_path config opt is owned by oslo.concurrency so I don't 
> think this is possible today. The simplest and least error-prone 
> solution is to configure all of the users of os-brick to use the same 
> lock path.

The oslo_concurrency.lockutils.lock() call takes a lock_path kwargs 
that can be used to override the configured lock_path as far as I 
see[1][2][3].

> 
> Even if we provided a way to override the lock path for just 
> os-brick, you'd still need to add a config opt to each service that 
> points at a common location and the deployment tools would need to 
> configure that and create the shared directory. You don't save the 
> deployment tools any effort this way.

os_brick can expose a new config option with a sane default and 
document that if that default is changed then the config of every 
service using os_brick needs to be changed to have the same value.

> 
> Keeping a single lock path for everything running in a given service 
> also eliminates the possibility that a lock gets used both in and out 
> of os-brick, which would break if os-brick had a separate path. I 
> don't know if that happens, but a single lock path means you never 
> have to answer that question.

Good point. That is a clear advantage of this proposal.

> 
> One drawback I can see to a single lock path for multiple services is 
> possible collisions of lock names. Previously each service could name 
> locks whatever they wanted as long as there were no duplicates within 
> the service. If they start sharing lock path, there can be no 
> duplicates between any of the services sharing the lock path. I can't 
> say how much of a problem this would be, but we could probably come 
> up with some way to look at the lock names used in a service and make 
> sure there's no overlap.
> 
> Also, I _think_ even if there were a duplicate lock name in two 
> services, the worst that would happen is some unnecessary lock 
> contention.* You might introduce a performance problem, but not a 
> race. Personally, that's a tradeoff I'd happily make.
> 
> *: If you had multiple duplicate locks being acquired in different 
> orders between the two services, it's possible you could introduce a 
> deadlock. A lot has to go wrong for that to happen, but in the 
> interest of completeness it should be considered. Have I mentioned 
> that concurrency is hard? ;-)


[1] 
https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L236
[2] 
https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L188
[3] 
https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L180




From dtantsur at redhat.com  Tue Feb  1 18:40:54 2022
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Tue, 1 Feb 2022 19:40:54 +0100
Subject: [requirements] The version of zeroconf in upper constraints no
 longer supports python3.6
In-Reply-To: <CANjRKVo=17QN82wyBmuxcP4OTu2Ys0TtAB0fVF8htdwrOi0FRg@mail.gmail.com>
References: <CANjRKVo=17QN82wyBmuxcP4OTu2Ys0TtAB0fVF8htdwrOi0FRg@mail.gmail.com>
Message-ID: <CACNgkFz5sfmPOuv5Auz-vcgFsJYLJA=jvvuD-=uArfasoyYriA@mail.gmail.com>

I've proposed a requirements patch for this since it breaks Ironic ramdisk
builds: https://review.opendev.org/c/openstack/requirements/+/827338

On Fri, Jan 28, 2022 at 10:31 AM William Szumski <will at stackhpc.com> wrote:

> The zeroconf package seems to have dropped support for python3.6 since
> 0.38.0, see: https://github.com/jstasiak/python-zeroconf#0380. We
> currently have 0.38.1 in upper-constraints. My understanding was that the
> yoga release would still support python3.6. This is important for RHEL8
> based distributions that only ship python3.6. Do we need to constrain
> zeroconf to a version <=0.37.0?
>
>
>

-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/911f87bf/attachment.htm>

From cboylan at sapwetik.org  Tue Feb  1 21:23:21 2022
From: cboylan at sapwetik.org (Clark Boylan)
Date: Tue, 01 Feb 2022 13:23:21 -0800
Subject: [infra] gerrit is:mergeable predicate
In-Reply-To: <43f436b5-699c-4800-8121-af358cf7c1db@www.fastmail.com>
References: <c5b126c1-6f50-bcbb-09ee-a85406d7d7ad@gmail.com>
 <43f436b5-699c-4800-8121-af358cf7c1db@www.fastmail.com>
Message-ID: <888611ec-be6c-4c5c-89a0-ddbfc7b7066a@www.fastmail.com>

On Fri, Jan 28, 2022, at 4:08 PM, Clark Boylan wrote:
> On Fri, Jan 28, 2022, at 3:51 PM, Brian Rosmaita wrote:
>> Hello Infra team,
>>
>> In Gerrit 3.4, the is:mergeable predicate is disabled by default [0]. It 
>> was kind of handy to be able to screen out patches that are in merge 
>> conflict when looking for reviews.  Is there an alternative way of doing 
>> this, or would you be averse to restoring the previous behavior?  (I 
>> promise not to complain about gerrit performance.)
>
> This was brought up on IRC as well. My biggest concern with re-enabling 
> it is that the cost is actually largely incurred when we reindex if I 
> understand how Gerrit works. This means it is fine most of the time 
> except for when we want to rename projects or upgrade and we need to do 
> reindexing.
>
> Two smaller concerns are that Gerrit often makes changes like this then 
> stops allowing you to modify the default, and the further you get away 
> from default Gerrit the more bugs and upgrade fun you run into. I'm 
> pretty sure the signed tag issue we ran into is because literally 
> everyone else allows you to push regular tags and signed tags and 
> doesn't force signed tags.
>
> All that said we'll be discussing it during our next meeting and will 
> hopefully have a plan from there: 
> https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting. Feel free to 
> join us at 19:00 UTC in #opendev-meeting Tuesday February 1, 2022.

To follow up on this we made the decision to go ahead and toggle the configuration option to add this back in then work to mitigate some of the concerns. In particular we'll communicate our desire to keep this feature in Gerrit to Gerrit upstream. Hopefully, you'll see this information again in Gerrit in the near future.

>
> Side note: Zuul also checks mergeability, but only when you trigger 
> events that cause Zuul to take action.
>
>>
>> cheers,
>> brian
>>
>>
>> [0] 
>> https://www.gerritcodereview.com/3.4.html#ismergeable-predicate-is-disabled-per-default


From jungleboyj at gmail.com  Tue Feb  1 22:05:07 2022
From: jungleboyj at gmail.com (Jay Bryant)
Date: Tue, 1 Feb 2022 16:05:07 -0600
Subject: [Skyline] Project mascot to review
In-Reply-To: <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org>
References: <54D2CC84-6134-4B62-801D-3C6CB93CBC79@openstack.org>
 <A7C3C22B-43C1-4CEC-8574-5537DFD02B58@openstack.org>
 <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org>
Message-ID: <bd13db19-d939-3af2-336c-907778c166b0@gmail.com>

Along with others I think the non-overlapping one looks best.? A really 
nice mascot design!

Thanks!

Jay


On 1/31/2022 3:51 PM, James Cole wrote:
> Hi everyone,
>
> Thank you for the additional feedback over the weekend. I wanted to 
> show you the white option both with overlapping spots (option 1) and 
> without overlapping spots (option 2). Is there a clear winner between 
> these two? PDF attached and viewable via Dropbox here 
> <https://www.dropbox.com/s/n6og0jb7lx1feri/20220131_Mascots%20Project-r2.pdf?dl=0>. 
>
>
> Thanks!
>
> -James
>
>
>
>> On Jan 28, 2022, at 12:20 PM, James Cole <james at openstack.org> wrote:
>>
>> Hi again everyone,
>>
>> Thank you for all the feedback on this! The white background version 
>> has a definitive lead at the moment, but I will leave the discussion 
>> open over the weekend in case anyone else wants to chime in.
>>
>> @Sean Moony mentioned a preference for the triangle pattern on the 
>> yellow version since they aren?t overlapping. I?m curious if anyone 
>> else shares a preference for that triangle pattern button on the 
>> white background.
>>
>> Thank you again!
>>
>> -James
>>
>>> On Jan 26, 2022, at 3:44 PM, James Cole <james at openstack.org> wrote:
>>>
>>> Greetings everyone,
>>>
>>> I?m James, a designer with the OpenInfra Foundation. We have a been 
>>> working on a new project mascot for Skyline and wanted to share a 
>>> couple of options with you.
>>>
>>> The reference we were provided alluded to a?nine-color-deer, so we 
>>> created a deer illustration in the style of the other project 
>>> mascots. The two options are essentially the same, but one is white 
>>> with spots and the other is yellow with spots. Let me know if you 
>>> like one or the other?or if we?re totally off on the theme?and we 
>>> will add?the text to the logo and finalize the assets.
>>>
>>> There is a PDF attached to this message or you can view the document 
>>> by visiting this link 
>>> <https://www.dropbox.com/s/d2ikaphzhml7tqb/20220120%20Mascots%20Project.pdf?dl=0>. 
>>>
>>>
>>> Thank you!
>>>
>>> -James
>>>
>>> <20220120 Mascots Project.pdf>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/2b4e0aa7/attachment.htm>

From gmann at ghanshyammann.com  Tue Feb  1 22:14:37 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 01 Feb 2022 16:14:37 -0600
Subject: [all][tc] Relmgt team position on release cadence
In-Reply-To: <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
References: <40f6f51b-6903-1afe-7318-0689b2af482d@openstack.org>
 <8301ef05-4011-43e9-beec-66f6aeeb00f9@www.fastmail.com>
 <20211129130957.3poysdeqsufkp3pg@yuggoth.org>
 <f2c4ab93-a1e1-475c-8b35-1b303b8fb96b@www.fastmail.com>
 <d28fc7ccfecd753561e1d395c672e987f95eb748.camel@redhat.com>
 <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com>
 <CAF7gwdiUF2wj7RqN-LzwvwH1FQ1A7j=F-CikHKS0ct8AKNAdJg@mail.gmail.com>
 <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org>
 <CAF7gwdhnS_101_Ljf++V=-jGwKZ_NUm6gn+Jzo_N-VDwDuvayw@mail.gmail.com>
 <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com>
 <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
Message-ID: <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>

 ---- On Fri, 28 Jan 2022 19:47:16 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  ---- On Wed, 01 Dec 2021 16:43:32 -0600 Jean-Philippe Evrard <openstack at a.spamming.party> wrote ----
 >  > Hello,
 >  > 
 >  > On Tue, Nov 30, 2021, at 23:31, Julia Kreger wrote:
 >  > >> > It feels like this is a giant "no win situation",
 >  > > It feels like we have created a bunch of basically immovable,
 >  > > insurmountable conflicting obstacles. Kind of like a self digging
 >  > > holes. I'm worried not even hacker-Kirk can save us. Well, maybe his
 >  > > answer might actually be to abolish the integrated release so he can
 >  > > not only rescue the operators on the ship, but also beam them the
 >  > > tools they need to move forward. Granted, that is change, and human
 >  > > nature is a thing. :(
 >  > 
 >  > Well, I feel completely differently.
 >  > For me, people are using different words, and are in agreement in some points.
 >  > Or maybe I am reading this wrong?
 >  > 
 >  > Here is what I read:
 >  > 1) Many want more releases, not less. I haven't seen a complaint about tagging more releases.
 >  > 2) More than one person is proposing to abandon the integrated release, and nobody has complained about it.
 >  > 3) Many people seem eager to carry "stable branches" for "critical patches", but no new definition of such criticality was done.
 >  > 4) Many people want to make sure it's easy to upgrade, and with less steps for operations.
 >  > 
 >  > I don't see any conflicts, just areas for improvement, for those who have been participating on this topic.
 >  > 
 >  > Can someone clarify if I have tunnel vision/bias (as it seems exactly what I proposed in my first answer)?
 >  > 
 > 
 > TC is planning to discuss this topic on 3rd Feb 16:00 UTC, let us know if the time works fine. Accordingly,
 > I will send the joining link.

I might not be available this week, we will schedule this meeting next week or so.

-gmann

 > 
 > -gmann
 > 
 >  > Thank you in advance.
 >  > 
 >  > Regards,
 >  > Jean-Philippe Evrard (evrardjp)
 >  > 
 >  > 
 > 
 > 	


From iwienand at redhat.com  Tue Feb  1 22:43:00 2022
From: iwienand at redhat.com (Ian Wienand)
Date: Wed, 2 Feb 2022 09:43:00 +1100
Subject: [all][infra][qa][tripleo][openstack-ansible][rally][aodh][cinder][kolla][chef][sahara]
 CentOS 8 EOL and removal from CI label/image lists
In-Reply-To: <5ae024ea-9cdf-4fe0-9794-27fcda507e4b@www.fastmail.com>
References: <5ae024ea-9cdf-4fe0-9794-27fcda507e4b@www.fastmail.com>
Message-ID: <Yfm3dEdtvIBPRYXt@fedora19.localdomain>

On Tue, Jan 11, 2022 at 01:50:27PM -0800, Clark Boylan wrote:
> As noted last month the OpenDev [0] team intends on removing CentOS
> 8 images from our CI system now that the release has gone EOL.

> [0] https://lists.opendev.org/pipermail/service-announce/2021-December/000029.html

Upstream have removed the CentOS-8 mirror redirectors and packages
from the mirror, which we have now synced to our mirror nodes.
i.e. CentOS-8 jobs are now completely EOL and will not be working.  As
noted in the original mail, projects still relying on this will go
into a configuration error when we remove the node types.

Thanks,

-i



From amy at demarco.com  Wed Feb  2 00:59:19 2022
From: amy at demarco.com (Amy Marrich)
Date: Tue, 1 Feb 2022 18:59:19 -0600
Subject: [Diversity] Diversity and Inclusion Meeting Reminder - New Day, Time
 and Location
Message-ID: <CAFs83QpHZQqmVuU6C-xCSR+6A8hysHpE_XiDhVr2A16ieMrZfw@mail.gmail.com>

The Diversity & Inclusion WG invites members of all OIF projects to attend
our next meeting Friday February 4th, at 15:00 UTC on
https://meetpad.opendev.org/osf-diversity-and-inclusion. The agenda can be
found at https://etherpad.openstack.org/p/diversity-wg-agenda.

 Please feel free to add any topics you wish to discuss at the meeting.

Thanks,

Amy (apotz)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/463c619d/attachment.htm>

From rlandy at redhat.com  Wed Feb  2 01:13:39 2022
From: rlandy at redhat.com (Ronelle Landy)
Date: Tue, 1 Feb 2022 20:13:39 -0500
Subject: [TripleO] Gate blocker - opstools repo
In-Reply-To: <CANnyimNja+E3P7qpLPk1F4r3w_WVJZ_dR3Ds8_n7WnFmpw983A@mail.gmail.com>
References: <CANnyimMvd-OvYzH_Pfyzu9_CRjQkViTTZqV1tZhmYAHcbnXy4Q@mail.gmail.com>
 <CANnyimNja+E3P7qpLPk1F4r3w_WVJZ_dR3Ds8_n7WnFmpw983A@mail.gmail.com>
Message-ID: <CANnyimNyVgghp0LqTcM4-eUkegOjyoMoaRHHE0M_=6ewTgApGA@mail.gmail.com>

On Tue, Feb 1, 2022 at 7:00 AM Ronelle Landy <rlandy at redhat.com> wrote:

>
>
> On Mon, Jan 31, 2022 at 3:50 PM Ronelle Landy <rlandy at redhat.com> wrote:
>
>> Hello All,
>>
>> We have an issue with tripleo-ci-centos-8-content-provider
>> <https://zuul.opendev.org/t/openstack/build/b05d7482835f4b4d83180c29b12973b0> among
>> other tests failing in check/gate due to missing 'centos-opstools' repo.
>>
>> Details are in: https://bugs.launchpad.net/tripleo/+bug/1959619.
>>
>> There are a few patch in flight to try address this issue:
>>
>> https://review.rdoproject.org/r/c/rdo-infra/ansible-role-dlrn/+/38673 -
>> Use opstools packages from trunk.rdoproject.org in cs8
>>
>> https://review.opendev.org/c/openstack/tripleo-quickstart/+/827111/ -
>> Adds temporary rdoproject repo for collectd/opstools Centos-8
>>
>> Please hold rechecks until we manage to merge the fixes.
>>
>
> An update ...
>
> We have cleared the above mentioned patches but now we have an issue
> accessing ceph-nautilus - impacting train, ussuri and victoria jobs.
>
> We are working on a similar temp repo fix and will reply when the gates
> are clear again.
>
>
>

Thanks to Alfredo, we are now using temporary repos and jobs can proceed -
the gate should be unblocked.


>
>
>>
>> Thank you!
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220201/e3e29523/attachment.htm>

From mrunge at matthias-runge.de  Wed Feb  2 06:59:50 2022
From: mrunge at matthias-runge.de (Matthias Runge)
Date: Wed, 2 Feb 2022 07:59:50 +0100
Subject: [TripleO] Gate blocker - opstools repo
In-Reply-To: <CANnyimMvd-OvYzH_Pfyzu9_CRjQkViTTZqV1tZhmYAHcbnXy4Q@mail.gmail.com>
References: <CANnyimMvd-OvYzH_Pfyzu9_CRjQkViTTZqV1tZhmYAHcbnXy4Q@mail.gmail.com>
Message-ID: <Yfor5jpqLzTn/11h@abel.berg.ol>

On Mon, Jan 31, 2022 at 03:50:30PM -0500, Ronelle Landy wrote:
> Hello All,
> 
> We have an issue with tripleo-ci-centos-8-content-provider
> <https://zuul.opendev.org/t/openstack/build/b05d7482835f4b4d83180c29b12973b0>
> among
> other tests failing in check/gate due to missing 'centos-opstools' repo.
> 
> Details are in: https://bugs.launchpad.net/tripleo/+bug/1959619.
> 
> There are a few patch in flight to try address this issue:
> 
> https://review.rdoproject.org/r/c/rdo-infra/ansible-role-dlrn/+/38673 - Use
> opstools packages from trunk.rdoproject.org in cs8
> 
> https://review.opendev.org/c/openstack/tripleo-quickstart/+/827111/ - Adds
> temporary rdoproject repo for collectd/opstools Centos-8
> 
> Please hold rechecks until we manage to merge the fixes.
> 
> Thank you!

The centos-release-opstools package has been updated to provide the
centos 8 stream repositories.

Matthias

-- 
Matthias Runge <mrunge at matthias-runge.de>


From skaplons at redhat.com  Wed Feb  2 07:27:21 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Wed, 02 Feb 2022 08:27:21 +0100
Subject: Openstack VLAN provider Network
In-Reply-To: <CAK8S=-sRFaNVeEoPy4iPSE3VHT8RDWbypOnnmxveQT3347ixOg@mail.gmail.com>
References: <CAK8S=-sRFaNVeEoPy4iPSE3VHT8RDWbypOnnmxveQT3347ixOg@mail.gmail.com>
Message-ID: <2919487.mvXUDI8C0e@p1>

Hi,

On wtorek, 1 lutego 2022 15:49:02 CET Felipe Mogollon wrote:
> I have deployed an OpenStack Victoria using packstack in a Centos 8 Stream
> machine.
> 
> I have 3 NIC interfaces that are configured in the following way
> 
> eno1 -> VLAN 684 10.15.0.0/16
> eno2 -> local network 192.168.235.0/24
> eno3 -> local network 192.168.15.0/24
> 
> VLAN and local networks are working fine outside Openstack.
> 
> I have deployed Openstack using packstack and local networks work fine and
> I can deploy instances inside openstack that get floating ips from those
> ranges without problem and I can ping to them.
> 
> The problem is with VLAN network, I can deploy instances and I get floating
> ips from VLAN network range but I can't ping them.
> 
> My packstack answer file is https://pastebin.com/GEqspMWu
> 
> I have created VLAN network using following commands:
> 
> neutron net-create vlan_network --provider:network_type vlan
> --provider:physical_network vlan  --router:external=True --shared
> --provider:segmentation_id=684
> 
> neutron subnet-create --name vlan_subnet --enable_dhcp=False
> --allocation-pool=start=10.15.11.103,end=10.15.11.113
> --gateway=10.15.11.1 vlan_network 10.15.11.0/24
> 
> Any ideas?

It's very long time since I was using packstack and I don't remember it at all 
but first thing I would check here is if eno1 NIC is actually in the physical 
bridge mapped to the "vlan" physical_network (typically it's br-ex but maybe 
You named it differently).

-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/67d94dad/attachment.sig>

From fmogollon at vicomtech.org  Wed Feb  2 07:43:50 2022
From: fmogollon at vicomtech.org (Felipe Mogollon)
Date: Wed, 2 Feb 2022 08:43:50 +0100
Subject: Openstack VLAN provider Network
In-Reply-To: <2919487.mvXUDI8C0e@p1>
References: <CAK8S=-sRFaNVeEoPy4iPSE3VHT8RDWbypOnnmxveQT3347ixOg@mail.gmail.com>
 <2919487.mvXUDI8C0e@p1>
Message-ID: <CAK8S=-udD=_j=p8+j_mBTOBfF8wFd8VRa5dtoP1UHGTSWjZFTg@mail.gmail.com>

Hi,

there is a br-ex1 that is mapped to eno1, it is configured in answers.txt
and seems to deploy well.

Felipe

On Wed, Feb 2, 2022 at 8:27 AM Slawek Kaplonski <skaplons at redhat.com> wrote:

> Hi,
>
> On wtorek, 1 lutego 2022 15:49:02 CET Felipe Mogollon wrote:
> > I have deployed an OpenStack Victoria using packstack in a Centos 8
> Stream
> > machine.
> >
> > I have 3 NIC interfaces that are configured in the following way
> >
> > eno1 -> VLAN 684 10.15.0.0/16
> > eno2 -> local network 192.168.235.0/24
> > eno3 -> local network 192.168.15.0/24
> >
> > VLAN and local networks are working fine outside Openstack.
> >
> > I have deployed Openstack using packstack and local networks work fine
> and
> > I can deploy instances inside openstack that get floating ips from those
> > ranges without problem and I can ping to them.
> >
> > The problem is with VLAN network, I can deploy instances and I get
> floating
> > ips from VLAN network range but I can't ping them.
> >
> > My packstack answer file is https://pastebin.com/GEqspMWu
> >
> > I have created VLAN network using following commands:
> >
> > neutron net-create vlan_network --provider:network_type vlan
> > --provider:physical_network vlan  --router:external=True --shared
> > --provider:segmentation_id=684
> >
> > neutron subnet-create --name vlan_subnet --enable_dhcp=False
> > --allocation-pool=start=10.15.11.103,end=10.15.11.113
> > --gateway=10.15.11.1 vlan_network 10.15.11.0/24
> >
> > Any ideas?
>
> It's very long time since I was using packstack and I don't remember it at
> all
> but first thing I would check here is if eno1 NIC is actually in the
> physical
> bridge mapped to the "vlan" physical_network (typically it's br-ex but
> maybe
> You named it differently).
>
> --
> Slawek Kaplonski
> Principal Software Engineer
> Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/0576ca08/attachment-0001.htm>

From satish.txt at gmail.com  Wed Feb  2 13:53:54 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 2 Feb 2022 08:53:54 -0500
Subject: Openstack VLAN provider Network
In-Reply-To: <CAK8S=-udD=_j=p8+j_mBTOBfF8wFd8VRa5dtoP1UHGTSWjZFTg@mail.gmail.com>
References: <CAK8S=-udD=_j=p8+j_mBTOBfF8wFd8VRa5dtoP1UHGTSWjZFTg@mail.gmail.com>
Message-ID: <243F84E8-F0D7-4FFC-9BC5-1DC05BCF704D@gmail.com>

Assuming you have configure 684 VLAN on your physical infrastructure. I meant your switches. 

Sent from my iPhone

> On Feb 2, 2022, at 2:45 AM, Felipe Mogollon <fmogollon at vicomtech.org> wrote:
> 
> ?
> Hi,
> 
> there is a br-ex1 that is mapped to eno1, it is configured in answers.txt and seems to deploy well.
> 
> Felipe
> 
>> On Wed, Feb 2, 2022 at 8:27 AM Slawek Kaplonski <skaplons at redhat.com> wrote:
>> Hi,
>> 
>> On wtorek, 1 lutego 2022 15:49:02 CET Felipe Mogollon wrote:
>> > I have deployed an OpenStack Victoria using packstack in a Centos 8 Stream
>> > machine.
>> > 
>> > I have 3 NIC interfaces that are configured in the following way
>> > 
>> > eno1 -> VLAN 684 10.15.0.0/16
>> > eno2 -> local network 192.168.235.0/24
>> > eno3 -> local network 192.168.15.0/24
>> > 
>> > VLAN and local networks are working fine outside Openstack.
>> > 
>> > I have deployed Openstack using packstack and local networks work fine and
>> > I can deploy instances inside openstack that get floating ips from those
>> > ranges without problem and I can ping to them.
>> > 
>> > The problem is with VLAN network, I can deploy instances and I get floating
>> > ips from VLAN network range but I can't ping them.
>> > 
>> > My packstack answer file is https://pastebin.com/GEqspMWu
>> > 
>> > I have created VLAN network using following commands:
>> > 
>> > neutron net-create vlan_network --provider:network_type vlan
>> > --provider:physical_network vlan  --router:external=True --shared
>> > --provider:segmentation_id=684
>> > 
>> > neutron subnet-create --name vlan_subnet --enable_dhcp=False
>> > --allocation-pool=start=10.15.11.103,end=10.15.11.113
>> > --gateway=10.15.11.1 vlan_network 10.15.11.0/24
>> > 
>> > Any ideas?
>> 
>> It's very long time since I was using packstack and I don't remember it at all 
>> but first thing I would check here is if eno1 NIC is actually in the physical 
>> bridge mapped to the "vlan" physical_network (typically it's br-ex but maybe 
>> You named it differently).
>> 
>> -- 
>> Slawek Kaplonski
>> Principal Software Engineer
>> Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/b06d1ba4/attachment.htm>

From mbollo at redhat.com  Tue Feb  1 16:17:48 2022
From: mbollo at redhat.com (Daniel Mats Niklas Bengtsson)
Date: Tue, 1 Feb 2022 17:17:48 +0100
Subject: [infra] Issue with the new pip
In-Reply-To: <20220201141354.er742obifv4pzvp3@yuggoth.org>
References: <CAKZ_x7-kUesbjVZVqODfOMe1xvYKG5ZcW5pS4XCuvP9dYGTHDg@mail.gmail.com>
 <20220130190744.hru7khru534cqhbi@yuggoth.org>
 <CAF+jc3XG6_pmq1DArcsM+5reyipbwfgKfNbz=5raBnYJaNG3CQ@mail.gmail.com>
 <20220201141354.er742obifv4pzvp3@yuggoth.org>
Message-ID: <CAF+jc3UOkt02HTbT=PQEoZExmTfMAo0ZUNGvTKN61DDXK6ZgfA@mail.gmail.com>

On Tue, Feb 1, 2022 at 3:16 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
> That will probably have to be backported to earlier branches once
> it's working, but if you want to assist the QA team with
> reviewing/improving the fix I'm sure they would appreciate the help.
Yes I will check it. Thanks a lot.



From adivya1.singh at gmail.com  Wed Feb  2 15:32:00 2022
From: adivya1.singh at gmail.com (Adivya Singh)
Date: Wed, 2 Feb 2022 21:02:00 +0530
Subject: Recently Upgraded to XENA and getting this error
Message-ID: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>

Hello,

We have recently upgraded to XENA release of Openstack, and getting this
error while trying to Resize instance using GUI, it is telling "Danger ,
Please try Later"
Same is working properly from CLI without any issue

Any thoughts on this

Regards
Adivya Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/bd94801b/attachment.htm>

From DHilsbos at performair.com  Wed Feb  2 15:49:09 2022
From: DHilsbos at performair.com (DHilsbos at performair.com)
Date: Wed, 2 Feb 2022 15:49:09 +0000
Subject: Openstack VLAN provider Network
In-Reply-To: <CAK8S=-tPosEgg8myc8Xn2Xoa1pjNOEpX35MQawJJ0UeGY=PB7w@mail.gmail.com>
References: <CAK8S=-sRFaNVeEoPy4iPSE3VHT8RDWbypOnnmxveQT3347ixOg@mail.gmail.com>
 <0670B960225633449A24709C291A525251E75023@COM03.performair.local>
 <CAK8S=-tPosEgg8myc8Xn2Xoa1pjNOEpX35MQawJJ0UeGY=PB7w@mail.gmail.com>
Message-ID: <0670B960225633449A24709C291A525251E757F3@COM03.performair.local>

Felipe;

A lot of this will depend on how you have Neutron configured.  We use OpenVSwitch.  For OpenVSwitch you want a completely unconfigured interface, for VLANs.

If you haven't looked at Server World's tutorial for OpenStack, I would suggest you do so.  They can be found here:
https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_xena2&f=6
https://www.server-world.info/en/note?os=CentOS_Stream_8&p=openstack_xena2&f=6

Pay particular attention to the names br-eth1 and physnet1, and where and how they are used.  You are likely going to need to reference the "Configure Neutron #2" page from the tutorial to understand the whole configuration, as these assume #1 and #2 have been completed (#1 walks through how to setup the support services).

The tutorials are for VXLAN, but are modifiable to be VLAN.

In particular;
[ml2_type_vxlan]
vni_ranges = 1:1000

becomes:
[ml2_type_vlan]
network_vlan_ranges = physnet1:1:1000

For you, I believe that last line would be:
network_vlan_ranges = physnet1:684:684

What I can't help you with is how this interacts with PackStack.

Thank you,

Dominic L. Hilsbos, MBA
Vice President ? Information Technology
Perform Air International Inc.
DHilsbos at PerformAir.com
www.PerformAir.com



From: Felipe Mogollon [mailto:fmogollon at vicomtech.org] 
Sent: Wednesday, February 2, 2022 12:44 AM
To: Dominic Hilsbos
Subject: Re: Openstack VLAN provider Network

Do you mean to remove only ip address from VLAN's eth configuration or removing all VLAN's eth configuration?

Thanks

Felipe

On Wed, Feb 2, 2022 at 12:21 AM <DHilsbos at performair.com> wrote:
Felipe;

I had significant problems with this as well, when I was first setting up our cluster.

The first thing to recognize is that the network type is from the stand point of the host (more specifically from the network services host, and the neutron compute hosts), not the network itself.? Your VLAN network is actually a physical network (from the standpoint of the host), because it is bound to a physical interface.

If you want to actually use it as a vlan type; a) remove the IP address(es) from the interface(s) of the network and compute host(s), and b) properly configure ml2, or an equivalent plugin.

Thank you,

Dominic L. Hilsbos, MBA
Vice President ? Information Technology
Perform Air International Inc.
DHilsbos at PerformAir.com
www.PerformAir.com


From: Felipe Mogollon [mailto:fmogollon at vicomtech.org] 
Sent: Tuesday, February 1, 2022 7:49 AM
To: openstack-discuss
Subject: Openstack VLAN provider Network

I have deployed an OpenStack Victoria using packstack in a Centos 8 Stream machine.
I have 3 NIC interfaces that are configured in the following way
eno1 -> VLAN 684 10.15.0.0/16 
eno2 -> local network 192.168.235.0/24
eno3 -> local network 192.168.15.0/24
VLAN and local networks are working fine outside Openstack.
I have deployed Openstack using packstack and local networks work fine and I can deploy instances inside openstack that get floating ips from those ranges without problem and I can ping to them.
The problem is with VLAN network, I can deploy instances and I get floating ips from VLAN network range but I can't ping them.
My packstack answer file is https://pastebin.com/GEqspMWu
I have created VLAN network using following commands:
neutron net-create vlan_network --provider:network_type vlan --provider:physical_network vlan? --router:external=True --shared --provider:segmentation_id=684

neutron subnet-create --name vlan_subnet --enable_dhcp=False --allocation-pool=start=10.15.11.103,end=10.15.11.113 --gateway=10.15.11.1 vlan_network 10.15.11.0/24
Any ideas?


-- 


Juan Felipe Mogoll?n Rodr?guez
Researcher | Investigador

fmogollon at vicomtech.org
+[34]?943?30?92?30
Digital Media

??

member of:?

La informaci?n que contiene este mensaje y sus adjuntos son confidenciales y est?n dirigidos exclusivamente a sus destinatarios. Si recibe este mensaje por error, se ruega nos lo comunique y proceda a su borrado.

The information contained in this electronic message is intended only for the personal and confidential use of the recipients designated in the original message. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. 

From fmogollon at vicomtech.org  Wed Feb  2 16:24:43 2022
From: fmogollon at vicomtech.org (Felipe Mogollon)
Date: Wed, 2 Feb 2022 17:24:43 +0100
Subject: Openstack VLAN provider Network
In-Reply-To: <243F84E8-F0D7-4FFC-9BC5-1DC05BCF704D@gmail.com>
References: <CAK8S=-udD=_j=p8+j_mBTOBfF8wFd8VRa5dtoP1UHGTSWjZFTg@mail.gmail.com>
 <243F84E8-F0D7-4FFC-9BC5-1DC05BCF704D@gmail.com>
Message-ID: <CAK8S=-tL=3p+LKtt6z4eYD_vfxcSwXnCk3aKXXCZ4oyOSo__iA@mail.gmail.com>

Hi,
yes, VLAN 684 is configured on my switches and I can ping another server
that is in VLAN 684 from the openstack server...

On Wed, Feb 2, 2022 at 2:53 PM Satish Patel <satish.txt at gmail.com> wrote:

> Assuming you have configure 684 VLAN on your physical infrastructure. I
> meant your switches.
>
> Sent from my iPhone
>
> On Feb 2, 2022, at 2:45 AM, Felipe Mogollon <fmogollon at vicomtech.org>
> wrote:
>
> ?
> Hi,
>
> there is a br-ex1 that is mapped to eno1, it is configured in answers.txt
> and seems to deploy well.
>
> Felipe
>
> On Wed, Feb 2, 2022 at 8:27 AM Slawek Kaplonski <skaplons at redhat.com>
> wrote:
>
>> Hi,
>>
>> On wtorek, 1 lutego 2022 15:49:02 CET Felipe Mogollon wrote:
>> > I have deployed an OpenStack Victoria using packstack in a Centos 8
>> Stream
>> > machine.
>> >
>> > I have 3 NIC interfaces that are configured in the following way
>> >
>> > eno1 -> VLAN 684 10.15.0.0/16
>> > eno2 -> local network 192.168.235.0/24
>> > eno3 -> local network 192.168.15.0/24
>> >
>> > VLAN and local networks are working fine outside Openstack.
>> >
>> > I have deployed Openstack using packstack and local networks work fine
>> and
>> > I can deploy instances inside openstack that get floating ips from those
>> > ranges without problem and I can ping to them.
>> >
>> > The problem is with VLAN network, I can deploy instances and I get
>> floating
>> > ips from VLAN network range but I can't ping them.
>> >
>> > My packstack answer file is https://pastebin.com/GEqspMWu
>> >
>> > I have created VLAN network using following commands:
>> >
>> > neutron net-create vlan_network --provider:network_type vlan
>> > --provider:physical_network vlan  --router:external=True --shared
>> > --provider:segmentation_id=684
>> >
>> > neutron subnet-create --name vlan_subnet --enable_dhcp=False
>> > --allocation-pool=start=10.15.11.103,end=10.15.11.113
>> > --gateway=10.15.11.1 vlan_network 10.15.11.0/24
>> >
>> > Any ideas?
>>
>> It's very long time since I was using packstack and I don't remember it
>> at all
>> but first thing I would check here is if eno1 NIC is actually in the
>> physical
>> bridge mapped to the "vlan" physical_network (typically it's br-ex but
>> maybe
>> You named it differently).
>>
>> --
>> Slawek Kaplonski
>> Principal Software Engineer
>> Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/0a590f95/attachment-0001.htm>

From fmogollon at vicomtech.org  Wed Feb  2 16:51:52 2022
From: fmogollon at vicomtech.org (Felipe Mogollon)
Date: Wed, 2 Feb 2022 17:51:52 +0100
Subject: Openstack VLAN provider Network
In-Reply-To: <0670B960225633449A24709C291A525251E757F3@COM03.performair.local>
References: <CAK8S=-sRFaNVeEoPy4iPSE3VHT8RDWbypOnnmxveQT3347ixOg@mail.gmail.com>
 <0670B960225633449A24709C291A525251E75023@COM03.performair.local>
 <CAK8S=-tPosEgg8myc8Xn2Xoa1pjNOEpX35MQawJJ0UeGY=PB7w@mail.gmail.com>
 <0670B960225633449A24709C291A525251E757F3@COM03.performair.local>
Message-ID: <CAK8S=-s-1hJ9FxAPY91ErDrqbeBMXPjTNLAWd2jAPpuq+oHROA@mail.gmail.com>

Hi,
I am using openvswitch too.

I have those parameters configured as your example, packstack does it for
me, but I dont't get what do you mean with "a completely unconfigured
interface for VLANS", do you mean that my
"/etc/sysconfig/network-scripts/ifcfg-eno1" (for Centos and eno1 is the NIC
which is connected to VLAN enabled switch) should be empty?

I haven't configured eno1 at all and after deploying OpenStack with
packstack I have the following content on

/etc/sysconfig/network-scripts/ifcfg-eno1

> DEVICE=eno1
> NAME=eno1
> DEVICETYPE=ovs
> TYPE=OVSPort
> OVS_BRIDGE=br-ex1
> ONBOOT=yes
> BOOTPROTO=none
>

and /etc/sysconfig/network-scripts/ifcfg-br-ex1

ONBOOT=yes
> PEERDNS=no
> NM_CONTROLLED=no
> NOZEROCONF=yes
> DEVICE=br-ex1
> NAME=br-ex1
> DEVICETYPE=ovs
> OVSBOOTPROTO=none
> TYPE=OVSBridge
> OVS_EXTRA="set bridge br-ex1 fail_mode=standalone"
>


my routing table is:

> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 0.0.0.0         192.168.15.254  0.0.0.0         UG    0      0        0
> br-ex
> 169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0
> eno3
> 169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0
> eno1
> 169.254.0.0     0.0.0.0         255.255.0.0     U     1005   0        0
> eno2
> 169.254.0.0     0.0.0.0         255.255.0.0     U     1043   0        0
> br-ex
> 192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0
> br-ex
>

Felipe

On Wed, Feb 2, 2022 at 4:49 PM <DHilsbos at performair.com> wrote:

> Felipe;
>
> A lot of this will depend on how you have Neutron configured.  We use
> OpenVSwitch.  For OpenVSwitch you want a completely unconfigured interface,
> for VLANs.
>
> If you haven't looked at Server World's tutorial for OpenStack, I would
> suggest you do so.  They can be found here:
> https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_xena2&f=6
>
> https://www.server-world.info/en/note?os=CentOS_Stream_8&p=openstack_xena2&f=6
>
> Pay particular attention to the names br-eth1 and physnet1, and where and
> how they are used.  You are likely going to need to reference the
> "Configure Neutron #2" page from the tutorial to understand the whole
> configuration, as these assume #1 and #2 have been completed (#1 walks
> through how to setup the support services).
>
> The tutorials are for VXLAN, but are modifiable to be VLAN.
>
> In particular;
> [ml2_type_vxlan]
> vni_ranges = 1:1000
>
> becomes:
> [ml2_type_vlan]
> network_vlan_ranges = physnet1:1:1000
>
> For you, I believe that last line would be:
> network_vlan_ranges = physnet1:684:684
>
> What I can't help you with is how this interacts with PackStack.
>
> Thank you,
>
> Dominic L. Hilsbos, MBA
> Vice President ? Information Technology
> Perform Air International Inc.
> DHilsbos at PerformAir.com
> www.PerformAir.com
>
>
>
> From: Felipe Mogollon [mailto:fmogollon at vicomtech.org]
> Sent: Wednesday, February 2, 2022 12:44 AM
> To: Dominic Hilsbos
> Subject: Re: Openstack VLAN provider Network
>
> Do you mean to remove only ip address from VLAN's eth configuration or
> removing all VLAN's eth configuration?
>
> Thanks
>
> Felipe
>
> On Wed, Feb 2, 2022 at 12:21 AM <DHilsbos at performair.com> wrote:
> Felipe;
>
> I had significant problems with this as well, when I was first setting up
> our cluster.
>
> The first thing to recognize is that the network type is from the stand
> point of the host (more specifically from the network services host, and
> the neutron compute hosts), not the network itself.  Your VLAN network is
> actually a physical network (from the standpoint of the host), because it
> is bound to a physical interface.
>
> If you want to actually use it as a vlan type; a) remove the IP
> address(es) from the interface(s) of the network and compute host(s), and
> b) properly configure ml2, or an equivalent plugin.
>
> Thank you,
>
> Dominic L. Hilsbos, MBA
> Vice President ? Information Technology
> Perform Air International Inc.
> DHilsbos at PerformAir.com
> www.PerformAir.com
>
>
> From: Felipe Mogollon [mailto:fmogollon at vicomtech.org]
> Sent: Tuesday, February 1, 2022 7:49 AM
> To: openstack-discuss
> Subject: Openstack VLAN provider Network
>
> I have deployed an OpenStack Victoria using packstack in a Centos 8 Stream
> machine.
> I have 3 NIC interfaces that are configured in the following way
> eno1 -> VLAN 684 10.15.0.0/16
> eno2 -> local network 192.168.235.0/24
> eno3 -> local network 192.168.15.0/24
> VLAN and local networks are working fine outside Openstack.
> I have deployed Openstack using packstack and local networks work fine and
> I can deploy instances inside openstack that get floating ips from those
> ranges without problem and I can ping to them.
> The problem is with VLAN network, I can deploy instances and I get
> floating ips from VLAN network range but I can't ping them.
> My packstack answer file is https://pastebin.com/GEqspMWu
> I have created VLAN network using following commands:
> neutron net-create vlan_network --provider:network_type vlan
> --provider:physical_network vlan  --router:external=True --shared
> --provider:segmentation_id=684
>
> neutron subnet-create --name vlan_subnet --enable_dhcp=False
> --allocation-pool=start=10.15.11.103,end=10.15.11.113 --gateway=10.15.11.1
> vlan_network 10.15.11.0/24
> Any ideas?
>
>
> --
>
>
> Juan Felipe Mogoll?n Rodr?guez
> Researcher | Investigador
>
> fmogollon at vicomtech.org
> +[34] 943 30 92 30
> Digital Media
>
>
>
> member of:
>
> La informaci?n que contiene este mensaje y sus adjuntos son confidenciales
> y est?n dirigidos exclusivamente a sus destinatarios. Si recibe este
> mensaje por error, se ruega nos lo comunique y proceda a su borrado.
>
> The information contained in this electronic message is intended only for
> the personal and confidential use of the recipients designated in the
> original message. If you have received this communication in error, please
> notify us immediately by replying to the message and deleting it from your
> computer.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/6def2676/attachment.htm>

From mtint.stfc at gmail.com  Wed Feb  2 17:07:51 2022
From: mtint.stfc at gmail.com (Michael STFC)
Date: Wed, 2 Feb 2022 17:07:51 +0000
Subject: Home openstack lab
In-Reply-To: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
Message-ID: <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>

Hi All:

I am kind of new to Openstack and want to setup openstack learning env or lab at home.

I have 3 HP MicroServers g8 with 16GB RAM and 5 HP MicroServers g7 with 8 GB RAM - all have dual or quad NIC and I have a 24 ports Aruba switch with VXLAN feature, older HP Procurve 24 switch. 

I am looking into have 3 nodes for run services and 2 for compute and remaining 3 for Ceph. 

Any advise on OS and which openstack distro I should and link to the documentations or guides?

Regards,

Michael



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/aa76d132/attachment.htm>

From rosmaita.fossdev at gmail.com  Wed Feb  2 17:24:26 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Wed, 2 Feb 2022 12:24:26 -0500
Subject: [cinder][drivers] stable branch backports
Message-ID: <621382ec-a0fd-58fb-875a-48bafe86a0f9@gmail.com>

Hello Argonauts, especially vendor driver maintainers:

At last week's midcycle meeting, we began a discussion of running 
third-party CI on stable branch changes.  While that continues *not* to 
be required (it will be re-visited at the Z PTG), we did agree to the 
following:

     When a vendor driver patch backport is proposed, we would like to 
see a clear statement on the gerrit review that the patch has been 
tested in an appropriate environment.

This shouldn't be a big deal because presumably you've done local 
testing with your backend to ensure that the code works as expected in a 
stable branch; we're simply asking that this be documented on the backport.

cheers,
brian



From jean-francois.taltavull at elca.ch  Wed Feb  2 17:33:24 2022
From: jean-francois.taltavull at elca.ch (=?iso-8859-1?Q?Taltavull_Jean-Fran=E7ois?=)
Date: Wed, 2 Feb 2022 17:33:24 +0000
Subject: Home openstack lab
In-Reply-To: <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
Message-ID: <62d22956f42a4b2195eedbdb6db650a3@elca.ch>

Hi Michael,

Ubuntu 20.04, OpenStack Xena, OpenStack-Ansible 24.0.1 (https://docs.openstack.org/openstack-ansible/xena/) and Ceph Pacific is a good combo.

Enjoy !

Jean-Francois


From: Michael STFC <mtint.stfc at gmail.com>
Sent: mercredi, 2 f?vrier 2022 18:08
To: openstack-discuss <openstack-discuss at lists.openstack.org>
Cc: Michael STFC <mtint.stfc at gmail.com>
Subject: Home openstack lab



EXTERNAL MESSAGE - This email comes from outside ELCA companies.

Hi All:

I am kind of new to Openstack and want to setup openstack learning env or lab at home.

I have 3 HP MicroServers g8 with 16GB RAM and 5 HP MicroServers g7 with 8 GB RAM - all have dual or quad NIC and I have a 24 ports Aruba switch with VXLAN feature, older HP Procurve 24 switch.


I am looking into have 3 nodes for run services and 2 for compute and remaining 3 for Ceph.

Any advise on OS and which openstack distro I should and link to the documentations or guides?

Regards,

Michael



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/66bc4d96/attachment-0001.htm>

From smooney at redhat.com  Wed Feb  2 17:44:10 2022
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 02 Feb 2022 17:44:10 +0000
Subject: Home openstack lab
In-Reply-To: <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
Message-ID: <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com>

On Wed, 2022-02-02 at 17:07 +0000, Michael STFC wrote:
> Hi All:
> 
> I am kind of new to Openstack and want to setup openstack learning env or lab at home.
> 
> I have 3 HP MicroServers g8 with 16GB RAM and 5 HP MicroServers g7 with 8 GB RAM - all have dual or quad NIC and I have a 24 ports Aruba switch with VXLAN feature, older HP Procurve 24 switch. 
> 
> I am looking into have 3 nodes for run services and 2 for compute and remaining 3 for Ceph. 
> 
> Any advise on OS and which openstack distro I should and link to the documentations or guides?
most common distros have good support for openstack at this point.
there are several installers to choose form personally kolla-ansible is my prefered install openstack ansible might also be good for your scale
but i have not used it much. triploe is proably overkill and i would not advise using it as your first into to openstack

so assuming you are not going to use this for developing openstack kolla-ansible on debian or ubuntu with the source install option would be
my recommendation it has pretty good support for centos too but i belive they are moveing to mainly using debain images for the contianers
going forward so using a deb based host might have less issues

openstack ansibale i belive also supports both the rpm and deb worlds so really you can pick your poision with regard to
host OS. i would go with what you are most comforatbale with but ubuntu 20.04 is what most of our upstream ci uses

if you are plannig t do developemnt i would use devstack but if you want this as a home lab to then run workload on i would use somethig else.

for ceph cephadm is proably the way to go and you should be able to integrate a standalone ceph cluster with this deployment.
kolla support external ceph and i suspect openstack ansible does too.

one thing to note is i proably woudl proably also run the nova compute serive on the contolers to get the most out of the cluster.

even with only 8gb of ram you can run a full contoler and have 1-2 GB of ram left over for vms
so unless you decide to have the contoler also run ceph i would co locate the compute service on the contoler too

if you do plan to have ceph and the openstack contolers coloacated then i would reuse the 3 nodes you planned ot dedicated fro ceph as computes.

you certenly can have each system have a singel role but you can consolidate into a hyperconverd toplogy too.
> 
> Regards,
> 
> Michael
> 
> 
> 



From mahendra.paipuri at cnrs.fr  Wed Feb  2 18:18:58 2022
From: mahendra.paipuri at cnrs.fr (PAIPURI Mahendra)
Date: Wed, 2 Feb 2022 18:18:58 +0000
Subject: Home openstack lab
In-Reply-To: <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
 <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com>
Message-ID: <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>

Hello Sean and Jean-Fran?ois,

Thanks for your answers. I am getting myself into the world of Openstack and I have few questions on similar subject.

You mentioned that the development team is moving towards Debian images for containers for kolla ansible. Does it mean they will drop the support for CentOS 8 Stream in near future?

From my understanding, Openstack ansible can be deployed without use of linux containers at all. Did someone try this approach? Is it scalable and stable? The problem is we might have restrictions on using containers at our organisation. So, a container-less solution for deploying and operating Openstack would be very helpful for us.

At what scale TripleO starts to pay off? We will have a cluster of 100-200 nodes soon and we will deploy Openstack on it. What would be a good deployment method for that scale? 

Thanks

Regards
Mahendra

> On 2 Feb 2022, at 18:44, Sean Mooney <smooney at redhat.com> wrote:
> 
> On Wed, 2022-02-02 at 17:07 +0000, Michael STFC wrote:
>> Hi All:
>> 
>> I am kind of new to Openstack and want to setup openstack learning env or lab at home.
>> 
>> I have 3 HP MicroServers g8 with 16GB RAM and 5 HP MicroServers g7 with 8 GB RAM - all have dual or quad NIC and I have a 24 ports Aruba switch with VXLAN feature, older HP Procurve 24 switch. 
>> 
>> I am looking into have 3 nodes for run services and 2 for compute and remaining 3 for Ceph. 
>> 
>> Any advise on OS and which openstack distro I should and link to the documentations or guides?
> most common distros have good support for openstack at this point.
> there are several installers to choose form personally kolla-ansible is my prefered install openstack ansible might also be good for your scale
> but i have not used it much. triploe is proably overkill and i would not advise using it as your first into to openstack
> 
> so assuming you are not going to use this for developing openstack kolla-ansible on debian or ubuntu with the source install option would be
> my recommendation it has pretty good support for centos too but i belive they are moveing to mainly using debain images for the contianers
> going forward so using a deb based host might have less issues
> 
> openstack ansibale i belive also supports both the rpm and deb worlds so really you can pick your poision with regard to
> host OS. i would go with what you are most comforatbale with but ubuntu 20.04 is what most of our upstream ci uses
> 
> if you are plannig t do developemnt i would use devstack but if you want this as a home lab to then run workload on i would use somethig else.
> 
> for ceph cephadm is proably the way to go and you should be able to integrate a standalone ceph cluster with this deployment.
> kolla support external ceph and i suspect openstack ansible does too.
> 
> one thing to note is i proably woudl proably also run the nova compute serive on the contolers to get the most out of the cluster.
> 
> even with only 8gb of ram you can run a full contoler and have 1-2 GB of ram left over for vms
> so unless you decide to have the contoler also run ceph i would co locate the compute service on the contoler too
> 
> if you do plan to have ceph and the openstack contolers coloacated then i would reuse the 3 nodes you planned ot dedicated fro ceph as computes.
> 
> you certenly can have each system have a singel role but you can consolidate into a hyperconverd toplogy too.
>> 
>> Regards,
>> 
>> Michael
>> 
>> 
>> 
> 
> 


From smooney at redhat.com  Wed Feb  2 18:43:37 2022
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 02 Feb 2022 18:43:37 +0000
Subject: Home openstack lab
In-Reply-To: <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
 <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com>
 <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
Message-ID: <ca6ae2a727b783e852c2e63ca703db5064c3b16e.camel@redhat.com>

On Wed, 2022-02-02 at 18:18 +0000, PAIPURI Mahendra wrote:
> Hello Sean and Jean-Fran?ois,
> 
> Thanks for your answers. I am getting myself into the world of Openstack and I have few questions on similar subject.
> 
> You mentioned that the development team is moving towards Debian images for containers for kolla ansible. Does it mean they will drop the support for CentOS 8 Stream in near future?
i dont work on kolla any more but i belive there plan is to drop support for building container on centos-8-stream and only support debian as an image
base in the openstack AA release.
centos should this be usable as a host os but the contaienr will jut use a differnt os internally.
that is generally fine. currently you can use centos 8 stream  for the contaienr base image but i knwo they dont plan to support centos 9 stream
so when python 3.6 is nolonger supported next cycle kollas will have to drop suport for centos 8 images in anycase.
> 
> From my understanding, Openstack ansible can be deployed without use of linux containers at all. Did someone try this approach? Is it scalable and stable? The problem is we might have restrictions on using containers at our organisation. So, a container-less solution for deploying and operating Openstack would be very helpful for us.
> 
i belive it can deploy with lxc/lxd container and without contianer yes.
i think without contaienr is what vexhost use for there public cloud in the past
althoguh it hink they have moved to use a k8s based operatro driven installs now.
https://opendev.org/vexxhost/openstack-operator

i think that is now what they use in production

i do not have that much expirce wiht osa but i would not expect the non contaierised version to be any less scalable the the contaienr based approch
osa does not use docker so there contaier based install is a singel app per contaier as far as im aware so they effectivly use the same playbooks to
install the pacages in the lxc contaienr when using containers.

its been about 2-3 years since i relly looked at how osa works so that could be out of date.

if you have restriciton on using containers and you do not like ansible you could also look at the openstack puppet modules
but i dont think they get much usage outside fo ooo so your milage will vary.

> At what scale TripleO starts to pay off? We will have a cluster of 100-200 nodes soon and we will deploy Openstack on it. What would be a good deployment method for that scale? 
> 
unless you have a vendor support contract with redhat i personally dont think there is a scale where it beniftis you in a self support mode form rdo.
that is just my personal opipion but ooo is very tied to the downstream redhat openstack product lifecyce for things like upgrades.
since we only support fast forward upgrades in our product that is all the redhat contibute really spend type impleemnting and testign so if that
does not work for you its not a good fit.
> Thanks
> 
> Regards
> Mahendra
> 
> > On 2 Feb 2022, at 18:44, Sean Mooney <smooney at redhat.com> wrote:
> > 
> > On Wed, 2022-02-02 at 17:07 +0000, Michael STFC wrote:
> > > Hi All:
> > > 
> > > I am kind of new to Openstack and want to setup openstack learning env or lab at home.
> > > 
> > > I have 3 HP MicroServers g8 with 16GB RAM and 5 HP MicroServers g7 with 8 GB RAM - all have dual or quad NIC and I have a 24 ports Aruba switch with VXLAN feature, older HP Procurve 24 switch. 
> > > 
> > > I am looking into have 3 nodes for run services and 2 for compute and remaining 3 for Ceph. 
> > > 
> > > Any advise on OS and which openstack distro I should and link to the documentations or guides?
> > most common distros have good support for openstack at this point.
> > there are several installers to choose form personally kolla-ansible is my prefered install openstack ansible might also be good for your scale
> > but i have not used it much. triploe is proably overkill and i would not advise using it as your first into to openstack
> > 
> > so assuming you are not going to use this for developing openstack kolla-ansible on debian or ubuntu with the source install option would be
> > my recommendation it has pretty good support for centos too but i belive they are moveing to mainly using debain images for the contianers
> > going forward so using a deb based host might have less issues
> > 
> > openstack ansibale i belive also supports both the rpm and deb worlds so really you can pick your poision with regard to
> > host OS. i would go with what you are most comforatbale with but ubuntu 20.04 is what most of our upstream ci uses
> > 
> > if you are plannig t do developemnt i would use devstack but if you want this as a home lab to then run workload on i would use somethig else.
> > 
> > for ceph cephadm is proably the way to go and you should be able to integrate a standalone ceph cluster with this deployment.
> > kolla support external ceph and i suspect openstack ansible does too.
> > 
> > one thing to note is i proably woudl proably also run the nova compute serive on the contolers to get the most out of the cluster.
> > 
> > even with only 8gb of ram you can run a full contoler and have 1-2 GB of ram left over for vms
> > so unless you decide to have the contoler also run ceph i would co locate the compute service on the contoler too
> > 
> > if you do plan to have ceph and the openstack contolers coloacated then i would reuse the 3 nodes you planned ot dedicated fro ceph as computes.
> > 
> > you certenly can have each system have a singel role but you can consolidate into a hyperconverd toplogy too.
> > > 
> > > Regards,
> > > 
> > > Michael
> > > 
> > > 
> > > 
> > 
> > 
> 



From fungi at yuggoth.org  Wed Feb  2 18:45:04 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 2 Feb 2022 18:45:04 +0000
Subject: Home openstack lab
In-Reply-To: <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
 <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com>
 <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
Message-ID: <20220202184337.nwx2kppa2roy7s2j@yuggoth.org>

On 2022-02-02 18:18:58 +0000 (+0000), PAIPURI Mahendra wrote:
[...]
> we might have restrictions on using containers at our
> organisation. So, a container-less solution for deploying and
> operating Openstack would be very helpful for us.
[...]

For non-container-based deployments, you could also consider a
distribution like Debian which packages OpenStack:

    https://wiki.debian.org/OpenStack

Check out the list of available distributions in the Marketplace as
there may be more which aren't container-based and don't require
support contracts, I just don't know which others fit those criteria
off the top of my head:

    https://www.openstack.org/marketplace/distros/

-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/1c09a141/attachment.sig>

From fungi at yuggoth.org  Wed Feb  2 18:48:16 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 2 Feb 2022 18:48:16 +0000
Subject: Home openstack lab
In-Reply-To: <ca6ae2a727b783e852c2e63ca703db5064c3b16e.camel@redhat.com>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
 <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com>
 <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
 <ca6ae2a727b783e852c2e63ca703db5064c3b16e.camel@redhat.com>
Message-ID: <20220202184816.rw22uv2bfvl4dmaw@yuggoth.org>

On 2022-02-02 18:43:37 +0000 (+0000), Sean Mooney wrote:
[...]
> if you have restriciton on using containers and you do not like
> ansible you could also look at the openstack puppet modules but i
> dont think they get much usage outside fo ooo so your milage will
> vary.
[...]

It's my understanding that the OpenStack Cluster Installer in Debian
uses packaged copies of those Puppet modules to perform
configuration management.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/586c3abd/attachment-0001.sig>

From openstack at a.spamming.party  Wed Feb  2 19:17:19 2022
From: openstack at a.spamming.party (Jean-Philippe Evrard)
Date: Wed, 02 Feb 2022 20:17:19 +0100
Subject: [all][tc] Relmgt team position on release cadence
In-Reply-To: <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>
References: <40f6f51b-6903-1afe-7318-0689b2af482d@openstack.org>
 <8301ef05-4011-43e9-beec-66f6aeeb00f9@www.fastmail.com>
 <20211129130957.3poysdeqsufkp3pg@yuggoth.org>
 <f2c4ab93-a1e1-475c-8b35-1b303b8fb96b@www.fastmail.com>
 <d28fc7ccfecd753561e1d395c672e987f95eb748.camel@redhat.com>
 <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com>
 <CAF7gwdiUF2wj7RqN-LzwvwH1FQ1A7j=F-CikHKS0ct8AKNAdJg@mail.gmail.com>
 <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org>
 <CAF7gwdhnS_101_Ljf++V=-jGwKZ_NUm6gn+Jzo_N-VDwDuvayw@mail.gmail.com>
 <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com>
 <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
 <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>
Message-ID: <fc5569d6-15e6-4d33-b0f4-2d619f90e732@www.fastmail.com>

On Tue, Feb 1, 2022, at 23:14, Ghanshyam Mann wrote:
> I might not be available this week, we will schedule this meeting next 
> week or so.

Ok, I hope I won't miss the next date then! :)
Thanks for organising this, Ghanshyam.

Regards,
JP


From smooney at redhat.com  Wed Feb  2 19:58:15 2022
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 02 Feb 2022 19:58:15 +0000
Subject: Home openstack lab
In-Reply-To: <20220202184816.rw22uv2bfvl4dmaw@yuggoth.org>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
 <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com>
 <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
 <ca6ae2a727b783e852c2e63ca703db5064c3b16e.camel@redhat.com>
 <20220202184816.rw22uv2bfvl4dmaw@yuggoth.org>
Message-ID: <843f0b90aff82cede683933781d2e0d764be2ecc.camel@redhat.com>

On Wed, 2022-02-02 at 18:48 +0000, Jeremy Stanley wrote:
> On 2022-02-02 18:43:37 +0000 (+0000), Sean Mooney wrote:
> [...]
> > if you have restriciton on using containers and you do not like
> > ansible you could also look at the openstack puppet modules but i
> > dont think they get much usage outside fo ooo so your milage will
> > vary.
> [...]
> 
> It's my understanding that the OpenStack Cluster Installer in Debian
> uses packaged copies of those Puppet modules to perform
> configuration management.
oh good to know.

i have heard good things about the debian installer but never used it
and dont know of any large scale deployment but for me simple is always better
then complex nad just using puppet or ansible with or without contaienr
makes grocking what is going on and why its broken much simpler when somethign
does go wrong.

if im self support a cluster like a home lab or even a small lab for a company
being able to understand what the installer is doing is high on my list.



From Ronald.Stone at windriver.com  Wed Feb  2 20:49:05 2022
From: Ronald.Stone at windriver.com (Stone, Ronald)
Date: Wed, 2 Feb 2022 20:49:05 +0000
Subject: bypass sphinx conf.py from CLI
Message-ID: <DM6PR11MB34191E22A1F4498571BE437C8C279@DM6PR11MB3419.namprd11.prod.outlook.com>

Hi,



The StarlingX docs team is implementing the default sphinxcontrib.spelling spelling extension for use from tox via a virtualenv set up for this purpose. We do not want sphinxcontrib.spelling loaded into other tox jobs that won't use it. This means that it cannot be loaded from the standard conf.py. Instead I am bypassing conf.py and setting parameters from the sphinx-build command in the appropriate tox job:



sphinx-build -a -E -C --keep-going -d doc/build/doctrees -D extensions=sphinxcontrib.spelling -D spelling_word_list_filename=spelling_wordlist.txt -D rst_prolog="open('./shared/strings.txt', 'r').read()" -t starlingx -t openstack -b spelling doc/source doc/build/spelling {posargs}



This works except that we also need to load some strings into the rst prolog for various purposes, and that is failing without warning or errors. I can open the file from a python console. Sphinx-build escapes the single quotes as:

open('"'"'./shared/strings.txt'"'"', '"'"'r'"'"').read()'



Any suggestions on the correct parameter format appreciated.



Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/3c29de24/attachment.htm>

From fungi at yuggoth.org  Wed Feb  2 22:09:41 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 2 Feb 2022 22:09:41 +0000
Subject: bypass sphinx conf.py from CLI
In-Reply-To: <DM6PR11MB34191E22A1F4498571BE437C8C279@DM6PR11MB3419.namprd11.prod.outlook.com>
References: <DM6PR11MB34191E22A1F4498571BE437C8C279@DM6PR11MB3419.namprd11.prod.outlook.com>
Message-ID: <20220202220941.2i4eu7aouqc4lvji@yuggoth.org>

On 2022-02-02 20:49:05 +0000 (+0000), Stone, Ronald wrote:
> The StarlingX docs team is implementing the default
> sphinxcontrib.spelling spelling extension for use from tox via a
> virtualenv set up for this purpose. We do not want
> sphinxcontrib.spelling loaded into other tox jobs that won't use
> it. This means that it cannot be loaded from the standard conf.py.
> Instead I am bypassing conf.py and setting parameters from the
> sphinx-build command in the appropriate tox job:
[...]

Have you considered creating a separate doc/source/conf-spelling.py
and passing that via sphinx-build's -c option 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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220202/3ace73da/attachment.sig>

From mnaser at vexxhost.com  Wed Feb  2 23:07:00 2022
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Wed, 2 Feb 2022 18:07:00 -0500
Subject: Recently Upgraded to XENA and getting this error
In-Reply-To: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
Message-ID: <CAEs876iG0Ph4zToqbwC08JftTo4mKY2w8BKBncMN_ekKc3dQZA@mail.gmail.com>

I think you're running into this which has been broken for a hot minute:

https://review.opendev.org/c/openstack/horizon/+/808102

that patch works for us locally.

On Wed, Feb 2, 2022 at 10:37 AM Adivya Singh <adivya1.singh at gmail.com> wrote:
>
> Hello,
>
> We have recently upgraded to XENA release of Openstack, and getting this error while trying to Resize instance using GUI, it is telling "Danger , Please try Later"
> Same is working properly from CLI without any issue
>
> Any thoughts on this
>
> Regards
> Adivya Singh



-- 
Mohammed Naser
VEXXHOST, Inc.


From jonathan.rosser at rd.bbc.co.uk  Thu Feb  3 07:41:25 2022
From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser)
Date: Thu, 3 Feb 2022 07:41:25 +0000
Subject: Home openstack lab
In-Reply-To: <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <9E76A521-0833-4121-A13D-7671D764701C@gmail.com>
 <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com>
 <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
Message-ID: <8559cc30-b01a-c8e9-c61d-05a3d3219ce2@rd.bbc.co.uk>

Openstack-ansible supports a containerless installation. We test this in 
CI equivalently to the LXC containers deployment - note that these are 
machine containers - analogous to VMs, and not docker type containers.

I would personally choose Ubuntu 20.04 as the OS - mostly due to the 
limited lifetime of python 3.6 which you might find elsewhere, plus the 
availability of a full set of upstream ceph packages which may be harder 
to find for some other distros.

OSA has managed to provide long and heavily overlapping lifecycles for 
Ubuntu based deployments, see 
https://docs.openstack.org/openstack-ansible/latest/en_GB/admin/upgrades/compatibility-matrix.html. 
This is something you should consider when planning how you are going to 
manage and upgrade your deployment. The more overlap you have the more 
freedom you have to work around external factors such as your preferred 
ceph versions.

The tools mentioned in this thread are not really "shrink-wrap" 
installers for OpenStack, only you can architect your deployment to meet 
your particular requirements for hardware, HA, storage and networking 
setup. This architecture has to align with what is possible with the 
deployment tools, and OpenStack in general. Check if the various tools 
provide a reference architecture you can start from.

Take a look at the available documentation, and join the relevant IRC 
channels. Operators using OSA who join #openstack-ansible and be an 
active part of the community are the ones who gain the most value.

Just my opinion - others may vary :)

Jonathan.

>  From my understanding, Openstack ansible can be deployed without use of linux containers at all. Did someone try this approach? Is it scalable and stable? The problem is we might have restrictions on using containers at our organisation. So, a container-less solution for deploying and operating Openstack would be very helpful for us.
>
>


From radoslaw.piliszek at gmail.com  Thu Feb  3 07:57:26 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Thu, 3 Feb 2022 08:57:26 +0100
Subject: [all][tc] Technical Committee next weekly meeting is today (Feb 3rd)
 at 1500 UTC
Message-ID: <CAKZ_x79Vm1c2AGT=7hSzosb-BsOAXHFMHdUe64E1K0i1r4FxNw@mail.gmail.com>

Hello OpenStackers,

Below is the agenda for today's TC IRC meeting scheduled at 1500 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

== Agenda for today's TC meeting ==

* Roll call

* Follow up on past action items

* Gate health check
** Fixing Zuul config error in OpenStack
*** https://etherpad.opendev.org/p/zuul-config-error-openstack

* Progress check on Yoga tracker
** https://etherpad.opendev.org/p/tc-yoga-tracker

* Z Release Cycle Name
** Election results:
https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f
** Next step, the foundation has started the trademark checks.

* Z cycle Technical Elections
** Proposed Election schedule, need to merge it if no objection.
*** https://review.opendev.org/c/openstack/election/+/825017

* Open Reviews
** https://review.opendev.org/q/projects:openstack/governance+is:open

-yoctozepto


From geguileo at redhat.com  Thu Feb  3 09:53:19 2022
From: geguileo at redhat.com (Gorka Eguileor)
Date: Thu, 3 Feb 2022 10:53:19 +0100
Subject: [os-brick][nova][cinder][glance] Question about lock_path
In-Reply-To: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
References: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
Message-ID: <20220203095319.7pezolzhq3glfpky@localhost>

On 01/02, Rados?aw Piliszek wrote:
> Hello Fellow OpenStackers!
>
> I have noticed os-brick started using the file locks (in lock_path) to
> avoid race conditions.
> I have a question regarding that lock_path - it seems all the cases I
> have found use separate lock_paths per service, yet the problematic
> cases listed in the bug report (and the commit message of [1]) suggest
> that, in case of co-hosted nova-compute, glance-api, cinder-volume and
> cinder-backup services (or any combination thereof), the lock_path
> should be shared.
> Should the deployment projects adapt to actually fix the race condition issue?
>
> [1] https://review.opendev.org/c/openstack/os-brick/+/814139
>
> Kind regards,
> -yoctozepto
>

Hi,

Yes, it is the deployment tool's responsibility to set the right
lock_path value on the following cases:

- Hyperconverged deployment: Cinder-volume or cinder-backup are running
  on the same node as thee nova-compute service.

- Glance is using Cinder as a backend.

In all other cases it doesn't matter the value of the lock_path since
there only 1 project that uses os-brick, even if it has multiple
processes and/or services using it as is the case in cinder-volume and
cinder-backup running on the same host or cinder-backup running multiple
processes.

Cheers,
Gorka.



From andrea.gargano at dgsspa.com  Thu Feb  3 10:02:12 2022
From: andrea.gargano at dgsspa.com (Gargano Andrea)
Date: Thu, 3 Feb 2022 10:02:12 +0000
Subject: [stein][neutron] Static rules losed
Message-ID: <DB9PR05MB8139F9ABE3777BF7B9508F78E7289@DB9PR05MB8139.eurprd05.prod.outlook.com>

Hi all,
we faced an inssue in our openstack, we have some private clouds with static rules, if the controller that own namespace with the static rule goes down, namespace moves to other controller but it loses the rule.
I can still see the rules inside the router on openstack but it doesn't work until recreated.
Have you seen something like this?
Thank you in advance.

Andrea Gargano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/d91f0eb3/attachment.htm>

From geguileo at redhat.com  Thu Feb  3 10:12:21 2022
From: geguileo at redhat.com (Gorka Eguileor)
Date: Thu, 3 Feb 2022 11:12:21 +0100
Subject: [os-brick][nova][cinder][glance] Question about lock_path
In-Reply-To: <KAZM6R.PMGVW2CFO3SR1@est.tech>
References: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
 <YZUM6R.GG3LDYZYOQH83@est.tech>
 <b84166be-b6ad-d596-69fb-010677629556@nemebean.com>
 <KAZM6R.PMGVW2CFO3SR1@est.tech>
Message-ID: <20220203101221.yygkfeo5prrx63oh@localhost>

On 01/02, Balazs Gibizer wrote:
>
>
> On Tue, Feb 1 2022 at 11:07:07 AM -0600, Ben Nemec <openstack at nemebean.com>
> wrote:
> > General question: Are file locks even sufficient for this? If we're
> > talking about multiple services coordinating access to a resource, do we
> > know for certain that all of the processes accessing the resource are on
> > the same system? If not, file locks can't solve this anyway.
> >

Hi,

File locks are sufficient and also necessary for some connector types.

I don't want to get too much into it, but these file locks are only
trying to create a critical section within a node, not deployment wide.

For example, we know that the Linux Open-iSCSI initiator has lots of
problems with concurrent access (due to the persistent configuration
database), so we only want to make sure that there are no 2 concurrent
calls to it.


> > If so, see my thoughts below.
> >
> > On 2/1/22 09:57, Balazs Gibizer wrote:
> > >
> > >
> > > On Tue, Feb 1 2022 at 11:50:28 AM +0100, Rados?aw Piliszek
> > > <radoslaw.piliszek at gmail.com> wrote:
> > > > Hello Fellow OpenStackers!
> > > >
> > > > I have noticed os-brick started using the file locks (in
> > > > lock_path) to
> > > > avoid race conditions.
> > > > I have a question regarding that lock_path - it seems all the
> > > > cases I
> > > > have found use separate lock_paths per service, yet the problematic
> > > > cases listed in the bug report (and the commit message of [1])
> > > > suggest
> > > > that, in case of co-hosted nova-compute, glance-api,
> > > > cinder-volume and
> > > > cinder-backup services (or any combination thereof), the lock_path
> > > > should be shared.
> > > > Should the deployment projects adapt to actually fix the race
> > > > condition issue?
> > >
> > > An alternative to that would be that os-brick has specific lock path
> > > config option regardless of which service is importing the lib.
> > > Then the oslo_concurrency.lockutils.lock() can be called with that
> > > os-brick specific path from os-brick.
> >
> > The lock_path config opt is owned by oslo.concurrency so I don't think
> > this is possible today. The simplest and least error-prone solution is
> > to configure all of the users of os-brick to use the same lock path.
>
> The oslo_concurrency.lockutils.lock() call takes a lock_path kwargs that can
> be used to override the configured lock_path as far as I see[1][2][3].
>
> >
> > Even if we provided a way to override the lock path for just os-brick,
> > you'd still need to add a config opt to each service that points at a
> > common location and the deployment tools would need to configure that
> > and create the shared directory. You don't save the deployment tools any
> > effort this way.
>

I agree, that's why I didn't add a new one when I developed that patch.

In retrospective I should have added to the commit message and release
notes the cases where admins/deployment tools need to use the same
lock_path.


> os_brick can expose a new config option with a sane default and document
> that if that default is changed then the config of every service using
> os_brick needs to be changed to have the same value.
>
> >
> > Keeping a single lock path for everything running in a given service
> > also eliminates the possibility that a lock gets used both in and out of
> > os-brick, which would break if os-brick had a separate path. I don't
> > know if that happens, but a single lock path means you never have to
> > answer that question.
>
> Good point. That is a clear advantage of this proposal.
>
> >
> > One drawback I can see to a single lock path for multiple services is
> > possible collisions of lock names. Previously each service could name
> > locks whatever they wanted as long as there were no duplicates within
> > the service. If they start sharing lock path, there can be no duplicates
> > between any of the services sharing the lock path. I can't say how much
> > of a problem this would be, but we could probably come up with some way
> > to look at the lock names used in a service and make sure there's no
> > overlap.
> >
> > Also, I _think_ even if there were a duplicate lock name in two
> > services, the worst that would happen is some unnecessary lock
> > contention.* You might introduce a performance problem, but not a race.
> > Personally, that's a tradeoff I'd happily make.
> >
> > *: If you had multiple duplicate locks being acquired in different
> > orders between the two services, it's possible you could introduce a
> > deadlock. A lot has to go wrong for that to happen, but in the interest
> > of completeness it should be considered. Have I mentioned that
> > concurrency is hard? ;-)
>

There shouldn't be any unintended lock name collision or lock
contention, because services use a service specific prefix for their
own locks. At least Cinder [1] and Nova [2] do.  OS-Brick doesn't use
those prefixed locks but bare locks so they are shared between services,
as intended.

Cheers,
Gorka.

[1]: https://github.com/openstack/cinder/blob/5cf395b38544b2e96bdf625b3aae66f0b2898814/cinder/utils.py#L72
[2]: https://github.com/openstack/nova/blob/b0633ac49bfbe2e0e51ef0506f626d2dbf7c1705/nova/utils.py#L62

>
> [1] https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L236
> [2] https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L188
> [3] https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L180
>
>
>



From andrea.gargano at dgsspa.com  Thu Feb  3 10:16:35 2022
From: andrea.gargano at dgsspa.com (Gargano Andrea)
Date: Thu, 3 Feb 2022 10:16:35 +0000
Subject: R: [stein][neutron] Static rules losed
In-Reply-To: <DB9PR05MB8139F9ABE3777BF7B9508F78E7289@DB9PR05MB8139.eurprd05.prod.outlook.com>
References: <DB9PR05MB8139F9ABE3777BF7B9508F78E7289@DB9PR05MB8139.eurprd05.prod.outlook.com>
Message-ID: <DB9PR05MB8139B6550B4E417DDF6628B8E7289@DB9PR05MB8139.eurprd05.prod.outlook.com>

Before controller reboot:

ip netns exec qrouter-808a7d28-5cf4-42c5-b74b-1d8b44193f13 netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.102.186.0    0.0.0.0         255.255.255.0   U         0 0          0 qr-c8ea8a1d-fe
169.254.0.0     0.0.0.0         255.255.255.0   U         0 0          0 ha-d030f1d9-d5
169.254.192.0   0.0.0.0         255.255.192.0   U         0 0          0 ha-d030f1d9-d5
192.168.69.0    10.102.186.251  255.255.255.0   UG        0 0          0 qr-c8ea8a1d-fe
192.168.100.0   0.0.0.0         255.255.255.0   U         0 0          0 qr-4b5d42cf-f4

After reboot on new controller node:

ip netns exec qrouter-808a7d28-5cf4-42c5-b74b-1d8b44193f13 netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.102.186.0    0.0.0.0         255.255.255.0   U         0 0          0 qr-c8ea8a1d-fe
169.254.0.0     0.0.0.0         255.255.255.0   U         0 0          0 ha-e7a4fd30-d5
169.254.192.0   0.0.0.0         255.255.192.0   U         0 0          0 ha-e7a4fd30-d5
192.168.100.0   0.0.0.0         255.255.255.0   U         0 0          0 qr-4b5d42cf-f4

Log l3 agent:

2022-02-03 10:36:32.241 11383 INFO neutron.agent.l3.agent [-] Finished a router update for 808a7d28-5cf4-42c5-b74b-1d8b44193f13, update_id eec87271-612e-4883-9ea4-75007de9f6cb. Time elapsed: 1.653
2022-02-03 11:09:46.107 11383 INFO eventlet.wsgi.server [-] <local> "GET / HTTP/1.1" status: 200  len: 115 time: 0.0016830
2022-02-03 11:09:46.108 11383 INFO eventlet.wsgi.server [-] <local> "GET / HTTP/1.1" status: 200  len: 115 time: 0.0015860
2022-02-03 11:09:48.107 11383 INFO neutron.agent.l3.ha [-] Router 43707d80-3449-4c4a-bd87-2fcb380bcdcf transitioned to master
2022-02-03 11:09:48.108 11383 INFO neutron.agent.l3.ha_router [-] Set router 43707d80-3449-4c4a-bd87-2fcb380bcdcf gateway device link state to up.
2022-02-03 11:09:48.109 11383 INFO neutron.agent.l3.ha [-] Router 808a7d28-5cf4-42c5-b74b-1d8b44193f13 transitioned to master
2022-02-03 11:09:48.109 11383 INFO neutron.agent.l3.ha_router [-] Set router 808a7d28-5cf4-42c5-b74b-1d8b44193f13 gateway device link state to up.

Andrea

Da: Gargano Andrea
Inviato: gioved? 3 febbraio 2022 11:02
A: openstack-discuss <openstack-discuss at lists.openstack.org>
Oggetto: [stein][neutron] Static rules losed

Hi all,
we faced an inssue in our openstack, we have some private clouds with static rules, if the controller that own namespace with the static rule goes down, namespace moves to other controller but it loses the rule.
I can still see the rules inside the router on openstack but it doesn't work until recreated.
Have you seen something like this?
Thank you in advance.

Andrea Gargano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/71ec09b3/attachment.htm>

From geguileo at redhat.com  Thu Feb  3 10:16:36 2022
From: geguileo at redhat.com (Gorka Eguileor)
Date: Thu, 3 Feb 2022 11:16:36 +0100
Subject: [cinder] new driver freeze & exceptions
In-Reply-To: <82a1b19c-477c-2fd0-87d7-b1473ebf760c@gmail.com>
References: <72ed9f96-7f1e-0d0c-63fd-aa3602d703b6@gmail.com>
 <82a1b19c-477c-2fd0-87d7-b1473ebf760c@gmail.com>
Message-ID: <20220203101636.gdhddtqekki7qdc5@localhost>

On 28/01, Brian Rosmaita wrote:
> Update:
>
> The NEC Storage V Series driver has merged.
>
> The Lightbits driver has three +2s.  The Lightbits os-brick connector it
> depends on has not yet merged, but has been actively revised to address
> comments.  I am extending the new driver freeze exception until 20:00
> Wednesday 2 February.
>

Update:

The Lightbits cinder driver and os-brick connector patches have merged
withing the freeze exception timeframe.


>
> On 1/21/22 5:25 PM, Brian Rosmaita wrote:
> > Hello Argonauts,
> >
> > The new driver merge deadline passed at 20:00 UTC today.
> >
> > I'm extending the new driver merge deadline to Friday 28 January at
> > 20:00 UTC for two drivers:
> >
> > 1. Lightbits: It has both a cinder and os-brick patch, and I want the
> > team to have more time to look at the os-brick patch.? I think the
> > driver patch is close to ready; the developers have been quick to
> > respond to comments and make revisions.? Also, the third-party CI is
> > functioning and responding on patches.
> >  ? cinder: https://review.opendev.org/c/openstack/cinder/+/821602
> >  ? os-brick: https://review.opendev.org/c/openstack/os-brick/+/821603
> >
> > 2. NEC Storage V Series: the driver patch has one +2 and the third party
> > CI is functioning and responding on patches; I don't see any reason to
> > make this one wait for the Z release.
> >  ? https://review.opendev.org/c/openstack/cinder/+/815614
> >
> > Cinder core reviewers: please continue to review the above patches.
> >
> > With respect to the other proposed drivers:
> > - Pure Storage NVMe-RoCE: vendor decided to hold it for Z
> > - Dell EMC PowerStore NFS driver: vendor decided to hold it for Z
> > - HPE XP Storage FC & iSCSI: the code is very straightforward, but the
> > CI is not ready yet, so this will have to wait for Z
> > - YADRO Tatlin.UNIFIED driver: initial patch arrived yesterday (and has
> > a -1 from Zuul); the CI appears to be running, but the cinder team needs
> > to move on to reviewing os-brick and Yoga feature patches, so this will
> > have to wait for Z also
> >
> >
> > cheers,
> > brian
>
>



From radoslaw.piliszek at gmail.com  Thu Feb  3 10:43:29 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Thu, 3 Feb 2022 11:43:29 +0100
Subject: [os-brick][nova][cinder][glance] Question about lock_path
In-Reply-To: <20220203095319.7pezolzhq3glfpky@localhost>
References: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
 <20220203095319.7pezolzhq3glfpky@localhost>
Message-ID: <CAKZ_x78zhcCPKAFTwvz_P5K0JMf+4ZUQp54R5Qq3PVqgauQ_-w@mail.gmail.com>

On Thu, 3 Feb 2022 at 10:53, Gorka Eguileor <geguileo at redhat.com> wrote:
>
> On 01/02, Rados?aw Piliszek wrote:
> > Hello Fellow OpenStackers!
> >
> > I have noticed os-brick started using the file locks (in lock_path) to
> > avoid race conditions.
> > I have a question regarding that lock_path - it seems all the cases I
> > have found use separate lock_paths per service, yet the problematic
> > cases listed in the bug report (and the commit message of [1]) suggest
> > that, in case of co-hosted nova-compute, glance-api, cinder-volume and
> > cinder-backup services (or any combination thereof), the lock_path
> > should be shared.
> > Should the deployment projects adapt to actually fix the race condition issue?
> >
> > [1] https://review.opendev.org/c/openstack/os-brick/+/814139
> >
> > Kind regards,
> > -yoctozepto
> >
>
> Hi,
>
> Yes, it is the deployment tool's responsibility to set the right
> lock_path value on the following cases:
>
> - Hyperconverged deployment: Cinder-volume or cinder-backup are running
>   on the same node as thee nova-compute service.
>
> - Glance is using Cinder as a backend.

Thank you, Gorka, for confirming.

> In all other cases it doesn't matter the value of the lock_path since
> there only 1 project that uses os-brick, even if it has multiple
> processes and/or services using it as is the case in cinder-volume and
> cinder-backup running on the same host or cinder-backup running multiple
> processes.

Yeah, that I figured out. :-)

Cheers,
-yoctozepto

> Cheers,
> Gorka.
>


From radoslaw.piliszek at gmail.com  Thu Feb  3 10:47:25 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Thu, 3 Feb 2022 11:47:25 +0100
Subject: [os-brick][nova][cinder][glance] Question about lock_path
In-Reply-To: <20220203101221.yygkfeo5prrx63oh@localhost>
References: <CAKZ_x7_1ypJWWkxYO_jzWxzFfsOyKS-XS3fh2QNqZRQySCtT1A@mail.gmail.com>
 <YZUM6R.GG3LDYZYOQH83@est.tech>
 <b84166be-b6ad-d596-69fb-010677629556@nemebean.com>
 <KAZM6R.PMGVW2CFO3SR1@est.tech> <20220203101221.yygkfeo5prrx63oh@localhost>
Message-ID: <CAKZ_x7-+y9knYjVLQpdRzWHMijrjfwSf4VK=MbhE+0HiXhKX-Q@mail.gmail.com>

Thank you also for all these clarifications.

Cheers,
-yoctozepto

On Thu, 3 Feb 2022 at 11:12, Gorka Eguileor <geguileo at redhat.com> wrote:
>
> On 01/02, Balazs Gibizer wrote:
> >
> >
> > On Tue, Feb 1 2022 at 11:07:07 AM -0600, Ben Nemec <openstack at nemebean.com>
> > wrote:
> > > General question: Are file locks even sufficient for this? If we're
> > > talking about multiple services coordinating access to a resource, do we
> > > know for certain that all of the processes accessing the resource are on
> > > the same system? If not, file locks can't solve this anyway.
> > >
>
> Hi,
>
> File locks are sufficient and also necessary for some connector types.
>
> I don't want to get too much into it, but these file locks are only
> trying to create a critical section within a node, not deployment wide.
>
> For example, we know that the Linux Open-iSCSI initiator has lots of
> problems with concurrent access (due to the persistent configuration
> database), so we only want to make sure that there are no 2 concurrent
> calls to it.
>
>
> > > If so, see my thoughts below.
> > >
> > > On 2/1/22 09:57, Balazs Gibizer wrote:
> > > >
> > > >
> > > > On Tue, Feb 1 2022 at 11:50:28 AM +0100, Rados?aw Piliszek
> > > >  <radoslaw.piliszek at gmail.com> wrote:
> > > > > Hello Fellow OpenStackers!
> > > > >
> > > > > I have noticed os-brick started using the file locks (in
> > > > > lock_path) to
> > > > > avoid race conditions.
> > > > > I have a question regarding that lock_path - it seems all the
> > > > > cases I
> > > > > have found use separate lock_paths per service, yet the problematic
> > > > > cases listed in the bug report (and the commit message of [1])
> > > > > suggest
> > > > > that, in case of co-hosted nova-compute, glance-api,
> > > > > cinder-volume and
> > > > > cinder-backup services (or any combination thereof), the lock_path
> > > > > should be shared.
> > > > > Should the deployment projects adapt to actually fix the race
> > > > >   condition issue?
> > > >
> > > > An alternative to that would be that os-brick has specific lock path
> > > >  config option regardless of which service is importing the lib.
> > > > Then the  oslo_concurrency.lockutils.lock() can be called with that
> > > > os-brick  specific path from os-brick.
> > >
> > > The lock_path config opt is owned by oslo.concurrency so I don't think
> > > this is possible today. The simplest and least error-prone solution is
> > > to configure all of the users of os-brick to use the same lock path.
> >
> > The oslo_concurrency.lockutils.lock() call takes a lock_path kwargs that can
> > be used to override the configured lock_path as far as I see[1][2][3].
> >
> > >
> > > Even if we provided a way to override the lock path for just os-brick,
> > > you'd still need to add a config opt to each service that points at a
> > > common location and the deployment tools would need to configure that
> > > and create the shared directory. You don't save the deployment tools any
> > > effort this way.
> >
>
> I agree, that's why I didn't add a new one when I developed that patch.
>
> In retrospective I should have added to the commit message and release
> notes the cases where admins/deployment tools need to use the same
> lock_path.
>
>
> > os_brick can expose a new config option with a sane default and document
> > that if that default is changed then the config of every service using
> > os_brick needs to be changed to have the same value.
> >
> > >
> > > Keeping a single lock path for everything running in a given service
> > > also eliminates the possibility that a lock gets used both in and out of
> > > os-brick, which would break if os-brick had a separate path. I don't
> > > know if that happens, but a single lock path means you never have to
> > > answer that question.
> >
> > Good point. That is a clear advantage of this proposal.
> >
> > >
> > > One drawback I can see to a single lock path for multiple services is
> > > possible collisions of lock names. Previously each service could name
> > > locks whatever they wanted as long as there were no duplicates within
> > > the service. If they start sharing lock path, there can be no duplicates
> > > between any of the services sharing the lock path. I can't say how much
> > > of a problem this would be, but we could probably come up with some way
> > > to look at the lock names used in a service and make sure there's no
> > > overlap.
> > >
> > > Also, I _think_ even if there were a duplicate lock name in two
> > > services, the worst that would happen is some unnecessary lock
> > > contention.* You might introduce a performance problem, but not a race.
> > > Personally, that's a tradeoff I'd happily make.
> > >
> > > *: If you had multiple duplicate locks being acquired in different
> > > orders between the two services, it's possible you could introduce a
> > > deadlock. A lot has to go wrong for that to happen, but in the interest
> > > of completeness it should be considered. Have I mentioned that
> > > concurrency is hard? ;-)
> >
>
> There shouldn't be any unintended lock name collision or lock
> contention, because services use a service specific prefix for their
> own locks. At least Cinder [1] and Nova [2] do.  OS-Brick doesn't use
> those prefixed locks but bare locks so they are shared between services,
> as intended.
>
> Cheers,
> Gorka.
>
> [1]: https://github.com/openstack/cinder/blob/5cf395b38544b2e96bdf625b3aae66f0b2898814/cinder/utils.py#L72
> [2]: https://github.com/openstack/nova/blob/b0633ac49bfbe2e0e51ef0506f626d2dbf7c1705/nova/utils.py#L62
>
> >
> > [1] https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L236
> > [2] https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L188
> > [3] https://github.com/openstack/oslo.concurrency/blob/95b9334cfab6849fbe47e2b118e5355af3675dba/oslo_concurrency/lockutils.py#L180
> >
> >
> >
>


From stephenfin at redhat.com  Thu Feb  3 10:54:09 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Thu, 03 Feb 2022 10:54:09 +0000
Subject: bypass sphinx conf.py from CLI
In-Reply-To: <20220202220941.2i4eu7aouqc4lvji@yuggoth.org>
References: <DM6PR11MB34191E22A1F4498571BE437C8C279@DM6PR11MB3419.namprd11.prod.outlook.com>
 <20220202220941.2i4eu7aouqc4lvji@yuggoth.org>
Message-ID: <f3049e559fc220fae0f0465c2f3c14c92d858212.camel@redhat.com>

On Wed, 2022-02-02 at 22:09 +0000, Jeremy Stanley wrote:
> On 2022-02-02 20:49:05 +0000 (+0000), Stone, Ronald wrote:
> > The StarlingX docs team is implementing the default
> > sphinxcontrib.spelling spelling extension for use from tox via a
> > virtualenv set up for this purpose. We do not want
> > sphinxcontrib.spelling loaded into other tox jobs that won't use
> > it. This means that it cannot be loaded from the standard conf.py.
> > Instead I am bypassing conf.py and setting parameters from the
> > sphinx-build command in the appropriate tox job:
> [...]
> 
> Have you considered creating a separate doc/source/conf-spelling.py
> and passing that via sphinx-build's -c option instead?

Also remember that the 'conf.py' is a Python file so you can encode logic in it.
tox injects environment variables when running [1]. It would be easy to check
for the presence of e.g. 'TOX_ENV_NAME' and add the extension as necessary.

Stephen

[1] https://tox.wiki/en/latest/config.html#injected-environment-variables



From alifshit at redhat.com  Thu Feb  3 11:49:51 2022
From: alifshit at redhat.com (Artom Lifshitz)
Date: Thu, 3 Feb 2022 06:49:51 -0500
Subject: [nova][tempest] nova-next gate blocker
In-Reply-To: <CALg0jKn53=u5o7kODcZn2ah_EV0p000OyD4ceHZ_4y5Yr4HkQQ@mail.gmail.com>
References: <CACqyMif5ezXRrBSKrUjkwg8hGxK9nA61U=73VgB0B6EgwduH3g@mail.gmail.com>
 <CALg0jKn53=u5o7kODcZn2ah_EV0p000OyD4ceHZ_4y5Yr4HkQQ@mail.gmail.com>
Message-ID: <CACqyMifs1yqXFX2h87qtFRtwcM+-f4Qr684Gf-cvkyGxM4xxGg@mail.gmail.com>

On Tue, Feb 1, 2022 at 11:38 AM Lajos Katona <katonalala at gmail.com> wrote:
>
> Hi,
> Thanks for bringing this up, just for reference the current fix for this issue is here:
> https://review.opendev.org/c/openstack/tempest/+/827258

That has merged - thanks to all involved! - and the Nova gate is now
(technically - another email is coming for that issue) unblocked.

>
> To make things harder we have to wait the solution for pip vs py36 issue:
> https://bugs.launchpad.net/neutron/+bug/1959600
> For this bug the solution/workaround is this patch: https://review.opendev.org/c/openstack/devstack/+/827155
>
> Perhaps there are other things, sorry for missing them :-)
> Regards
> Lajos Katona (lajoskatona)
>
>
>
> Artom Lifshitz <alifshit at redhat.com> ezt ?rta (id?pont: 2022. febr. 1., K, 16:39):
>>
>> nova-next (and possibly others) is broken because of
>> https://bugs.launchpad.net/tempest/+bug/1959682
>>
>> The fix is at https://review.opendev.org/c/openstack/tempest/+/827305,
>> with a Nova DNM patch to exercise it at
>> https://review.opendev.org/c/openstack/nova/+/827306
>>
>> Please hold your rechecks until this is resolved.
>>
>> Cheers!
>>
>>



From alifshit at redhat.com  Thu Feb  3 12:57:56 2022
From: alifshit at redhat.com (Artom Lifshitz)
Date: Thu, 3 Feb 2022 07:57:56 -0500
Subject: [nova][gate] test_tagged_attachment failing close to 100% in nova-next
Message-ID: <CACqyMic=UFcx-XZRT-LgyFX7m1cf_ocsuzCdZ_9R5K56H5_y0A@mail.gmail.com>

https://bugs.launchpad.net/nova/+bug/1959899

The test times out verifying the tags in the metadata API after
attaching a NIC and volume.

This is happening almost 100% of the time, but I've seen at least a
couple of passing runs as well. We have yet to determine what the
exact failure mode is - is the metadata API timing out (unlikely,
since every other test passes)? Or are the expected tags just not
present (more likely)?

I'm trying to figure some things out at [1], but other than that this
is very much under investigation with no root cause identified yet.

[1] https://review.opendev.org/c/openstack/nova/+/827549



From smooney at redhat.com  Thu Feb  3 15:06:47 2022
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 03 Feb 2022 15:06:47 +0000
Subject: [cinder] new driver freeze & exceptions
In-Reply-To: <20220203101636.gdhddtqekki7qdc5@localhost>
References: <72ed9f96-7f1e-0d0c-63fd-aa3602d703b6@gmail.com>
 <82a1b19c-477c-2fd0-87d7-b1473ebf760c@gmail.com>
 <20220203101636.gdhddtqekki7qdc5@localhost>
Message-ID: <2243896ab8a6e4fb94e7d1616ac31c2fc2414164.camel@redhat.com>

On Thu, 2022-02-03 at 11:16 +0100, Gorka Eguileor wrote:
> On 28/01, Brian Rosmaita wrote:
> > Update:
> > 
> > The NEC Storage V Series driver has merged.
> > 
> > The Lightbits driver has three +2s.  The Lightbits os-brick connector it
> > depends on has not yet merged, but has been actively revised to address
> > comments.  I am extending the new driver freeze exception until 20:00
> > Wednesday 2 February.
> > 
> 
> Update:
> 
> The Lightbits cinder driver and os-brick connector patches have merged
> withing the freeze exception timeframe.
we were just talking about this on the nova channel.
for it to be usable in nova an os-brick release needs to be done
https://github.com/openstack/os-brick/compare/5.1.0...master

so we need a 5.2.0 release based on b29f1529228bb7a16c2373f7bbf1cf862438aa23 i guess
https://github.com/openstack/releases/blob/master/deliverables/yoga/os-brick.yaml

then that will allow this to be useable in the zuul jobs ectra.


> 
> 
> > 
> > On 1/21/22 5:25 PM, Brian Rosmaita wrote:
> > > Hello Argonauts,
> > > 
> > > The new driver merge deadline passed at 20:00 UTC today.
> > > 
> > > I'm extending the new driver merge deadline to Friday 28 January at
> > > 20:00 UTC for two drivers:
> > > 
> > > 1. Lightbits: It has both a cinder and os-brick patch, and I want the
> > > team to have more time to look at the os-brick patch.? I think the
> > > driver patch is close to ready; the developers have been quick to
> > > respond to comments and make revisions.? Also, the third-party CI is
> > > functioning and responding on patches.
> > >  ? cinder: https://review.opendev.org/c/openstack/cinder/+/821602
> > >  ? os-brick: https://review.opendev.org/c/openstack/os-brick/+/821603
> > > 
> > > 2. NEC Storage V Series: the driver patch has one +2 and the third party
> > > CI is functioning and responding on patches; I don't see any reason to
> > > make this one wait for the Z release.
> > >  ? https://review.opendev.org/c/openstack/cinder/+/815614
> > > 
> > > Cinder core reviewers: please continue to review the above patches.
> > > 
> > > With respect to the other proposed drivers:
> > > - Pure Storage NVMe-RoCE: vendor decided to hold it for Z
> > > - Dell EMC PowerStore NFS driver: vendor decided to hold it for Z
> > > - HPE XP Storage FC & iSCSI: the code is very straightforward, but the
> > > CI is not ready yet, so this will have to wait for Z
> > > - YADRO Tatlin.UNIFIED driver: initial patch arrived yesterday (and has
> > > a -1 from Zuul); the CI appears to be running, but the cinder team needs
> > > to move on to reviewing os-brick and Yoga feature patches, so this will
> > > have to wait for Z also
> > > 
> > > 
> > > cheers,
> > > brian
> > 
> > 
> 
> 



From smooney at redhat.com  Thu Feb  3 15:17:47 2022
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 03 Feb 2022 15:17:47 +0000
Subject: [nova][gate] test_tagged_attachment failing close to 100% in
 nova-next
In-Reply-To: <CACqyMic=UFcx-XZRT-LgyFX7m1cf_ocsuzCdZ_9R5K56H5_y0A@mail.gmail.com>
References: <CACqyMic=UFcx-XZRT-LgyFX7m1cf_ocsuzCdZ_9R5K56H5_y0A@mail.gmail.com>
Message-ID: <1220c065c4c56f121444d1333596083cd4bfa71f.camel@redhat.com>

On Thu, 2022-02-03 at 07:57 -0500, Artom Lifshitz wrote:
> https://bugs.launchpad.net/nova/+bug/1959899
> 
> The test times out verifying the tags in the metadata API after
> attaching a NIC and volume.
> 
> This is happening almost 100% of the time, but I've seen at least a
> couple of passing runs as well. We have yet to determine what the
> exact failure mode is - is the metadata API timing out (unlikely,
> since every other test passes)? Or are the expected tags just not
> present (more likely)?
we might want to add it to the exclude list for that job for now since we should have
testing without q35 for it in other jobs.
that will "unblock" the ci for now coming up to code freeze as we want to avoid soft blockign
the ci with lots fo rechecks.
> 
> I'm trying to figure some things out at [1], but other than that this
> is very much under investigation with no root cause identified yet.
> 
> [1] https://review.opendev.org/c/openstack/nova/+/827549
have you been able to repoduce it locally?
i know you tried addign some waits to the tempest change too i assuem that did not help?
we can technially call the metadata api form outside the vm so perhaps we should also have tempst
curl the nova metadata api direclty externally form the vm to assert taht its not in the metadata api
issue. in terms fo tags we might also want to have tempest do a blkid or lsblk to see if we can see the volume
is attached in the vm by looking at the serial. i think there are other tests that do that but before we assert the tag is in the metadata
api we shoudl ensrue the volume is present in the vm.
we are not currently doing that
https://github.com/openstack/tempest/blob/ad8f599b32e875c438bd49b8d81bfcd9d4eb8ead/tempest/api/compute/servers/test_device_tagging.py#L421

so hwere we shoudl wait for the volume to attach
https://github.com/openstack/tempest/blob/ad8f599b32e875c438bd49b8d81bfcd9d4eb8ead/tempest/api/compute/servers/test_device_tagging.py#L413
and then verify its attached in the vm with lsblk/blkid.


> 
> 



From anyrude10 at gmail.com  Thu Feb  3 13:15:02 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Thu, 3 Feb 2022 18:45:02 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
Message-ID: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>

Hi Team

I am trying to Provision Bare Metal Node from my tripleo Overcloud.
For this, while deploying the overcloud, I have followed the *"default
flat" *network approach specified in the below link
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning

Just to highlight the changes, I have defined the

*ironic-config.yaml*

parameter_defaults:
    ...
    ...
    IronicIPXEEnabled: true
    IronicInspectorSubnets:
    - ip_range: *172.23.3.100,172.23.3.150*
    IronicInspectorInterface: 'br-baremetal'

Also modified the file *~/templates/network-environment.yaml*

parameter_defaults:
  NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
  NeutronFlatNetworks: datacentre,baremetal

With this I have Followed all the steps of creating br-baremetal bridge on
controller, given in the link below:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy

  - type: ovs_bridge
     name: br-baremetal
     use_dhcp: false
     members:
     - type: interface
       name: nic3

Post Deployment, I have also create a flat network on "datacentre"
physical network and subnet having the range *172.23.3.200,172.23.3.240 *(as
suggested subnet is same as of inspector and range is different) and the
router

Also created a baremetal node and ran *"openstack baremetal node manage
bm1", *the state of which was a success.

Observation:

On executing  "openstack baremetal node *provide* bm1", the machine gets
power on and ideally it should take an IP from ironic inspector range and
PXE Boot.
But nothing of this sort happens and we see an IP from neutron range "
*172.23.3.239*" (attached the screenshot)

[image: image.png]

I have checked overcloud ironic inspector podman logs alongwith the tcpdump.
In tcpdump, I can only see dhcp discover request on br-baremetal and
nothing happens after that.

I have tried to explain my issue in detail, but I would be happy to share
more details in case still required.
Can someone please help in resolving my issue.

Regards
Anirudh Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/080f6cda/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/080f6cda/attachment-0001.png>

From katonalala at gmail.com  Thu Feb  3 17:40:22 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 3 Feb 2022 18:40:22 +0100
Subject: [neutron] Drivers meeting - Friday 4.2.2022 - cancelled
Message-ID: <CALg0jKnt7XCf0Yaxj0UgB+Bocupd7VVaZt=eOEWpNkjc6_4KJg@mail.gmail.com>

Hi Neutron Drivers!

Due to the lack of agenda, let's cancel tomorrow's drivers meeting.
See You on the meeting next week.

Lajos Katona (lajoskatona)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/5e4e5dbb/attachment.htm>

From rosmaita.fossdev at gmail.com  Thu Feb  3 17:58:14 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 3 Feb 2022 12:58:14 -0500
Subject: [cinder] new driver freeze & exceptions
In-Reply-To: <2243896ab8a6e4fb94e7d1616ac31c2fc2414164.camel@redhat.com>
References: <72ed9f96-7f1e-0d0c-63fd-aa3602d703b6@gmail.com>
 <82a1b19c-477c-2fd0-87d7-b1473ebf760c@gmail.com>
 <20220203101636.gdhddtqekki7qdc5@localhost>
 <2243896ab8a6e4fb94e7d1616ac31c2fc2414164.camel@redhat.com>
Message-ID: <60696922-826e-1879-a1ce-ad9d1e11d8b7@gmail.com>

On 2/3/22 10:06 AM, Sean Mooney wrote:
> On Thu, 2022-02-03 at 11:16 +0100, Gorka Eguileor wrote:
>> On 28/01, Brian Rosmaita wrote:
>>> Update:
>>>
>>> The NEC Storage V Series driver has merged.
>>>
>>> The Lightbits driver has three +2s.  The Lightbits os-brick connector it
>>> depends on has not yet merged, but has been actively revised to address
>>> comments.  I am extending the new driver freeze exception until 20:00
>>> Wednesday 2 February.
>>>
>>
>> Update:
>>
>> The Lightbits cinder driver and os-brick connector patches have merged
>> withing the freeze exception timeframe.
> we were just talking about this on the nova channel.
> for it to be usable in nova an os-brick release needs to be done
> https://github.com/openstack/os-brick/compare/5.1.0...master
> 
> so we need a 5.2.0 release based on b29f1529228bb7a16c2373f7bbf1cf862438aa23 i guess
> https://github.com/openstack/releases/blob/master/deliverables/yoga/os-brick.yaml
> 
> then that will allow this to be useable in the zuul jobs ectra.

We're planning to release yoga os-brick next Thursday (10 Feb).

> 
> 
>>
>>
>>>
>>> On 1/21/22 5:25 PM, Brian Rosmaita wrote:
>>>> Hello Argonauts,
>>>>
>>>> The new driver merge deadline passed at 20:00 UTC today.
>>>>
>>>> I'm extending the new driver merge deadline to Friday 28 January at
>>>> 20:00 UTC for two drivers:
>>>>
>>>> 1. Lightbits: It has both a cinder and os-brick patch, and I want the
>>>> team to have more time to look at the os-brick patch.? I think the
>>>> driver patch is close to ready; the developers have been quick to
>>>> respond to comments and make revisions.? Also, the third-party CI is
>>>> functioning and responding on patches.
>>>>   ? cinder: https://review.opendev.org/c/openstack/cinder/+/821602
>>>>   ? os-brick: https://review.opendev.org/c/openstack/os-brick/+/821603
>>>>
>>>> 2. NEC Storage V Series: the driver patch has one +2 and the third party
>>>> CI is functioning and responding on patches; I don't see any reason to
>>>> make this one wait for the Z release.
>>>>   ? https://review.opendev.org/c/openstack/cinder/+/815614
>>>>
>>>> Cinder core reviewers: please continue to review the above patches.
>>>>
>>>> With respect to the other proposed drivers:
>>>> - Pure Storage NVMe-RoCE: vendor decided to hold it for Z
>>>> - Dell EMC PowerStore NFS driver: vendor decided to hold it for Z
>>>> - HPE XP Storage FC & iSCSI: the code is very straightforward, but the
>>>> CI is not ready yet, so this will have to wait for Z
>>>> - YADRO Tatlin.UNIFIED driver: initial patch arrived yesterday (and has
>>>> a -1 from Zuul); the CI appears to be running, but the cinder team needs
>>>> to move on to reviewing os-brick and Yoga feature patches, so this will
>>>> have to wait for Z also
>>>>
>>>>
>>>> cheers,
>>>> brian
>>>
>>>
>>
>>
> 



From rosmaita.fossdev at gmail.com  Thu Feb  3 18:04:08 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 3 Feb 2022 13:04:08 -0500
Subject: [cinder][drivers] third-party CI compliance check
Message-ID: <a9526e40-14e6-f45e-fbb9-afc12c2f13de@gmail.com>

Hello Argonauts, particularly vendor driver maintainers,

This is a reminder that the third-party CI compliance check is imminent 
[0].  You can prevent any unpleasantness by checking now to verify that 
your CI is compliant.


[0] 
https://releases.openstack.org/yoga/schedule.html#cinder-3rd-party-ci-compliance-checkpoint
[1] 
https://docs.openstack.org/cinder/latest/drivers-all-about.html#driver-compliance


From kennelson11 at gmail.com  Thu Feb  3 18:35:26 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Thu, 3 Feb 2022 10:35:26 -0800
Subject: [PTG] April 2022 Team Signup
Message-ID: <CAJ6yrQhRki1KsuvC97pPtx8wfFP-EnPSigg8coeRjz-jk5+sSA@mail.gmail.com>

Hello Everyone!
Last week, we announced the next virtual PTG will be held virtually from
Monday, April 4th to Friday, April 8th, 2022. We will have the same
schedule set up available as last time with three windows of time spread
across the day to cover all timezones with breaks in between.

To signup your team, you must complete BOTH the survey[1] AND reserve time
in the ethercalc[2] by end of day March 11th.

We ask that the PTL/SIG Chair/Team lead sign up for time to have their
discussions with 3 rules/guidelines:

1. Cross project discussions (like SIGs or support project teams) should be
scheduled towards the start of the week so that any discussions that might
shape those of other teams happen first.
2. No team should sign up for more than 4 hours per UTC day to help keep
participants actively engaged.
3. No team should sign up for more than 16 hours across all time slots to
avoid burning out our contributors and to enable participation in multiple
teams discussions.

Again, you need to fill out BOTH the ethercalc AND the survey to complete
your team's sign up. If you have any issues with signing up your team, due
to conflict or otherwise,  please let me know! While we are trying to
empower you to make your own decisions as to when you meet and for how long
(after all, you know your needs and teams timezones better than we do), we
are here to help!

Once your team is signed up, please register[3]! And remind your team to
register! Registration is free, but it's important that you sign up to let
us know you'll be attending because that's how you'll receive event
details, passwords, and other relevant information about the PTG.

Continue to visit openinfra.dev/ptg for updates.

-Kendall (diablo_rojo)

[1] Team Survey:
https://openinfrafoundation.formstack.com/forms/april2022_vptg_survey
[2] Ethercalc Signup: https://ethercalc.openstack.org/7yxdas7suqnd
[3] PTG Registration: https://openinfra-ptg.eventbrite.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/1b654217/attachment.htm>

From admin at gibdev.ru  Thu Feb  3 18:41:30 2022
From: admin at gibdev.ru (admin at gibdev.ru)
Date: Thu, 3 Feb 2022 21:41:30 +0300
Subject: openstack swift and local path filename
Message-ID: <f6afa19b-4fc1-dc87-3342-54d51fb9b6d8@gibdev.ru>

I have installed openstack swift 2.25.2

object-server writes and serves local files from disk

It receives http requests from a proxy-server, for example:


http get: 
/sdb4/525/AUTH_xxxxxxxxxxxxxxxxxxxxxxxx/panda/2c34a941f581d848e2799e7a0956ea14f3cb27b0e516aef99a438fdaebbd7592


reads a file from disk:


/srv/node/sdb4/objects/525/346/835ee70dce07217d8e33147e0864f346/1643910916.71556.data


how can I calculate the path by which the file will be read by 
object-server?


thanks




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/2dc44c1a/attachment.htm>

From clay.gerrard at gmail.com  Thu Feb  3 18:58:28 2022
From: clay.gerrard at gmail.com (Clay Gerrard)
Date: Thu, 3 Feb 2022 12:58:28 -0600
Subject: openstack swift and local path filename
In-Reply-To: <f6afa19b-4fc1-dc87-3342-54d51fb9b6d8@gibdev.ru>
References: <f6afa19b-4fc1-dc87-3342-54d51fb9b6d8@gibdev.ru>
Message-ID: <CA+_JKzrA=O6B6KOi3SU=VZx-A4yQC9HhE5k_Z3gcasX+2Mz9nw@mail.gmail.com>

If you're just curious how swift works, the CLI tool `swift-get-nodes`
wraps up that translation/calculation pretty nicely

vagrant at saio:~$ swift stat -v test test | egrep -i "(timestamp|url)"
                   URL: http://saio:8080/v1/AUTH_test/test/test
           X-Timestamp: 1643914310.47773
vagrant at saio:~$ tail /var/log/syslog | grep "object-"
Feb  3 18:54:37 saio object-6020: STDERR: (6752) accepted ('127.0.0.1',
56050)
Feb  3 18:54:37 saio object-6020: 127.0.0.1 - - [03/Feb/2022:18:54:37
+0000] "HEAD /sdb2/40/AUTH_test/test/test" 200 8 "HEAD
http://saio:8080/v1/AUTH_test/test/test"
"tx1cc84ff96e4b40d18bdb0-0061fc24ed" "proxy-server 6480" 0.0006 "-" 6752 0
Feb  3 18:54:37 saio object-6020: STDERR: 127.0.0.1 - - [03/Feb/2022
18:54:37] "HEAD /sdb2/40/AUTH_test/test/test HTTP/1.1" 200 423 0.001149
(txn: tx1cc84ff96e4b40d18bdb0-0061fc24ed)
vagrant at saio:~$ swift-get-nodes /etc/swift/object.ring.gz AUTH_test test
test | grep /srv/node
such as "export DEVICE=/srv/node"
ssh 127.0.0.2 "ls -lah
${DEVICE:-/srv/node*}/sdb2/objects/40/35a/a161102fba1710ef912af194b8d4635a"
ssh 127.0.0.3 "ls -lah
${DEVICE:-/srv/node*}/sdb3/objects/40/35a/a161102fba1710ef912af194b8d4635a"
ssh 127.0.0.4 "ls -lah
${DEVICE:-/srv/node*}/sdb4/objects/40/35a/a161102fba1710ef912af194b8d4635a"
ssh 127.0.0.1 "ls -lah
${DEVICE:-/srv/node*}/sdb1/objects/40/35a/a161102fba1710ef912af194b8d4635a"
# [Handoff]
note: `/srv/node*` is used as default value of `devices`, the real value is
set in the config file on each storage node.
vagrant at saio:~$ ls
/srv/node2/sdb2/objects/40/35a/a161102fba1710ef912af194b8d4635a/
1643914310.47773.data

...  so you could look at how that does it:

https://github.com/openstack/swift/blob/master/swift/cli/info.py#L105

If you're doing something more sophisticated (maybe in the HPC space with
direct/non-proxy access) - checkout the "ListEndpoints" middleware:

https://docs.openstack.org/swift/latest/middleware.html#module-swift.common.middleware.list_endpoints

If you have some more questions, come say Hi in #openstack-swift on OFTC

On Thu, Feb 3, 2022 at 12:45 PM admin at gibdev.ru <admin at gibdev.ru> wrote:

> I have installed openstack swift 2.25.2
>
> object-server writes and serves local files from disk
>
> It receives http requests from a proxy-server, for example:
>
>
> http get:
> /sdb4/525/AUTH_xxxxxxxxxxxxxxxxxxxxxxxx/panda/2c34a941f581d848e2799e7a0956ea14f3cb27b0e516aef99a438fdaebbd7592
>
>
> reads a file from disk:
>
>
>
> /srv/node/sdb4/objects/525/346/835ee70dce07217d8e33147e0864f346/1643910916.71556.data
>
>
> how can I calculate the path by which the file will be read by
> object-server?
>
>
> thanks
>
>
>
>
>
>

-- 
Clay Gerrard
210 788 9431
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/035fcdf0/attachment-0001.htm>

From juliaashleykreger at gmail.com  Thu Feb  3 20:06:31 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Thu, 3 Feb 2022 12:06:31 -0800
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
Message-ID: <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>

My guess: You're running OVN. You need neutron-dhcp-agent running as well.
OVN disables it by default and OVN's integrated DHCP service does not
support options for network booting.

-Julia

On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta <anyrude10 at gmail.com> wrote:

> Hi Team
>
> I am trying to Provision Bare Metal Node from my tripleo Overcloud.
> For this, while deploying the overcloud, I have followed the *"default
> flat" *network approach specified in the below link
>
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>
> Just to highlight the changes, I have defined the
>
> *ironic-config.yaml*
>
> parameter_defaults:
>     ...
>     ...
>     IronicIPXEEnabled: true
>     IronicInspectorSubnets:
>     - ip_range: *172.23.3.100,172.23.3.150*
>     IronicInspectorInterface: 'br-baremetal'
>
> Also modified the file *~/templates/network-environment.yaml*
>
> parameter_defaults:
>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>   NeutronFlatNetworks: datacentre,baremetal
>
> With this I have Followed all the steps of creating br-baremetal bridge on
> controller, given in the link below:
>
>
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>
>   - type: ovs_bridge
>      name: br-baremetal
>      use_dhcp: false
>      members:
>      - type: interface
>        name: nic3
>
> Post Deployment, I have also create a flat network on "datacentre"
> physical network and subnet having the range *172.23.3.200,172.23.3.240 *(as
> suggested subnet is same as of inspector and range is different) and the
> router
>
> Also created a baremetal node and ran *"openstack baremetal node manage
> bm1", *the state of which was a success.
>
> Observation:
>
> On executing  "openstack baremetal node *provide* bm1", the machine gets
> power on and ideally it should take an IP from ironic inspector range and
> PXE Boot.
> But nothing of this sort happens and we see an IP from neutron range "
> *172.23.3.239*" (attached the screenshot)
>
> [image: image.png]
>
> I have checked overcloud ironic inspector podman logs alongwith the
> tcpdump.
> In tcpdump, I can only see dhcp discover request on br-baremetal and
> nothing happens after that.
>
> I have tried to explain my issue in detail, but I would be happy to share
> more details in case still required.
> Can someone please help in resolving my issue.
>
> Regards
> Anirudh Gupta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/c2b2989e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220203/c2b2989e/attachment-0001.png>

From mnaser at vexxhost.com  Fri Feb  4 13:59:31 2022
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Fri, 4 Feb 2022 08:59:31 -0500
Subject: Recently Upgraded to XENA and getting this error
In-Reply-To: <CA+ykd62inFqTuyj6yUkjXoCtab4Zy4P_XsdApeyA3nxxZdLc9g@mail.gmail.com>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <CAEs876iG0Ph4zToqbwC08JftTo4mKY2w8BKBncMN_ekKc3dQZA@mail.gmail.com>
 <CA+ykd62inFqTuyj6yUkjXoCtab4Zy4P_XsdApeyA3nxxZdLc9g@mail.gmail.com>
Message-ID: <CAEs876groLqbS4EDGUmDXY5_Fo8LQERG93bbXu-gqUFibnszRA@mail.gmail.com>

The fix hasn?t landed yet since then.

On Fri, Feb 4, 2022 at 8:38 AM Adivya Singh <adivya1.singh at gmail.com> wrote:

> hi Mohammed,
>
> This is for pike release, I am talking about Xena
>
> Regards
> Adivya Singh
>
> On Thu, Feb 3, 2022 at 4:37 AM Mohammed Naser <mnaser at vexxhost.com> wrote:
>
>> I think you're running into this which has been broken for a hot minute:
>>
>> https://review.opendev.org/c/openstack/horizon/+/808102
>>
>> that patch works for us locally.
>>
>> On Wed, Feb 2, 2022 at 10:37 AM Adivya Singh <adivya1.singh at gmail.com>
>> wrote:
>> >
>> > Hello,
>> >
>> > We have recently upgraded to XENA release of Openstack, and getting
>> this error while trying to Resize instance using GUI, it is telling "Danger
>> , Please try Later"
>> > Same is working properly from CLI without any issue
>> >
>> > Any thoughts on this
>> >
>> > Regards
>> > Adivya Singh
>>
>>
>>
>> --
>> Mohammed Naser
>> VEXXHOST, Inc.
>>
> --
Mohammed Naser
VEXXHOST, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/50d61af5/attachment.htm>

From hberaud at redhat.com  Fri Feb  4 14:24:09 2022
From: hberaud at redhat.com (Herve Beraud)
Date: Fri, 4 Feb 2022 15:24:09 +0100
Subject: [oslo] feature freeze - Feb 07 - Feb 11 (R-7)
Message-ID: <CAFDq9gWW8cXtJVt+PACT35C8_SUft1c4GwTopHgXjehjde7gBg@mail.gmail.com>

Hello Osloers,

Just a friendly reminder that oslo's feature freeze will happen next week
(R-7 - Feb 07 - Feb 11).
It's earlier than everyone else, and if you're wondering why, we have a
policy[1] that discusses it.

The main thing is that if you have features you want to get into Oslo
libraries this cycle, please make sure they merge by Friday. After that
we'll need to go through the FFE process and there's no guarantee we can
land them. Feel free to ping us on IRC if you need reviews.

Thanks for your attention.

[1] http://specs.openstack.org/openstack/oslo-specs/specs/policy/feature-
freeze.html
-- 
Herv? Beraud
Senior Software Engineer at Red Hat
irc: hberaud
https://github.com/4383/
https://twitter.com/4383hberaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/d8039003/attachment.htm>

From elod.illes at est.tech  Fri Feb  4 15:18:29 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Fri, 4 Feb 2022 16:18:29 +0100
Subject: [release] Release countdown for week R-7, Feb 07-11
Message-ID: <2d4c7835-89b4-ec6b-d7d2-15667696d440@est.tech>

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

We are entering the last weeks of the Yogadevelopment cycle. From
now until the final release, we'll send a countdown email like this
every week.

It's probably a good time for teams to take stock of their library and
client work that needs to be completed yet. The non-client library freeze
is coming up, followed closely by the client lib freeze. Please plan
accordingly to avoid any last minute rushes to get key functionality in.

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

Next week is the Extra-ATC freeze, in preparation for elections. All
contributions to OpenStack are valuable, but some are not expressed as
Gerrit code changes. Please list active contributors to your project team
who do not have a code contribution this cycle, and therefore won't
automatically be considered an Active Technical Contributor and allowed
to vote. This is done by adding extra-atcs to
https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml
before the Extra-ATC freeze on February 10th, 2022.

A quick reminder of the upcoming freeze dates. Those vary depending on
deliverable type:

* General libraries (except client libraries) need to have their last
feature release before Non-client library freeze (February 17th, 2022).
Their stable branches are cut early.

* Client libraries (think python-*client libraries) need to have their
last feature release before Client library freeze (February 24th, 2022)

* Deliverables following a cycle-with-rc model (that would be most
services) observe a Feature freeze on that same date, February 24th, 2022.
Any feature addition beyond that date should be discussed on the
mailing-list and get PTL approval. After feature freeze, cycle-with-rc
deliverables need to produce a first release candidate (and a stable
branch) before RC1 deadline (March 7th, 2022)

* Deliverables following cycle-with-intermediary model can release as
necessary, but in all cases before Final RC deadline (March 24th, 2022)

Finally, now is also a good time to start planning what highlights you
want for your deliverables in the cycle highlights. The deadline to
submit an initial version for those is set to Feature freeze (February 
24th, 2022).

Background on cycle-highlights:
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html
Project Team Guide, Cycle-Highlights:
https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights
knelson [at] openstack.org/diablo_rojo on IRC is available if you need
help selecting or writing your highlights

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

Extra-ATC freeze: February 10th, 2022(R-7 week)
Non-client library freeze: February 17th, 2022(R-6 week)
Client library freeze: February 24th, 2022(R-5 week)
Yoga-3 milestone: February 24th, 2022(R-5 week)
Yoga final release: March 30th, 2022
Next PTG: April 4 - 8, 2022 (virtual)



El?dIll?s
irc: elodilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/f9ea08fd/attachment-0001.htm>

From anyrude10 at gmail.com  Fri Feb  4 04:02:55 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Fri, 4 Feb 2022 09:32:55 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
Message-ID: <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>

Hi Julia,

Thanks for your response.
For the overcloud deployment, I am executing the following command:

openstack overcloud deploy --templates \
    -n /home/stack/templates/network_data.yaml \
    -r /home/stack/templates/roles_data.yaml \
    -e /home/stack/templates/node-info.yaml \
    -e /home/stack/templates/environment.yaml \
    -e /home/stack/templates/environments/network-isolation.yaml \
    -e /home/stack/templates/environments/network-environment.yaml \
    -e
/usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
\
    -e
/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
\
    -e
/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
\
    -e
/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
\
    -e /home/stack/templates/ironic-config.yaml \
    -e
/usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml
\
    -e /home/stack/containers-prepare-parameter.yaml

I can see some OVN related stuff in my roles_data and
environments/network-isolation.yaml

[stack at undercloud ~]$ grep -inr "ovn"
roles_data.yaml:34:    *OVNCMSOptions: "enable-chassis-as-gw"*
roles_data.yaml:168:    - *OS::TripleO::Services::OVNDBs*
roles_data.yaml:169:    - *OS::TripleO::Services::OVNController*
roles_data.yaml:279:    - *OS::TripleO::Services::OVNController*
roles_data.yaml:280:    - *OS::TripleO::Services::OVNMetadataAgent*
environments/network-isolation.yaml:16:
*OS::TripleO::Network::Ports::OVNDBsVipPort:
../network/ports/vip.yaml*

What is your recommendation and how to disable OVN....should I remove it
from roles_data.yaml and then render so that it doesn't get generated
in environments/network-isolation.yaml
Please suggest some pointers.

Regards
Anirudh Gupta






It seems OVN is getting installed in ironic


On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger <juliaashleykreger at gmail.com>
wrote:

> My guess: You're running OVN. You need neutron-dhcp-agent running as well.
> OVN disables it by default and OVN's integrated DHCP service does not
> support options for network booting.
>
> -Julia
>
> On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta <anyrude10 at gmail.com> wrote:
>
>> Hi Team
>>
>> I am trying to Provision Bare Metal Node from my tripleo Overcloud.
>> For this, while deploying the overcloud, I have followed the *"default
>> flat" *network approach specified in the below link
>>
>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>>
>> Just to highlight the changes, I have defined the
>>
>> *ironic-config.yaml*
>>
>> parameter_defaults:
>>     ...
>>     ...
>>     IronicIPXEEnabled: true
>>     IronicInspectorSubnets:
>>     - ip_range: *172.23.3.100,172.23.3.150*
>>     IronicInspectorInterface: 'br-baremetal'
>>
>> Also modified the file *~/templates/network-environment.yaml*
>>
>> parameter_defaults:
>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>   NeutronFlatNetworks: datacentre,baremetal
>>
>> With this I have Followed all the steps of creating br-baremetal bridge
>> on controller, given in the link below:
>>
>>
>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>>
>>   - type: ovs_bridge
>>      name: br-baremetal
>>      use_dhcp: false
>>      members:
>>      - type: interface
>>        name: nic3
>>
>> Post Deployment, I have also create a flat network on "datacentre"
>> physical network and subnet having the range *172.23.3.200,172.23.3.240 *(as
>> suggested subnet is same as of inspector and range is different) and the
>> router
>>
>> Also created a baremetal node and ran *"openstack baremetal node manage
>> bm1", *the state of which was a success.
>>
>> Observation:
>>
>> On executing  "openstack baremetal node *provide* bm1", the machine gets
>> power on and ideally it should take an IP from ironic inspector range and
>> PXE Boot.
>> But nothing of this sort happens and we see an IP from neutron range "
>> *172.23.3.239*" (attached the screenshot)
>>
>> [image: image.png]
>>
>> I have checked overcloud ironic inspector podman logs alongwith the
>> tcpdump.
>> In tcpdump, I can only see dhcp discover request on br-baremetal and
>> nothing happens after that.
>>
>> I have tried to explain my issue in detail, but I would be happy to share
>> more details in case still required.
>> Can someone please help in resolving my issue.
>>
>> Regards
>> Anirudh Gupta
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/ebf082e0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/ebf082e0/attachment-0001.png>

From juliaashleykreger at gmail.com  Fri Feb  4 13:09:58 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Fri, 4 Feb 2022 05:09:58 -0800
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
Message-ID: <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>

It is not a matter of disabling OVN, but a matter of enabling the dnsmasq
service and notifications.

https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
may provide some insight.

I suspect if you're using stable/wallaby based branches and it is not
working, there may need to be a patch backported by the TripleO maintainers.

On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta <anyrude10 at gmail.com> wrote:

> Hi Julia,
>
> Thanks for your response.
> For the overcloud deployment, I am executing the following command:
>
> openstack overcloud deploy --templates \
>     -n /home/stack/templates/network_data.yaml \
>     -r /home/stack/templates/roles_data.yaml \
>     -e /home/stack/templates/node-info.yaml \
>     -e /home/stack/templates/environment.yaml \
>     -e /home/stack/templates/environments/network-isolation.yaml \
>     -e /home/stack/templates/environments/network-environment.yaml \
>     -e
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
> \
>     -e
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
> \
>     -e
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
> \
>     -e
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
> \
>     -e /home/stack/templates/ironic-config.yaml \
>     -e
> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>     -e
> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>     -e /home/stack/containers-prepare-parameter.yaml
>
> I can see some OVN related stuff in my roles_data and
> environments/network-isolation.yaml
>
> [stack at undercloud ~]$ grep -inr "ovn"
> roles_data.yaml:34:    *OVNCMSOptions: "enable-chassis-as-gw"*
> roles_data.yaml:168:    - *OS::TripleO::Services::OVNDBs*
> roles_data.yaml:169:    - *OS::TripleO::Services::OVNController*
> roles_data.yaml:279:    - *OS::TripleO::Services::OVNController*
> roles_data.yaml:280:    - *OS::TripleO::Services::OVNMetadataAgent*
> environments/network-isolation.yaml:16:  *OS::TripleO::Network::Ports::OVNDBsVipPort:
> ../network/ports/vip.yaml*
>
> What is your recommendation and how to disable OVN....should I remove it
> from roles_data.yaml and then render so that it doesn't get generated
> in environments/network-isolation.yaml
> Please suggest some pointers.
>
> Regards
> Anirudh Gupta
>
>
>
>
>
>
> It seems OVN is getting installed in ironic
>
>
> On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger <juliaashleykreger at gmail.com>
> wrote:
>
>> My guess: You're running OVN. You need neutron-dhcp-agent running as
>> well. OVN disables it by default and OVN's integrated DHCP service does not
>> support options for network booting.
>>
>> -Julia
>>
>> On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta <anyrude10 at gmail.com> wrote:
>>
>>> Hi Team
>>>
>>> I am trying to Provision Bare Metal Node from my tripleo Overcloud.
>>> For this, while deploying the overcloud, I have followed the *"default
>>> flat" *network approach specified in the below link
>>>
>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>>>
>>> Just to highlight the changes, I have defined the
>>>
>>> *ironic-config.yaml*
>>>
>>> parameter_defaults:
>>>     ...
>>>     ...
>>>     IronicIPXEEnabled: true
>>>     IronicInspectorSubnets:
>>>     - ip_range: *172.23.3.100,172.23.3.150*
>>>     IronicInspectorInterface: 'br-baremetal'
>>>
>>> Also modified the file *~/templates/network-environment.yaml*
>>>
>>> parameter_defaults:
>>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>>   NeutronFlatNetworks: datacentre,baremetal
>>>
>>> With this I have Followed all the steps of creating br-baremetal bridge
>>> on controller, given in the link below:
>>>
>>>
>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>>>
>>>   - type: ovs_bridge
>>>      name: br-baremetal
>>>      use_dhcp: false
>>>      members:
>>>      - type: interface
>>>        name: nic3
>>>
>>> Post Deployment, I have also create a flat network on "datacentre"
>>> physical network and subnet having the range *172.23.3.200,172.23.3.240
>>> *(as suggested subnet is same as of inspector and range is different)
>>> and the router
>>>
>>> Also created a baremetal node and ran *"openstack baremetal node manage
>>> bm1", *the state of which was a success.
>>>
>>> Observation:
>>>
>>> On executing  "openstack baremetal node *provide* bm1", the machine
>>> gets power on and ideally it should take an IP from ironic inspector range
>>> and PXE Boot.
>>> But nothing of this sort happens and we see an IP from neutron range "
>>> *172.23.3.239*" (attached the screenshot)
>>>
>>> [image: image.png]
>>>
>>> I have checked overcloud ironic inspector podman logs alongwith the
>>> tcpdump.
>>> In tcpdump, I can only see dhcp discover request on br-baremetal and
>>> nothing happens after that.
>>>
>>> I have tried to explain my issue in detail, but I would be happy to
>>> share more details in case still required.
>>> Can someone please help in resolving my issue.
>>>
>>> Regards
>>> Anirudh Gupta
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/8ac40b8e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/8ac40b8e/attachment-0001.png>

From cbouchar at redhat.com  Fri Feb  4 13:38:36 2022
From: cbouchar at redhat.com (Carol Bouchard)
Date: Fri, 4 Feb 2022 08:38:36 -0500
Subject: [ironic]Anaconda deploy interface config
Message-ID: <CACkzpE4A11he8EDmF-tDVOb2ZMR0FnaHogpBOq9EpWdYZ36ahg@mail.gmail.com>

Ironic folks:

I'm trying to spawn a RHEL7 image using a kickstart file and having issues
with stage2 file.
First I used bifrost to initially setup a couple of VMs.  (There is no
openstack/glance).
I'm now using one of those VMs to boot up with RHEL7. I changed the VM
config
with the following:

*| deploy_interface       | anaconda*
* | instance_info          | {'kernel': 'http://myip:8080/RHEL7/vmlinuz
<http://myip:8080/RHEL7/vmlinuz>', 'ramdisk':
'http://myip:8080/RHEL7/initrd.img <http://myip:8080/RHEL7/initrd.img>',
'image_source': 'http://myip:8080/RHEL7/initrd.img
<http://myip:8080/RHEL7/initrd.img>', 'stage2':
'http://myip:8080/RHEL7/squashfs.img
<http://myip:8080/RHEL7/squashfs.img>', 'ks_cfg':
'http://myip:8080/RHEL7/ks.cfg.template
<http://myip:8080/RHEL7/ks.cfg.template>', 'ks_template':
'http://myip:8080/RHEL7/ks.cfg.template
<http://myip:8080/RHEL7/ks.cfg.template>'}*

ironic.conf changes I made are as follows:

*enabled_deploy_interfaces = direct,ramdisk,anaconda*

*[anaconda]default_ks_template = file:///etc/ironic/ks.cfg.template*

The error I'm getting is as follows:
 *$ baremetal node show testvm1 --field last_error*

*| last_error | Deploy step deploy.deploy failed with IsADirectoryError:
[Errno 21] Is a directory:
'/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'.*
Tail end of traceback is as follows:








* ironic-conductor[]:   ERROR ironic.conductor.utils   File
"/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/common/pxe_utils.py",
line 1245, in cache_ramdisk_kernel ironic-conductor[]:   ERROR
ironic.conductor.utils     deploy_utils.fetch_images(ctx, TFTPImageCache(),
list(t_pxe_info.values()), ironic-conductor[]:   ERROR
ironic.conductor.utils   File
"/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/deploy_utils.py",
line 240, in fetch_images ironic-conductor[]:   ERROR
ironic.conductor.utils     cache.fetch_image(href, path, ctx=ctx,
force_raw=force_raw) ironic-conductor[]:   ERROR ironic.conductor.utils
File
"/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py",
line 120, in fetch_image ironic-conductor[]:   ERROR ironic.conductor.utils
    dest_up_to_date =
_delete_dest_path_if_stale(master_path, ironic-conductor[]:   ERROR
ironic.conductor.utils   File
"/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py",
line 460, in _delete_dest_path_if_stale ironic-conductor[]:   ERROR
ironic.conductor.utils     os.unlink(dest_path) ironic-conductor[]:   ERROR
ironic.conductor.utils IsADirectoryError: [Errno 21] Is a directory:
'/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'*

Please advise.

Carol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/4cec7f13/attachment-0001.htm>

From anyrude10 at gmail.com  Fri Feb  4 13:50:02 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Fri, 4 Feb 2022 19:20:02 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
Message-ID: <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>

Hi Julia

Thanks for your response.

Earlier I was passing both ironic.yaml and ironic-overcloud.yaml located at
path /usr/share/openstack-tripleo-heat-templates/environments/services/

My current understanding now says that since I am using OVN, not OVS so I
should pass only ironic-overcloud.yaml in my deployment.

I am currently on Train Release and my default ironic-overcloud.yaml file
has no such entry
DhcpAgentNotification: true

I would add this there and re deploy the setup.

Would that be enough to make my deployment successful?

Regards
Anirudh Gupta


On Fri, 4 Feb, 2022, 18:40 Julia Kreger, <juliaashleykreger at gmail.com>
wrote:

> It is not a matter of disabling OVN, but a matter of enabling the dnsmasq
> service and notifications.
>
>
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
> may provide some insight.
>
> I suspect if you're using stable/wallaby based branches and it is not
> working, there may need to be a patch backported by the TripleO maintainers.
>
> On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta <anyrude10 at gmail.com> wrote:
>
>> Hi Julia,
>>
>> Thanks for your response.
>> For the overcloud deployment, I am executing the following command:
>>
>> openstack overcloud deploy --templates \
>>     -n /home/stack/templates/network_data.yaml \
>>     -r /home/stack/templates/roles_data.yaml \
>>     -e /home/stack/templates/node-info.yaml \
>>     -e /home/stack/templates/environment.yaml \
>>     -e /home/stack/templates/environments/network-isolation.yaml \
>>     -e /home/stack/templates/environments/network-environment.yaml \
>>     -e
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
>> \
>>     -e
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>> \
>>     -e
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>> \
>>     -e
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>> \
>>     -e /home/stack/templates/ironic-config.yaml \
>>     -e
>> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>>     -e
>> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>>     -e /home/stack/containers-prepare-parameter.yaml
>>
>> I can see some OVN related stuff in my roles_data and
>> environments/network-isolation.yaml
>>
>> [stack at undercloud ~]$ grep -inr "ovn"
>> roles_data.yaml:34:    *OVNCMSOptions: "enable-chassis-as-gw"*
>> roles_data.yaml:168:    - *OS::TripleO::Services::OVNDBs*
>> roles_data.yaml:169:    - *OS::TripleO::Services::OVNController*
>> roles_data.yaml:279:    - *OS::TripleO::Services::OVNController*
>> roles_data.yaml:280:    - *OS::TripleO::Services::OVNMetadataAgent*
>> environments/network-isolation.yaml:16:  *OS::TripleO::Network::Ports::OVNDBsVipPort:
>> ../network/ports/vip.yaml*
>>
>> What is your recommendation and how to disable OVN....should I remove it
>> from roles_data.yaml and then render so that it doesn't get generated
>> in environments/network-isolation.yaml
>> Please suggest some pointers.
>>
>> Regards
>> Anirudh Gupta
>>
>>
>>
>>
>>
>>
>> It seems OVN is getting installed in ironic
>>
>>
>> On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger <juliaashleykreger at gmail.com>
>> wrote:
>>
>>> My guess: You're running OVN. You need neutron-dhcp-agent running as
>>> well. OVN disables it by default and OVN's integrated DHCP service does not
>>> support options for network booting.
>>>
>>> -Julia
>>>
>>> On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta <anyrude10 at gmail.com>
>>> wrote:
>>>
>>>> Hi Team
>>>>
>>>> I am trying to Provision Bare Metal Node from my tripleo Overcloud.
>>>> For this, while deploying the overcloud, I have followed the *"default
>>>> flat" *network approach specified in the below link
>>>>
>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>>>>
>>>> Just to highlight the changes, I have defined the
>>>>
>>>> *ironic-config.yaml*
>>>>
>>>> parameter_defaults:
>>>>     ...
>>>>     ...
>>>>     IronicIPXEEnabled: true
>>>>     IronicInspectorSubnets:
>>>>     - ip_range: *172.23.3.100,172.23.3.150*
>>>>     IronicInspectorInterface: 'br-baremetal'
>>>>
>>>> Also modified the file *~/templates/network-environment.yaml*
>>>>
>>>> parameter_defaults:
>>>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>>>   NeutronFlatNetworks: datacentre,baremetal
>>>>
>>>> With this I have Followed all the steps of creating br-baremetal bridge
>>>> on controller, given in the link below:
>>>>
>>>>
>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>>>>
>>>>   - type: ovs_bridge
>>>>      name: br-baremetal
>>>>      use_dhcp: false
>>>>      members:
>>>>      - type: interface
>>>>        name: nic3
>>>>
>>>> Post Deployment, I have also create a flat network on "datacentre"
>>>> physical network and subnet having the range *172.23.3.200,172.23.3.240
>>>> *(as suggested subnet is same as of inspector and range is different)
>>>> and the router
>>>>
>>>> Also created a baremetal node and ran *"openstack baremetal node
>>>> manage bm1", *the state of which was a success.
>>>>
>>>> Observation:
>>>>
>>>> On executing  "openstack baremetal node *provide* bm1", the machine
>>>> gets power on and ideally it should take an IP from ironic inspector range
>>>> and PXE Boot.
>>>> But nothing of this sort happens and we see an IP from neutron range "
>>>> *172.23.3.239*" (attached the screenshot)
>>>>
>>>> [image: image.png]
>>>>
>>>> I have checked overcloud ironic inspector podman logs alongwith the
>>>> tcpdump.
>>>> In tcpdump, I can only see dhcp discover request on br-baremetal and
>>>> nothing happens after that.
>>>>
>>>> I have tried to explain my issue in detail, but I would be happy to
>>>> share more details in case still required.
>>>> Can someone please help in resolving my issue.
>>>>
>>>> Regards
>>>> Anirudh Gupta
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/3d69ed88/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/3d69ed88/attachment-0001.png>

From juliaashleykreger at gmail.com  Fri Feb  4 14:59:18 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Fri, 4 Feb 2022 06:59:18 -0800
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
Message-ID: <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>

On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta <anyrude10 at gmail.com> wrote:

> Hi Julia
>
> Thanks for your response.
>
> Earlier I was passing both ironic.yaml and ironic-overcloud.yaml located
> at path /usr/share/openstack-tripleo-heat-templates/environments/services/
>
> My current understanding now says that since I am using OVN, not OVS so I
> should pass only ironic-overcloud.yaml in my deployment.
>
> I am currently on Train Release and my default ironic-overcloud.yaml file
> has no such entry
> DhcpAgentNotification: true
>
>
I suspect that should work. Let us know if it does.



> I would add this there and re deploy the setup.
>
> Would that be enough to make my deployment successful?
>
> Regards
> Anirudh Gupta
>
>
> On Fri, 4 Feb, 2022, 18:40 Julia Kreger, <juliaashleykreger at gmail.com>
> wrote:
>
>> It is not a matter of disabling OVN, but a matter of enabling the dnsmasq
>> service and notifications.
>>
>>
>> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
>> may provide some insight.
>>
>> I suspect if you're using stable/wallaby based branches and it is not
>> working, there may need to be a patch backported by the TripleO maintainers.
>>
>> On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta <anyrude10 at gmail.com> wrote:
>>
>>> Hi Julia,
>>>
>>> Thanks for your response.
>>> For the overcloud deployment, I am executing the following command:
>>>
>>> openstack overcloud deploy --templates \
>>>     -n /home/stack/templates/network_data.yaml \
>>>     -r /home/stack/templates/roles_data.yaml \
>>>     -e /home/stack/templates/node-info.yaml \
>>>     -e /home/stack/templates/environment.yaml \
>>>     -e /home/stack/templates/environments/network-isolation.yaml \
>>>     -e /home/stack/templates/environments/network-environment.yaml \
>>>     -e
>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
>>> \
>>>     -e
>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>>> \
>>>     -e
>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>>> \
>>>     -e
>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>>> \
>>>     -e /home/stack/templates/ironic-config.yaml \
>>>     -e
>>> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>>>     -e
>>> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>>>     -e /home/stack/containers-prepare-parameter.yaml
>>>
>>> I can see some OVN related stuff in my roles_data and
>>> environments/network-isolation.yaml
>>>
>>> [stack at undercloud ~]$ grep -inr "ovn"
>>> roles_data.yaml:34:    *OVNCMSOptions: "enable-chassis-as-gw"*
>>> roles_data.yaml:168:    - *OS::TripleO::Services::OVNDBs*
>>> roles_data.yaml:169:    - *OS::TripleO::Services::OVNController*
>>> roles_data.yaml:279:    - *OS::TripleO::Services::OVNController*
>>> roles_data.yaml:280:    - *OS::TripleO::Services::OVNMetadataAgent*
>>> environments/network-isolation.yaml:16:  *OS::TripleO::Network::Ports::OVNDBsVipPort:
>>> ../network/ports/vip.yaml*
>>>
>>> What is your recommendation and how to disable OVN....should I remove it
>>> from roles_data.yaml and then render so that it doesn't get generated
>>> in environments/network-isolation.yaml
>>> Please suggest some pointers.
>>>
>>> Regards
>>> Anirudh Gupta
>>>
>>>
>>>
>>>
>>>
>>>
>>> It seems OVN is getting installed in ironic
>>>
>>>
>>> On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger <juliaashleykreger at gmail.com>
>>> wrote:
>>>
>>>> My guess: You're running OVN. You need neutron-dhcp-agent running as
>>>> well. OVN disables it by default and OVN's integrated DHCP service does not
>>>> support options for network booting.
>>>>
>>>> -Julia
>>>>
>>>> On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta <anyrude10 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Team
>>>>>
>>>>> I am trying to Provision Bare Metal Node from my tripleo Overcloud.
>>>>> For this, while deploying the overcloud, I have followed the *"default
>>>>> flat" *network approach specified in the below link
>>>>>
>>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>>>>>
>>>>> Just to highlight the changes, I have defined the
>>>>>
>>>>> *ironic-config.yaml*
>>>>>
>>>>> parameter_defaults:
>>>>>     ...
>>>>>     ...
>>>>>     IronicIPXEEnabled: true
>>>>>     IronicInspectorSubnets:
>>>>>     - ip_range: *172.23.3.100,172.23.3.150*
>>>>>     IronicInspectorInterface: 'br-baremetal'
>>>>>
>>>>> Also modified the file *~/templates/network-environment.yaml*
>>>>>
>>>>> parameter_defaults:
>>>>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>>>>   NeutronFlatNetworks: datacentre,baremetal
>>>>>
>>>>> With this I have Followed all the steps of creating br-baremetal
>>>>> bridge on controller, given in the link below:
>>>>>
>>>>>
>>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>>>>>
>>>>>   - type: ovs_bridge
>>>>>      name: br-baremetal
>>>>>      use_dhcp: false
>>>>>      members:
>>>>>      - type: interface
>>>>>        name: nic3
>>>>>
>>>>> Post Deployment, I have also create a flat network on "datacentre"
>>>>> physical network and subnet having the range *172.23.3.200,172.23.3.240
>>>>> *(as suggested subnet is same as of inspector and range is different)
>>>>> and the router
>>>>>
>>>>> Also created a baremetal node and ran *"openstack baremetal node
>>>>> manage bm1", *the state of which was a success.
>>>>>
>>>>> Observation:
>>>>>
>>>>> On executing  "openstack baremetal node *provide* bm1", the machine
>>>>> gets power on and ideally it should take an IP from ironic inspector range
>>>>> and PXE Boot.
>>>>> But nothing of this sort happens and we see an IP from neutron range "
>>>>> *172.23.3.239*" (attached the screenshot)
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> I have checked overcloud ironic inspector podman logs alongwith the
>>>>> tcpdump.
>>>>> In tcpdump, I can only see dhcp discover request on br-baremetal and
>>>>> nothing happens after that.
>>>>>
>>>>> I have tried to explain my issue in detail, but I would be happy to
>>>>> share more details in case still required.
>>>>> Can someone please help in resolving my issue.
>>>>>
>>>>> Regards
>>>>> Anirudh Gupta
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/5e661874/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/5e661874/attachment-0001.png>

From anyrude10 at gmail.com  Fri Feb  4 15:24:14 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Fri, 4 Feb 2022 20:54:14 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
Message-ID: <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>

Hi,

Surely I'll revert the status once it gets deployed.
Bdw the suspicion is because of Train Release or it is something else?

Regards
Anirudh Gupta

On Fri, 4 Feb, 2022, 20:29 Julia Kreger, <juliaashleykreger at gmail.com>
wrote:

>
>
> On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta <anyrude10 at gmail.com> wrote:
>
>> Hi Julia
>>
>> Thanks for your response.
>>
>> Earlier I was passing both ironic.yaml and ironic-overcloud.yaml located
>> at path /usr/share/openstack-tripleo-heat-templates/environments/services/
>>
>> My current understanding now says that since I am using OVN, not OVS so I
>> should pass only ironic-overcloud.yaml in my deployment.
>>
>> I am currently on Train Release and my default ironic-overcloud.yaml file
>> has no such entry
>> DhcpAgentNotification: true
>>
>>
> I suspect that should work. Let us know if it does.
>
>
>
>> I would add this there and re deploy the setup.
>>
>> Would that be enough to make my deployment successful?
>>
>> Regards
>> Anirudh Gupta
>>
>>
>> On Fri, 4 Feb, 2022, 18:40 Julia Kreger, <juliaashleykreger at gmail.com>
>> wrote:
>>
>>> It is not a matter of disabling OVN, but a matter of enabling the
>>> dnsmasq service and notifications.
>>>
>>>
>>> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
>>> may provide some insight.
>>>
>>> I suspect if you're using stable/wallaby based branches and it is not
>>> working, there may need to be a patch backported by the TripleO maintainers.
>>>
>>> On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta <anyrude10 at gmail.com>
>>> wrote:
>>>
>>>> Hi Julia,
>>>>
>>>> Thanks for your response.
>>>> For the overcloud deployment, I am executing the following command:
>>>>
>>>> openstack overcloud deploy --templates \
>>>>     -n /home/stack/templates/network_data.yaml \
>>>>     -r /home/stack/templates/roles_data.yaml \
>>>>     -e /home/stack/templates/node-info.yaml \
>>>>     -e /home/stack/templates/environment.yaml \
>>>>     -e /home/stack/templates/environments/network-isolation.yaml \
>>>>     -e /home/stack/templates/environments/network-environment.yaml \
>>>>     -e
>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
>>>> \
>>>>     -e
>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>>>> \
>>>>     -e
>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>>>> \
>>>>     -e
>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>>>> \
>>>>     -e /home/stack/templates/ironic-config.yaml \
>>>>     -e
>>>> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>>>>     -e
>>>> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>>>>     -e /home/stack/containers-prepare-parameter.yaml
>>>>
>>>> I can see some OVN related stuff in my roles_data and
>>>> environments/network-isolation.yaml
>>>>
>>>> [stack at undercloud ~]$ grep -inr "ovn"
>>>> roles_data.yaml:34:    *OVNCMSOptions: "enable-chassis-as-gw"*
>>>> roles_data.yaml:168:    - *OS::TripleO::Services::OVNDBs*
>>>> roles_data.yaml:169:    - *OS::TripleO::Services::OVNController*
>>>> roles_data.yaml:279:    - *OS::TripleO::Services::OVNController*
>>>> roles_data.yaml:280:    - *OS::TripleO::Services::OVNMetadataAgent*
>>>> environments/network-isolation.yaml:16:  *OS::TripleO::Network::Ports::OVNDBsVipPort:
>>>> ../network/ports/vip.yaml*
>>>>
>>>> What is your recommendation and how to disable OVN....should I remove
>>>> it from roles_data.yaml and then render so that it doesn't get generated
>>>> in environments/network-isolation.yaml
>>>> Please suggest some pointers.
>>>>
>>>> Regards
>>>> Anirudh Gupta
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It seems OVN is getting installed in ironic
>>>>
>>>>
>>>> On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger <
>>>> juliaashleykreger at gmail.com> wrote:
>>>>
>>>>> My guess: You're running OVN. You need neutron-dhcp-agent running as
>>>>> well. OVN disables it by default and OVN's integrated DHCP service does not
>>>>> support options for network booting.
>>>>>
>>>>> -Julia
>>>>>
>>>>> On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta <anyrude10 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Team
>>>>>>
>>>>>> I am trying to Provision Bare Metal Node from my tripleo Overcloud.
>>>>>> For this, while deploying the overcloud, I have followed the *"default
>>>>>> flat" *network approach specified in the below link
>>>>>>
>>>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>>>>>>
>>>>>> Just to highlight the changes, I have defined the
>>>>>>
>>>>>> *ironic-config.yaml*
>>>>>>
>>>>>> parameter_defaults:
>>>>>>     ...
>>>>>>     ...
>>>>>>     IronicIPXEEnabled: true
>>>>>>     IronicInspectorSubnets:
>>>>>>     - ip_range: *172.23.3.100,172.23.3.150*
>>>>>>     IronicInspectorInterface: 'br-baremetal'
>>>>>>
>>>>>> Also modified the file *~/templates/network-environment.yaml*
>>>>>>
>>>>>> parameter_defaults:
>>>>>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>>>>>   NeutronFlatNetworks: datacentre,baremetal
>>>>>>
>>>>>> With this I have Followed all the steps of creating br-baremetal
>>>>>> bridge on controller, given in the link below:
>>>>>>
>>>>>>
>>>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>>>>>>
>>>>>>   - type: ovs_bridge
>>>>>>      name: br-baremetal
>>>>>>      use_dhcp: false
>>>>>>      members:
>>>>>>      - type: interface
>>>>>>        name: nic3
>>>>>>
>>>>>> Post Deployment, I have also create a flat network on "datacentre"
>>>>>> physical network and subnet having the range *172.23.3.200,172.23.3.240
>>>>>> *(as suggested subnet is same as of inspector and range is
>>>>>> different) and the router
>>>>>>
>>>>>> Also created a baremetal node and ran *"openstack baremetal node
>>>>>> manage bm1", *the state of which was a success.
>>>>>>
>>>>>> Observation:
>>>>>>
>>>>>> On executing  "openstack baremetal node *provide* bm1", the machine
>>>>>> gets power on and ideally it should take an IP from ironic inspector range
>>>>>> and PXE Boot.
>>>>>> But nothing of this sort happens and we see an IP from neutron range "
>>>>>> *172.23.3.239*" (attached the screenshot)
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> I have checked overcloud ironic inspector podman logs alongwith the
>>>>>> tcpdump.
>>>>>> In tcpdump, I can only see dhcp discover request on br-baremetal and
>>>>>> nothing happens after that.
>>>>>>
>>>>>> I have tried to explain my issue in detail, but I would be happy to
>>>>>> share more details in case still required.
>>>>>> Can someone please help in resolving my issue.
>>>>>>
>>>>>> Regards
>>>>>> Anirudh Gupta
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/1da01b5f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/1da01b5f/attachment-0001.png>

From franck.vedel at univ-grenoble-alpes.fr  Fri Feb  4 16:47:10 2022
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Fri, 4 Feb 2022 17:47:10 +0100
Subject: [kolla-ansible][mariadb]error (galera cluster problem ?)
Message-ID: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr>

Hello,
I am in an emergency situation, quite catastrophic situation because I do not know what to do.

I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was doing so well?


A network admin came to me and told me to change an MTU on the cards. I knew it shouldn't be done...I shouldn't have done it.
I did it.
Of course, it didn't work as expected. I went back to my starting configuration and there I have a big problem with mariadb which is set up on serv1 and serv2.

Here are my errors:


2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
	 at gcomm/src/pc.cpp:connect():160
2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out)
2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': -110 (Connection timed out)
2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed out
2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567) failed: 7
2022-02-04 17:40:36 0 [ERROR] Aborting




I do not know what to do. My installation is done with kolla-ansible, mariadb docker restarts every 30 seconds.

Can the "kolla-ansible reconfigure mariadb" command be a solution?
Could the command "kolla-ansible mariadb recovery" be a solution?

Thanks in advance if you can help me.



Franck


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/fba1af77/attachment.htm>

From laurentfdumont at gmail.com  Fri Feb  4 22:12:55 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Fri, 4 Feb 2022 17:12:55 -0500
Subject: [kolla-ansible][mariadb]error (galera cluster problem ?)
In-Reply-To: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr>
References: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr>
Message-ID: <CAOAKi8wQ=MafWcRwh1duyuoGtF07j+ctQBma3vG25WTKCs8yYA@mail.gmail.com>

   - What was the starting value for MTU?
   - What was the starting value changed to for MTU?
   - Can ping between all your controllers?
   - Do you just have two controllers running mariadb?
   - How did you change MTU?
   - Was the change reverted at the network level as well (switches need to
   be configured higher or at the same MTU value then the servers)

4567 seems to be the port for galera (clustering for mariadb)

On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL <
franck.vedel at univ-grenoble-alpes.fr> wrote:

> Hello,
> I am in an emergency situation, quite catastrophic situation because I do
> not know what to do.
>
> I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was
> doing so well?
>
>
> A network admin came to me and told me to change an MTU on the cards. I
> knew it shouldn't be done...I shouldn't have done it.
> I did it.
> Of course, it didn't work as expected. I went back to my starting
> configuration and there I have a big problem with mariadb which is set up
> on serv1 and serv2.
>
> Here are my errors:
>
>
> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend
> connection: 110: failed to reach primary view: 110 (Connection timed out)
>  at gcomm/src/pc.cpp:connect():160
> 2022-02-04 17:40:36 0 [ERROR] WSREP:
> gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend
> connection: -110 (Connection timed out)
> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475:
> Failed to open channel 'openstack' at '
> gcomm://10.0.5.109:4567,10.0.5.110:4567': -110 (Connection timed out)
> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed
> out
> 2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(
> gcomm://10.0.5.109:4567,10.0.5.110:4567) failed: 7
> 2022-02-04 17:40:36 0 [ERROR] Aborting
>
>
>
>
> I do not know what to do. My installation is done with kolla-ansible,
> mariadb docker restarts every 30 seconds.
>
> Can the "kolla-ansible reconfigure mariadb" command be a solution?
> Could the command "kolla-ansible mariadb recovery" be a solution?
>
> Thanks in advance if you can help me.
>
>
>
> Franck
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220204/914d16dd/attachment.htm>

From johnsomor at gmail.com  Fri Feb  4 23:39:21 2022
From: johnsomor at gmail.com (Michael Johnson)
Date: Fri, 4 Feb 2022 15:39:21 -0800
Subject: [designate] Tentative PTG time slots for Designate
Message-ID: <CAMH0Mg+0eMwZeVaPREa9dYtodA1gKWTQiGUhZ58PJhvNQQHeQg@mail.gmail.com>

Hello Designate community,

I have tentatively put Designate down for two time slots for the PTG.

Tuesday April 5th 15:00 - 17:00 UTC
Wednesday April 6th 15:00-17:00 UTC

Please let me know if those times do not work for you and you would
like to attend.

Michael


From franck.vedel at univ-grenoble-alpes.fr  Sat Feb  5 06:50:47 2022
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Sat, 5 Feb 2022 07:50:47 +0100
Subject: [kolla-ansible][mariadb]error (galera cluster problem ?)
In-Reply-To: <CAOAKi8wQ=MafWcRwh1duyuoGtF07j+ctQBma3vG25WTKCs8yYA@mail.gmail.com>
References: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr>
 <CAOAKi8wQ=MafWcRwh1duyuoGtF07j+ctQBma3vG25WTKCs8yYA@mail.gmail.com>
Message-ID: <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr>

Thanks for your help.


> What was the starting value for MTU?
1500
> What was the starting value changed to for MTU?
9000
> Can ping between all your controllers?
yes, all container starts except nova-conductor, nova-scheduler, maraidb


> Do you just have two controllers running mariadb?
yes
> How did you change MTU?

On the 3 servers:
nmcli connection modify team0-port1 802-3-ethernet.mtu 9000
nmcli connection modify team1-port2 802-3-ethernet.mtu 9000
nmcli connection modify type team0 team.runner lack ethernet.mtu 9000
nmcli con down team0
nmcli con down team1


> Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)
I didn?t change Mtu on network (switches) , but ping -s 10.0.5.117 (iscsi bay) was working from serv3.

I changed the value of the mtu because the creation of the volumes takes a lot of time I find (4 minutes for 20G, which is too long for what I want to do, the patience of the students decreases with the years)

Franck

> Le 4 f?vr. 2022 ? 23:12, Laurent Dumont <laurentfdumont at gmail.com> a ?crit :
> 
> What was the starting value for MTU?
> What was the starting value changed to for MTU?
> Can ping between all your controllers?
> Do you just have two controllers running mariadb?
> How did you change MTU?
> Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)
> 4567 seems to be the port for galera (clustering for mariadb) <>
> On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
> Hello,
> I am in an emergency situation, quite catastrophic situation because I do not know what to do.
> 
> I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was doing so well?
> 
> 
> A network admin came to me and told me to change an MTU on the cards. I knew it shouldn't be done...I shouldn't have done it.
> I did it.
> Of course, it didn't work as expected. I went back to my starting configuration and there I have a big problem with mariadb which is set up on serv1 and serv2.
> 
> Here are my errors:
> 
> 
> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
> 	 at gcomm/src/pc.cpp:connect():160
> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out)
> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': <> -110 (Connection timed out)
> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed out
> 2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567 <>) failed: 7
> 2022-02-04 17:40:36 0 [ERROR] Aborting
> 
> 
> 
> 
> I do not know what to do. My installation is done with kolla-ansible, mariadb docker restarts every 30 seconds.
> 
> Can the "kolla-ansible reconfigure mariadb" command be a solution?
> Could the command "kolla-ansible mariadb recovery" be a solution?
> 
> Thanks in advance if you can help me.
> 
> 
> 
> Franck
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220205/cb02f4f8/attachment-0001.htm>

From laurentfdumont at gmail.com  Sat Feb  5 16:08:02 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Sat, 5 Feb 2022 11:08:02 -0500
Subject: [kolla-ansible][mariadb]error (galera cluster problem ?)
In-Reply-To: <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr>
References: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr>
 <CAOAKi8wQ=MafWcRwh1duyuoGtF07j+ctQBma3vG25WTKCs8yYA@mail.gmail.com>
 <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr>
Message-ID: <CAOAKi8w-XN7zpqbFME0mrVW8+wv+LKO7fPhvxOTAPS9R8Ppcqg@mail.gmail.com>

   - Any chance to revert back switches + server? That would indicate that
   MTU was the issue.
   - Dont ping the iscsi bay, ping between the controllers in Openstack,
   they are the ones running mariadb/galera.
   - Since the icmp packets are small, it might not trigger the MTU issues.
   Can you try something like "ping -s 8972 -M do -c 4 $mariadb_host_2" from $
   mariadb_host_1?
   - What is your network setup on the servers? Two ports in a bond? Did
   you change both physical interface MTU + bond interface itself?


4 minutes to create a 20GB empty volume seems too long to me. For an actual
20GB image, it's going to depend on the speed of the backing storage tech.

On Sat, Feb 5, 2022 at 1:51 AM Franck VEDEL <
franck.vedel at univ-grenoble-alpes.fr> wrote:

> Thanks for your help.
>
>
>
>    - What was the starting value for MTU?
>
> 1500
>
>
>    - What was the starting value changed to for MTU?
>
> 9000
>
>
>    - Can ping between all your controllers?
>
> yes, all container starts except nova-conductor, nova-scheduler, maraidb
>
>
>
>    - Do you just have two controllers running mariadb?
>
> yes
>
>
>    - How did you change MTU?
>
>
> On the 3 servers:
>
> nmcli connection modify team0-port1 802-3-ethernet.mtu 9000
> nmcli connection modify team1-port2 802-3-ethernet.mtu 9000
>
> nmcli connection modify type team0 team.runner lack ethernet.mtu 9000
>
> nmcli con down team0
>
> nmcli con down team1
>
>
>
>
>    - Was the change reverted at the network level as well (switches need
>    to be configured higher or at the same MTU value then the servers)
>
> I didn?t change Mtu on network (switches) , but ping -s 10.0.5.117 (iscsi
> bay) was working from serv3.
>
> I changed the value of the mtu because the creation of the volumes takes a
> lot of time I find (4 minutes for 20G, which is too long for what I want to
> do, the patience of the students decreases with the years)
>
> Franck
>
> Le 4 f?vr. 2022 ? 23:12, Laurent Dumont <laurentfdumont at gmail.com> a
> ?crit :
>
>
>    - What was the starting value for MTU?
>    - What was the starting value changed to for MTU?
>    - Can ping between all your controllers?
>    - Do you just have two controllers running mariadb?
>    - How did you change MTU?
>    - Was the change reverted at the network level as well (switches need
>    to be configured higher or at the same MTU value then the servers)
>
> 4567 seems to be the port for galera (clustering for mariadb)
>
> On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL <
> franck.vedel at univ-grenoble-alpes.fr> wrote:
>
>> Hello,
>> I am in an emergency situation, quite catastrophic situation because I do
>> not know what to do.
>>
>> I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was
>> doing so well?
>>
>>
>> A network admin came to me and told me to change an MTU on the cards. I
>> knew it shouldn't be done...I shouldn't have done it.
>> I did it.
>> Of course, it didn't work as expected. I went back to my starting
>> configuration and there I have a big problem with mariadb which is set up
>> on serv1 and serv2.
>>
>> Here are my errors:
>>
>>
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend
>> connection: 110: failed to reach primary view: 110 (Connection timed out)
>>  at gcomm/src/pc.cpp:connect():160
>> 2022-02-04 17:40:36 0 [ERROR] WSREP:
>> gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend
>> connection: -110 (Connection timed out)
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475:
>> Failed to open channel 'openstack' at '
>> gcomm://10.0.5.109:4567,10.0.5.110:4567': -110 (Connection timed out)
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed
>> out
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(
>> gcomm://10.0.5.109:4567,10.0.5.110:4567) failed: 7
>> 2022-02-04 17:40:36 0 [ERROR] Aborting
>>
>>
>>
>>
>> I do not know what to do. My installation is done with kolla-ansible,
>> mariadb docker restarts every 30 seconds.
>>
>> Can the "kolla-ansible reconfigure mariadb" command be a solution?
>> Could the command "kolla-ansible mariadb recovery" be a solution?
>>
>> Thanks in advance if you can help me.
>>
>>
>>
>> Franck
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220205/309cc045/attachment.htm>

From franck.vedel at univ-grenoble-alpes.fr  Sun Feb  6 06:25:10 2022
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Sun, 6 Feb 2022 07:25:10 +0100
Subject: [kolla-ansible][mariadb]error (galera cluster problem ?)
In-Reply-To: <CAOAKi8w-XN7zpqbFME0mrVW8+wv+LKO7fPhvxOTAPS9R8Ppcqg@mail.gmail.com>
References: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr>
 <CAOAKi8wQ=MafWcRwh1duyuoGtF07j+ctQBma3vG25WTKCs8yYA@mail.gmail.com>
 <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr>
 <CAOAKi8w-XN7zpqbFME0mrVW8+wv+LKO7fPhvxOTAPS9R8Ppcqg@mail.gmail.com>
Message-ID: <2143074A-B762-4455-ADD4-86A001919D8D@univ-grenoble-alpes.fr>

Sunday morning: my openstack works?. OUF.
the "kolla-ansible -i multimode mariadb_recovery"  command (which is magic anyway) fixed the problem and then the mariadb and nova containers started.
Once solved the problems between my serv3 and the iscsi bay, restart the container glance, everything seems to work.

> 4 minutes to create a 20GB empty volume seems too long to me. For an actual 20GB image, it's going to depend on the speed of the backing storage tech.
4 minutes is for a volume from an image. I will see this problem next summer , I will retry to change the MTU value.

Thanks a lot, really

 
Franck 

> Le 5 f?vr. 2022 ? 17:08, Laurent Dumont <laurentfdumont at gmail.com> a ?crit :
> 
> Any chance to revert back switches + server? That would indicate that MTU was the issue.
> Dont ping the iscsi bay, ping between the controllers in Openstack, they are the ones running mariadb/galera.
> Since the icmp packets are small, it might not trigger the MTU issues. Can you try something like "ping -s 8972 -M do -c 4 $mariadb_host_2" from $ mariadb_host_1?
> What is your network setup on the servers? Two ports in a bond? Did you change both physical interface MTU + bond interface itself?
> 
> 4 minutes to create a 20GB empty volume seems too long to me. For an actual 20GB image, it's going to depend on the speed of the backing storage tech.
> 
> On Sat, Feb 5, 2022 at 1:51 AM Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
> Thanks for your help.
> 
> 
>> What was the starting value for MTU?
> 1500
>> What was the starting value changed to for MTU?
> 9000
>> Can ping between all your controllers?
> yes, all container starts except nova-conductor, nova-scheduler, maraidb
> 
> 
>> Do you just have two controllers running mariadb?
> yes
>> How did you change MTU?
> 
> On the 3 servers:
> nmcli connection modify team0-port1 802-3-ethernet.mtu 9000
> nmcli connection modify team1-port2 802-3-ethernet.mtu 9000
> nmcli connection modify type team0 team.runner lack ethernet.mtu 9000
> nmcli con down team0
> nmcli con down team1
> 
> 
>> Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)
> I didn?t change Mtu on network (switches) , but ping -s 10.0.5.117 (iscsi bay) was working from serv3.
> 
> I changed the value of the mtu because the creation of the volumes takes a lot of time I find (4 minutes for 20G, which is too long for what I want to do, the patience of the students decreases with the years)
> 
> Franck
> 
>> Le 4 f?vr. 2022 ? 23:12, Laurent Dumont <laurentfdumont at gmail.com <mailto:laurentfdumont at gmail.com>> a ?crit :
>> 
>> What was the starting value for MTU?
>> What was the starting value changed to for MTU?
>> Can ping between all your controllers?
>> Do you just have two controllers running mariadb?
>> How did you change MTU?
>> Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)
>> 4567 seems to be the port for galera (clustering for mariadb) <>
>> On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>> Hello,
>> I am in an emergency situation, quite catastrophic situation because I do not know what to do.
>> 
>> I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was doing so well?
>> 
>> 
>> A network admin came to me and told me to change an MTU on the cards. I knew it shouldn't be done...I shouldn't have done it.
>> I did it.
>> Of course, it didn't work as expected. I went back to my starting configuration and there I have a big problem with mariadb which is set up on serv1 and serv2.
>> 
>> Here are my errors:
>> 
>> 
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
>> 	 at gcomm/src/pc.cpp:connect():160
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out)
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': <> -110 (Connection timed out)
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed out
>> 2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567 <>) failed: 7
>> 2022-02-04 17:40:36 0 [ERROR] Aborting
>> 
>> 
>> 
>> 
>> I do not know what to do. My installation is done with kolla-ansible, mariadb docker restarts every 30 seconds.
>> 
>> Can the "kolla-ansible reconfigure mariadb" command be a solution?
>> Could the command "kolla-ansible mariadb recovery" be a solution?
>> 
>> Thanks in advance if you can help me.
>> 
>> 
>> 
>> Franck
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220206/eaa28f1f/attachment-0001.htm>

From gmann at ghanshyammann.com  Mon Feb  7 00:26:54 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Sun, 06 Feb 2022 18:26:54 -0600
Subject: [all][elections][ptl][tc] Combined PTL/TC Election Feb-Mar 2022 Season
Message-ID: <17ed1938a6d.f66e4f3067306.4265343578747584978@ghanshyammann.com>

Hello Everyone!

This is time for the Z development cycle Technical elections.

Election details:  https://governance.openstack.org/election/ 
 
The nomination period officially begins Feb 8, 2022 23:45.
 
Please read the stipulations and timelines for candidates and electorate contained in
this governance documentation.
 
The PTL and TC elections for the coming cycle will run concurrently; deadlines for their
nomination and voting activities are synchronized but will still use separate ballots.
 
Please note, if only one candidate is nominated as PTL for a project team during the PTL
nomination period, that candidate will win by acclaim, and there will be no poll. There will
only be a poll if there is more than one candidate stepping forward for a project team's PTL
position. If teams do not produce any PTL candidate during the nomination period, or are
interested in considering alternatives prior to nominations, the TC may consider requests to
switch to the new distributed leadership model they recently documented[1].
 
In keeping with the established plan[1 ] to gradually reduce the size of the Technical Committee,
we will only fill five (5) seats in this coming election.
 
There will be further announcements posted to the mailing list as action is required from the
electorate or candidates. This email is for information purposes only.
 
If you have any questions which you feel affect others please reply to this email thread.
 
If you have any questions that you which to discuss in private please email any of the election
officials[3] so that we may address your concerns.
 
[1] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html 
[2] https://governance.openstack.org/tc/reference/charter.html#number-of-seats-to-elect 
[3] https://governance.openstack.org/election/#election-officials


-gmann & The OpenStack Technical Election Officials



From arne.wiebalck at cern.ch  Mon Feb  7 08:06:39 2022
From: arne.wiebalck at cern.ch (Arne Wiebalck)
Date: Mon, 7 Feb 2022 09:06:39 +0100
Subject: [baremetal-sig][ironic] Tue Feb 8, 2022, 2pm UTC: Scaling Ironic
Message-ID: <4159c5ec-4019-9299-fea4-2a4897e413ab@cern.ch>

Dear all,

The Bare Metal SIG will meet tomorrow

   Tue Feb 8, 2022, at 2pm UTC on zoom.

The meeting will feature a "topic-of-the-day"
presentation by Julia Kreger on

   "Scaling Ironic"

providing details on the massive performance
and scaling improvements Ironic has seen in
the latest releases.

Come along and bring your questions, everyone is welcome!

As usual, all details on https://etherpad.opendev.org/p/bare-metal-sig

Cheers,
  Arne


From amoralej at redhat.com  Mon Feb  7 08:24:27 2022
From: amoralej at redhat.com (Alfredo Moralejo Alonso)
Date: Mon, 7 Feb 2022 09:24:27 +0100
Subject: [puppet][tc] Propose changing the release model to cycle-with-rc
In-Reply-To: <CAL_crJRPqEp+e=qysmR8=XVq37YLWd+EaB7ChnGjkbkz9YEg7Q@mail.gmail.com>
References: <CAL_crJRPqEp+e=qysmR8=XVq37YLWd+EaB7ChnGjkbkz9YEg7Q@mail.gmail.com>
Message-ID: <CACrbaxgpD64n8DMoc=BBPjgcF5hRU-adGbJefYQs=4SF=0Vq4g@mail.gmail.com>

On Mon, Jan 24, 2022 at 2:59 AM Takashi Kajinami <tkajinam at redhat.com>
wrote:

> Hello,
>
>
> I already discussed this with a few cores last year but I'm raising this
> topic
> in ML to make an official decision.
>
> Currently Puppet OpenStack is following cycle-with-intermediary and
> creates a release every milestone. However our code is tightly related
> to the actual service implementations and having only puppet releases
> is not very useful.
>
> Considering the above point, and effort required to cut off releases per
> milestone,
> I'll propose changing our release model to cycle-with-rc , and creating a
> single release.
>
>
+1 LGTM.

>From the RDO side, we do our first release-based packages based on RC1, so
that's the first release actually useful for us.

Alfredo


> Because we already created milestone releases for Yoga, I'm thinking of
> applying
> the change from next cycle(Z).
>
> Please let me know if you have any concerns.
>
> Thank you,
> Takashi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/e62b83f4/attachment.htm>

From eblock at nde.ag  Mon Feb  7 09:55:28 2022
From: eblock at nde.ag (Eugen Block)
Date: Mon, 07 Feb 2022 09:55:28 +0000
Subject: [kolla-ansible][mariadb]error (galera cluster problem ?)
In-Reply-To: <2143074A-B762-4455-ADD4-86A001919D8D@univ-grenoble-alpes.fr>
References: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr>
 <CAOAKi8wQ=MafWcRwh1duyuoGtF07j+ctQBma3vG25WTKCs8yYA@mail.gmail.com>
 <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr>
 <CAOAKi8w-XN7zpqbFME0mrVW8+wv+LKO7fPhvxOTAPS9R8Ppcqg@mail.gmail.com>
 <2143074A-B762-4455-ADD4-86A001919D8D@univ-grenoble-alpes.fr>
Message-ID: <20220207095528.Horde.TLJ23YmLfAbOaPxt2gc-22M@webmail.nde.ag>

Hi Franck,

although it's a different topic than your original question I wanted  
to comment on the volume creation time (maybe a new thread would make  
sense). What is your storage back end? If it is ceph, are your images  
in raw format? Otherwise cinder has to download the image from glance  
(to /var/lib/cinder/conversion) and convert it, then upload it back to  
ceph. It's similar with nova, nova stores base images in  
/var/lib/nova/instances/_base to prevent the compute nodes from  
downloading it every time. This may save some time for the download,  
but the upload has to happen anyway. And if you don't use shared  
storage for nova (e.g. for live-migration) you may encounter that some  
compute nodes are quicker creating an instance because they only have  
to upload, others will first have to download, convert and then upload  
it.

You would see the conversion in the logs of cinder:

INFO cinder.image.image_utils  
[req-f2062570-4006-464b-a1f5-d0d5ac34670d  
d71f59600f1c40c394022738d4864915 31b9b4900a4d4bdaabaf263d0b4021be - -  
-] Converted 2252.00 MB image at 757.52 MB/s

Hope this helps.

Eugen


Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:

> Sunday morning: my openstack works?. OUF.
> the "kolla-ansible -i multimode mariadb_recovery"  command (which is  
> magic anyway) fixed the problem and then the mariadb and nova  
> containers started.
> Once solved the problems between my serv3 and the iscsi bay, restart  
> the container glance, everything seems to work.
>
>> 4 minutes to create a 20GB empty volume seems too long to me. For  
>> an actual 20GB image, it's going to depend on the speed of the  
>> backing storage tech.
> 4 minutes is for a volume from an image. I will see this problem  
> next summer , I will retry to change the MTU value.
>
> Thanks a lot, really
>
>
> Franck
>
>> Le 5 f?vr. 2022 ? 17:08, Laurent Dumont <laurentfdumont at gmail.com> a ?crit :
>>
>> Any chance to revert back switches + server? That would indicate  
>> that MTU was the issue.
>> Dont ping the iscsi bay, ping between the controllers in Openstack,  
>> they are the ones running mariadb/galera.
>> Since the icmp packets are small, it might not trigger the MTU  
>> issues. Can you try something like "ping -s 8972 -M do -c 4  
>> $mariadb_host_2" from $ mariadb_host_1?
>> What is your network setup on the servers? Two ports in a bond? Did  
>> you change both physical interface MTU + bond interface itself?
>>
>> 4 minutes to create a 20GB empty volume seems too long to me. For  
>> an actual 20GB image, it's going to depend on the speed of the  
>> backing storage tech.
>>
>> On Sat, Feb 5, 2022 at 1:51 AM Franck VEDEL  
>> <franck.vedel at univ-grenoble-alpes.fr  
>> <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>> Thanks for your help.
>>
>>
>>> What was the starting value for MTU?
>> 1500
>>> What was the starting value changed to for MTU?
>> 9000
>>> Can ping between all your controllers?
>> yes, all container starts except nova-conductor, nova-scheduler, maraidb
>>
>>
>>> Do you just have two controllers running mariadb?
>> yes
>>> How did you change MTU?
>>
>> On the 3 servers:
>> nmcli connection modify team0-port1 802-3-ethernet.mtu 9000
>> nmcli connection modify team1-port2 802-3-ethernet.mtu 9000
>> nmcli connection modify type team0 team.runner lack ethernet.mtu 9000
>> nmcli con down team0
>> nmcli con down team1
>>
>>
>>> Was the change reverted at the network level as well (switches  
>>> need to be configured higher or at the same MTU value then the  
>>> servers)
>> I didn?t change Mtu on network (switches) , but ping -s 10.0.5.117  
>> (iscsi bay) was working from serv3.
>>
>> I changed the value of the mtu because the creation of the volumes  
>> takes a lot of time I find (4 minutes for 20G, which is too long  
>> for what I want to do, the patience of the students decreases with  
>> the years)
>>
>> Franck
>>
>>> Le 4 f?vr. 2022 ? 23:12, Laurent Dumont <laurentfdumont at gmail.com  
>>> <mailto:laurentfdumont at gmail.com>> a ?crit :
>>>
>>> What was the starting value for MTU?
>>> What was the starting value changed to for MTU?
>>> Can ping between all your controllers?
>>> Do you just have two controllers running mariadb?
>>> How did you change MTU?
>>> Was the change reverted at the network level as well (switches  
>>> need to be configured higher or at the same MTU value then the  
>>> servers)
>>> 4567 seems to be the port for galera (clustering for mariadb) <>
>>> On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL  
>>> <franck.vedel at univ-grenoble-alpes.fr  
>>> <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>> Hello,
>>> I am in an emergency situation, quite catastrophic situation  
>>> because I do not know what to do.
>>>
>>> I have an Openstack cluster with 3 servers (serv1, serv2, serv3).  
>>> He was doing so well?
>>>
>>>
>>> A network admin came to me and told me to change an MTU on the  
>>> cards. I knew it shouldn't be done...I shouldn't have done it.
>>> I did it.
>>> Of course, it didn't work as expected. I went back to my starting  
>>> configuration and there I have a big problem with mariadb which is  
>>> set up on serv1 and serv2.
>>>
>>> Here are my errors:
>>>
>>>
>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend  
>>> connection: 110: failed to reach primary view: 110 (Connection  
>>> timed out)
>>> 	 at gcomm/src/pc.cpp:connect():160
>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>> gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend  
>>> connection: -110 (Connection timed out)
>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>> gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel  
>>> 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': <> -110  
>>> (Connection timed out)
>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed:  
>>> Connection timed out
>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>> wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567 <>) failed: 7
>>> 2022-02-04 17:40:36 0 [ERROR] Aborting
>>>
>>>
>>>
>>>
>>> I do not know what to do. My installation is done with  
>>> kolla-ansible, mariadb docker restarts every 30 seconds.
>>>
>>> Can the "kolla-ansible reconfigure mariadb" command be a solution?
>>> Could the command "kolla-ansible mariadb recovery" be a solution?
>>>
>>> Thanks in advance if you can help me.
>>>
>>>
>>>
>>> Franck
>>>
>>>
>>





From katonalala at gmail.com  Mon Feb  7 13:39:36 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Mon, 7 Feb 2022 14:39:36 +0100
Subject: [neutron] Bug deputy report for week of January 31
Message-ID: <CALg0jK=wpsd2a6hBM+6vMEy9mYR2GSJitE4p0CqkuinaB_v3rA@mail.gmail.com>

Hi Neutron Team

I was bug deputy in neutron last week.

Summary
=======

Needs attention
============
* Neutron-dynamic-routing does not work with OVN (
https://bugs.launchpad.net/neutron/+bug/1959666)
* [stein][neutron] Static rules losed (
https://bugs.launchpad.net/neutron/+bug/1959884)
* VM gets wrong ipv6 address from neutron-dhcp-agent after ipv6 address on
port was changed (https://bugs.launchpad.net/neutron/+bug/1959697)

Bugs with assignees
================
* Random Tempest test failures(SSH failure) in openvswitch jobs  (
https://bugs.launchpad.net/neutron/+bug/1959564)
** https://review.opendev.org/c/openstack/neutron/+/827315

* QoS Ingress bandwidth limit with OVS backend may not work as expected (
https://bugs.launchpad.net/neutron/+bug/1959567)
** WIP: https://review.opendev.org/c/openstack/neutron/+/827112

* test_local_ip_connectivity test failing in stable/xena jobs (
https://bugs.launchpad.net/neutron/+bug/1959573):
** MERGED: https://review.opendev.org/c/openstack/neutron/+/827057

* pip 22 breaks python3.6 jobs (Victoria and older CI jobs) (
https://bugs.launchpad.net/neutron/+bug/1959600)
** MERGED:
https://review.opendev.org/q/Iab2c391d5388461fe9e9037cee81884ce8032e72

* minimum_packet_rate qos rule type is not visible in the GET
/v2.0/qos/rule-types response (
https://bugs.launchpad.net/neutron/+bug/1959749)
** https://review.opendev.org/q/topic:bug%252F1959749

* "get_rule_type" should not check the context admin status (
https://bugs.launchpad.net/neutron/+bug/1959778)
** https://review.opendev.org/c/openstack/neutron-lib/+/827533

* ovn-octavia loadbalancer not working when VIP is on a dual-stack provider
network (https://bugs.launchpad.net/neutron/+bug/1959903 )
** https://review.opendev.org/c/openstack/ovn-octavia-provider/+/827670

* [ovn] Stale ports in the OVN database at churn (
https://bugs.launchpad.net/neutron/+bug/1960006)
** https://review.opendev.org/c/openstack/neutron/+/827834

* neutron-tempest-with-uwsgi job failing tempest tests with: Floating ip
<fip> failed to associate with server <server id> in time (
https://bugs.launchpad.net/neutron/+bug/1960022 )
** MERGED: https://review.opendev.org/c/openstack/tempest/+/814085

* NullQuota driver returns None that breaks client API (
https://bugs.launchpad.net/neutron/+bug/1960032)
** https://review.opendev.org/c/openstack/neutron/+/827875

Low hanging fruit
=============
* potential performance issue when scheduling network segments (
https://bugs.launchpad.net/neutron/+bug/1959750)

Need more information
==================
* Disallow users to allocate gateway ip of external subnets as floating ip (
https://bugs.launchpad.net/neutron/+bug/1959699 )

Regards
Lajos Katona (lajoskatona)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/bbd01933/attachment.htm>

From satish.txt at gmail.com  Mon Feb  7 14:33:33 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Mon, 7 Feb 2022 09:33:33 -0500
Subject: Recently Upgraded to XENA and getting this error
In-Reply-To: <CAEs876groLqbS4EDGUmDXY5_Fo8LQERG93bbXu-gqUFibnszRA@mail.gmail.com>
References: <CA+ykd63W5ibVE-yL6S7tO4XP+Ce343cy7ohibzc84n2+-sm3sg@mail.gmail.com>
 <CAEs876iG0Ph4zToqbwC08JftTo4mKY2w8BKBncMN_ekKc3dQZA@mail.gmail.com>
 <CA+ykd62inFqTuyj6yUkjXoCtab4Zy4P_XsdApeyA3nxxZdLc9g@mail.gmail.com>
 <CAEs876groLqbS4EDGUmDXY5_Fo8LQERG93bbXu-gqUFibnszRA@mail.gmail.com>
Message-ID: <CAPgF-fqRW7+EChyRMr0_XyUOskvwf0U5oTdEND0p=Z9HGFFzqg@mail.gmail.com>

Not sure about others but I have noticed the same error in wallaby
also, mostly i am using a command line nowadays until we have a fix.

On Fri, Feb 4, 2022 at 9:04 AM Mohammed Naser <mnaser at vexxhost.com> wrote:
>
> The fix hasn?t landed yet since then.
>
> On Fri, Feb 4, 2022 at 8:38 AM Adivya Singh <adivya1.singh at gmail.com> wrote:
>>
>> hi Mohammed,
>>
>> This is for pike release, I am talking about Xena
>>
>> Regards
>> Adivya Singh
>>
>> On Thu, Feb 3, 2022 at 4:37 AM Mohammed Naser <mnaser at vexxhost.com> wrote:
>>>
>>> I think you're running into this which has been broken for a hot minute:
>>>
>>> https://review.opendev.org/c/openstack/horizon/+/808102
>>>
>>> that patch works for us locally.
>>>
>>> On Wed, Feb 2, 2022 at 10:37 AM Adivya Singh <adivya1.singh at gmail.com> wrote:
>>> >
>>> > Hello,
>>> >
>>> > We have recently upgraded to XENA release of Openstack, and getting this error while trying to Resize instance using GUI, it is telling "Danger , Please try Later"
>>> > Same is working properly from CLI without any issue
>>> >
>>> > Any thoughts on this
>>> >
>>> > Regards
>>> > Adivya Singh
>>>
>>>
>>>
>>> --
>>> Mohammed Naser
>>> VEXXHOST, Inc.
>
> --
> Mohammed Naser
> VEXXHOST, Inc.


From satish.txt at gmail.com  Mon Feb  7 15:07:01 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Mon, 7 Feb 2022 10:07:01 -0500
Subject: [kolla-ansible] custom configuration override issue.
Message-ID: <CAPgF-fqr8+3OFvxmo4Xu1H7n6ZoztA9WRfihhrqQZmjt74NdDg@mail.gmail.com>

Folks,

I have a working kolla-ansible environment and now I want to push out
some nova custom changes to specific compute nodes and I am trying the
following override but somehow it doesn't work for me.

Ansible inventory file multinode

[control]
192.168.75.141 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
192.168.75.142 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
192.168.75.143 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
[compute]
192.168.75.[144:175] ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key


I want to change some option on 192.168.75.199 compute server, I don't
have compute name in inventory so i am using IP address for override
but somehow that doesn't work

/etc/kolla/config/nova/192.168.75.199/nova.conf

I have tried the following to use hypervisor hostname but that doesn't
work. What am I doing wrong here?

/etc/kolla/config/nova/COMP01.local/nova.conf


Following works for me but they are for global not for specific nodes.
How do i override specific node file?

/etc/kolla/config/nova/nova-compute.conf


From rosmaita.fossdev at gmail.com  Mon Feb  7 15:15:38 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Mon, 7 Feb 2022 10:15:38 -0500
Subject: [ops][cinder] resource count survey
Message-ID: <06c94995-02fa-caf2-517a-ab334cffc714@gmail.com>

Hello operators,

The Cinder project is working on the cinder quotas system in an effort 
to improve its accuracy and remove the necessity for operators to go 
through and clean it up occasionally when it gets out of sync with reality.

One way to do this is to use dynamic database counting (instead of 
storing the usage info in a table where it can become outdated). Whether 
this will be a good change depends on how many records the database has 
to process during a transaction, which in turn depends on how many 
Cinder resources a project has.

So we need to get some information from you.

Please take this brief survey:
https://rosmaita.wufoo.com/forms/cinder-resource-count-survey/

The survey closes on Wednesday 30 March at 1200 UTC, so that we can have 
data to discuss during the "Z" PTG.  But please don't procrastinate, 
it's only 6 questions and the answers are all positive integers. It 
shouldn't take long to fill out!


Thanks!
brian


From massimo.sgaravatto at gmail.com  Mon Feb  7 15:21:05 2022
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Mon, 7 Feb 2022 16:21:05 +0100
Subject: [nova][ops] Problem with nova policies for resume operation
Message-ID: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>

Dear all

I am running a Xena installation

I have modified the nova policy fail so that certain operations can be done
only by the user who created the instance, or by the administrator
This [*] is my policy.yaml file.
While the suspend operation works as intended (I can suspend only my
instances and I am not allowed to suspend an instance created by another
user) I am not able to resume an instance that I own and that I have
previously suspended.
I get this error:

ERROR (Forbidden): Policy doesn't allow
os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403)
(Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)

Only removing the line:

"os_compute_api:os-suspend-server:suspend": "rule:admin_api or
user_id:%(user_id)s"

from the policy file, I am able to resume the instance.

I am not able to understand what is wrong with that policy. Any hints ?

Thanks, Massimo


[*]

# Pause a server
# POST  /servers/{server_id}/action (pause)
# Intended scope(s): system, project
"os_compute_api:os-pause-server:pause": "rule:admin_api or
user_id:%(user_id)s"

# Delete a server
# DELETE  /servers/{server_id}
# Intended scope(s): system, project
"os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"

# Resize a server
# POST  /servers/{server_id}/action (resize)
# Intended scope(s): system, project
"os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"

# Rebuild a server
# POST  /servers/{server_id}/action (rebuild)
# Intended scope(s): system, project
"os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"

# Stop a server
# POST  /servers/{server_id}/action (os-stop)
# Intended scope(s): system, project
"os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"

# Resume suspended server
# POST  /servers/{server_id}/action (resume)
# Intended scope(s): system, project
"os_compute_api:os-suspend-server:resume": "rule:admin_api or
user_id:%(user_id)s"

# Suspend server
# POST  /servers/{server_id}/action (suspend)
# Intended scope(s): system, project
"os_compute_api:os-suspend-server:suspend": "rule:admin_api or
user_id:%(user_id)s"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/3751bd7e/attachment-0001.htm>

From radoslaw.piliszek at gmail.com  Mon Feb  7 15:45:34 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Mon, 7 Feb 2022 16:45:34 +0100
Subject: [ironic] Each deploy overwrites the entire target disk
Message-ID: <CAKZ_x7_W5SWSu09kXnya_Oo7rw8AYcZm+GJ732-e00DS_zzvYg@mail.gmail.com>

Dears,

I have a question regarding the default behaviour of Ironic Python
Agent - it seems that each deploy causes the entire target disk to be
overwritten. I have noticed this after replacing disks with larger
ones, the deployment process started taking considerably longer and I
observed that each sector is rewritten on the target device.
Is that expected? Can I somehow avoid it?
I am using whole-disk, qcow2 images that are much smaller than the
disk size (even in raw form).
I am running Ironic Wallaby.
The deployment method is direct.

Kind regards,
-yoctozepto


From lucasagomes at gmail.com  Mon Feb  7 15:52:34 2022
From: lucasagomes at gmail.com (Lucas Alvares Gomes)
Date: Mon, 7 Feb 2022 15:52:34 +0000
Subject: [all][Neutron][Octavia][Nova][Kuryr] Bump pyroute2 version to 0.6.5
 in stable/wallaby
Message-ID: <CAB1EZBr2q7K3opZyZbP-+92Letvyo4Gv5tMarqzJFMbG4zySZA@mail.gmail.com>

Hi,

I currently have a patch up for openstack/requirements [0] bumping the
version of the pyroute2 library from 0.5.14 to 0.6.5 as the older
version have a memory leak issue [1] in the NDB module which can cause
the service using the library to be killed by the OOM killer because
of an out-of-memory condition.

This email was a suggestion by a core reviewer to raise awareness from
the broader community to this change/issue.

Please if you have any concerning about this version bump let us know
here on in the patch itself [0]

[0] https://review.opendev.org/c/openstack/requirements/+/828091
[1] https://github.com/svinota/pyroute2/issues/789

Cheers,
Lucas


From tkajinam at redhat.com  Mon Feb  7 16:03:29 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 8 Feb 2022 01:03:29 +0900
Subject: [nova][ops] Problem with nova policies for resume operation
In-Reply-To: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
References: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
Message-ID: <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>

Quickly checking the current code, it seems support for user_id was
introduced to only suspend api[1]
 [1] https://review.opendev.org/c/openstack/nova/+/353344

I've opened a bug for nova[2] because supporting consistent rules for
suspend and resume
makes clear sense to me.
 [2] https://bugs.launchpad.net/nova/+bug/1960247


On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <
massimo.sgaravatto at gmail.com> wrote:

> Dear all
>
> I am running a Xena installation
>
> I have modified the nova policy fail so that certain operations can be
> done only by the user who created the instance, or by the administrator
> This [*] is my policy.yaml file.
> While the suspend operation works as intended (I can suspend only my
> instances and I am not allowed to suspend an instance created by another
> user) I am not able to resume an instance that I own and that I have
> previously suspended.
> I get this error:
>
> ERROR (Forbidden): Policy doesn't allow
> os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403)
> (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
>
> Only removing the line:
>
> "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
> user_id:%(user_id)s"
>
> from the policy file, I am able to resume the instance.
>
> I am not able to understand what is wrong with that policy. Any hints ?
>
> Thanks, Massimo
>
>
> [*]
>
> # Pause a server
> # POST  /servers/{server_id}/action (pause)
> # Intended scope(s): system, project
> "os_compute_api:os-pause-server:pause": "rule:admin_api or
> user_id:%(user_id)s"
>
> # Delete a server
> # DELETE  /servers/{server_id}
> # Intended scope(s): system, project
> "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
>
> # Resize a server
> # POST  /servers/{server_id}/action (resize)
> # Intended scope(s): system, project
> "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"
>
> # Rebuild a server
> # POST  /servers/{server_id}/action (rebuild)
> # Intended scope(s): system, project
> "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"
>
> # Stop a server
> # POST  /servers/{server_id}/action (os-stop)
> # Intended scope(s): system, project
> "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
>
> # Resume suspended server
> # POST  /servers/{server_id}/action (resume)
> # Intended scope(s): system, project
> "os_compute_api:os-suspend-server:resume": "rule:admin_api or
> user_id:%(user_id)s"
>
> # Suspend server
> # POST  /servers/{server_id}/action (suspend)
> # Intended scope(s): system, project
> "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
> user_id:%(user_id)s"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/0d28581a/attachment.htm>

From opensrloo at gmail.com  Mon Feb  7 16:56:00 2022
From: opensrloo at gmail.com (Ruby Loo)
Date: Mon, 7 Feb 2022 11:56:00 -0500
Subject: [ironic]Anaconda deploy interface config
In-Reply-To: <CACkzpE4A11he8EDmF-tDVOb2ZMR0FnaHogpBOq9EpWdYZ36ahg@mail.gmail.com>
References: <CACkzpE4A11he8EDmF-tDVOb2ZMR0FnaHogpBOq9EpWdYZ36ahg@mail.gmail.com>
Message-ID: <CAJkGiNuPMD-wMJpn_=eMK63j9SBuYOOmTQGS9HsVh8XYH5aQWw@mail.gmail.com>

Hi Carol,

Thanks for reporting this! It is a bug :-( The fix is in
https://review.opendev.org/c/openstack/ironic/+/827924.

--ruby

On Fri, Feb 4, 2022 at 11:44 AM Carol Bouchard <cbouchar at redhat.com> wrote:

> Ironic folks:
>
> I'm trying to spawn a RHEL7 image using a kickstart file and having issues
> with stage2 file.
> First I used bifrost to initially setup a couple of VMs.  (There is no
> openstack/glance).
> I'm now using one of those VMs to boot up with RHEL7. I changed the VM
> config
> with the following:
>
> *| deploy_interface       | anaconda*
> * | instance_info          | {'kernel': 'http://myip:8080/RHEL7/vmlinuz
> <http://myip:8080/RHEL7/vmlinuz>', 'ramdisk':
> 'http://myip:8080/RHEL7/initrd.img <http://myip:8080/RHEL7/initrd.img>',
> 'image_source': 'http://myip:8080/RHEL7/initrd.img
> <http://myip:8080/RHEL7/initrd.img>', 'stage2':
> 'http://myip:8080/RHEL7/squashfs.img
> <http://myip:8080/RHEL7/squashfs.img>', 'ks_cfg':
> 'http://myip:8080/RHEL7/ks.cfg.template
> <http://myip:8080/RHEL7/ks.cfg.template>', 'ks_template':
> 'http://myip:8080/RHEL7/ks.cfg.template
> <http://myip:8080/RHEL7/ks.cfg.template>'}*
>
> ironic.conf changes I made are as follows:
>
> *enabled_deploy_interfaces = direct,ramdisk,anaconda*
>
> *[anaconda]default_ks_template = file:///etc/ironic/ks.cfg.template*
>
> The error I'm getting is as follows:
>  *$ baremetal node show testvm1 --field last_error*
>
> *| last_error | Deploy step deploy.deploy failed with IsADirectoryError:
> [Errno 21] Is a directory:
> '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'.*
> Tail end of traceback is as follows:
>
>
>
>
>
>
>
>
> * ironic-conductor[]:   ERROR ironic.conductor.utils   File
> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/common/pxe_utils.py",
> line 1245, in cache_ramdisk_kernel ironic-conductor[]:   ERROR
> ironic.conductor.utils     deploy_utils.fetch_images(ctx, TFTPImageCache(),
> list(t_pxe_info.values()), ironic-conductor[]:   ERROR
> ironic.conductor.utils   File
> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/deploy_utils.py",
> line 240, in fetch_images ironic-conductor[]:   ERROR
> ironic.conductor.utils     cache.fetch_image(href, path, ctx=ctx,
> force_raw=force_raw) ironic-conductor[]:   ERROR ironic.conductor.utils
> File
> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py",
> line 120, in fetch_image ironic-conductor[]:   ERROR ironic.conductor.utils
>     dest_up_to_date =
> _delete_dest_path_if_stale(master_path, ironic-conductor[]:   ERROR
> ironic.conductor.utils   File
> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py",
> line 460, in _delete_dest_path_if_stale ironic-conductor[]:   ERROR
> ironic.conductor.utils     os.unlink(dest_path) ironic-conductor[]:   ERROR
> ironic.conductor.utils IsADirectoryError: [Errno 21] Is a directory:
> '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'*
>
> Please advise.
>
> Carol
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/01157623/attachment.htm>

From massimo.sgaravatto at gmail.com  Mon Feb  7 17:06:06 2022
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Mon, 7 Feb 2022 18:06:06 +0100
Subject: [nova][ops] Problem with nova policies for resume operation
In-Reply-To: <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>
References: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
 <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>
Message-ID: <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>

Thanks

Actually in the past support for user_id in the resume operation worked as
expected
E.g. I have a train installation where I defined this rule in the
policy.json file:

"os_compute_api:os-suspend-server:suspend": "rule:admin_api or
user_id:%(user_id)s",

and it works

Cheers, Massimo



On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <tkajinam at redhat.com> wrote:

> Quickly checking the current code, it seems support for user_id was
> introduced to only suspend api[1]
>  [1] https://review.opendev.org/c/openstack/nova/+/353344
>
> I've opened a bug for nova[2] because supporting consistent rules for
> suspend and resume
> makes clear sense to me.
>  [2] https://bugs.launchpad.net/nova/+bug/1960247
>
>
> On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <
> massimo.sgaravatto at gmail.com> wrote:
>
>> Dear all
>>
>> I am running a Xena installation
>>
>> I have modified the nova policy fail so that certain operations can be
>> done only by the user who created the instance, or by the administrator
>> This [*] is my policy.yaml file.
>> While the suspend operation works as intended (I can suspend only my
>> instances and I am not allowed to suspend an instance created by another
>> user) I am not able to resume an instance that I own and that I have
>> previously suspended.
>> I get this error:
>>
>> ERROR (Forbidden): Policy doesn't allow
>> os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403)
>> (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
>>
>> Only removing the line:
>>
>> "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
>> user_id:%(user_id)s"
>>
>> from the policy file, I am able to resume the instance.
>>
>> I am not able to understand what is wrong with that policy. Any hints ?
>>
>> Thanks, Massimo
>>
>>
>> [*]
>>
>> # Pause a server
>> # POST  /servers/{server_id}/action (pause)
>> # Intended scope(s): system, project
>> "os_compute_api:os-pause-server:pause": "rule:admin_api or
>> user_id:%(user_id)s"
>>
>> # Delete a server
>> # DELETE  /servers/{server_id}
>> # Intended scope(s): system, project
>> "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
>>
>> # Resize a server
>> # POST  /servers/{server_id}/action (resize)
>> # Intended scope(s): system, project
>> "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"
>>
>> # Rebuild a server
>> # POST  /servers/{server_id}/action (rebuild)
>> # Intended scope(s): system, project
>> "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"
>>
>> # Stop a server
>> # POST  /servers/{server_id}/action (os-stop)
>> # Intended scope(s): system, project
>> "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
>>
>> # Resume suspended server
>> # POST  /servers/{server_id}/action (resume)
>> # Intended scope(s): system, project
>> "os_compute_api:os-suspend-server:resume": "rule:admin_api or
>> user_id:%(user_id)s"
>>
>> # Suspend server
>> # POST  /servers/{server_id}/action (suspend)
>> # Intended scope(s): system, project
>> "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
>> user_id:%(user_id)s"
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/d901503c/attachment-0001.htm>

From gmann at ghanshyammann.com  Mon Feb  7 17:10:37 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 07 Feb 2022 11:10:37 -0600
Subject: [nova][ops] Problem with nova policies for resume operation
In-Reply-To: <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>
References: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
 <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>
 <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>
Message-ID: <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com>

 ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote ----
 > Thanks
 > Actually in the past support for user_id in the resume operation worked as expectedE.g. I have a train installation where I defined this rule in the policy.json file:
 > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s",
 > 
 > and it works
 > Cheers, Massimo
 > 
 > 
 > On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
 > Quickly checking the current code, it seems support for user_id was introduced to only suspend api[1] [1] https://review.opendev.org/c/openstack/nova/+/353344
 > I've opened a bug for nova[2] because supporting consistent rules for suspend and resumemakes clear sense to me.
 >  [2] https://bugs.launchpad.net/nova/+bug/1960247
 > 
 > On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote:
 > Dear all
 > 
 > I am running a Xena installation
 > I have modified the nova policy fail so that certain operations can be done only by the user who created the instance, or by the administratorThis [*] is my policy.yaml file.While the suspend operation works as intended (I can suspend only my instances and I am not allowed to suspend an instance created by another user) I am not able to resume an instance that I own and that I have previously suspended.I get this error:
 > ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
 > 
 > Only removing the line:
 > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
 > from the policy file, I am able to resume the instance.
 > I am not able to understand what is wrong with that policy. Any hints ?

I think we had the same conversation in June 2020 also[1].

Nova does not restrict the policy by user_id except keypairs API. We have kept it for a few of the
destructive actions (for backwards compatibility) and intent to remove them too in future. I remember
we discussed this in 2016 but I could not find the ML thread for that but
the consensus that time was we do not intend to support user_id based restriction permission in the API.

This is the spec where we kept the user_id support for destructive actions and the reason.

https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html

As we are moving our policy to new defaults (with new direction), after that we should discuss to remove all the user_id
enforcement support except keypair. But defiantly should not extend it for any other action.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015273.html

-gmann

 > Thanks, Massimo
 > 
 > [*]
 > # Pause a server
 > # POST  /servers/{server_id}/action (pause)
 > # Intended scope(s): system, project
 > "os_compute_api:os-pause-server:pause": "rule:admin_api or user_id:%(user_id)s"
 > 
 > # Delete a server
 > # DELETE  /servers/{server_id}
 > # Intended scope(s): system, project
 > "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
 > 
 > # Resize a server
 > # POST  /servers/{server_id}/action (resize)
 > # Intended scope(s): system, project
 > "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"
 > 
 > # Rebuild a server
 > # POST  /servers/{server_id}/action (rebuild)
 > # Intended scope(s): system, project
 > "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"
 > 
 > # Stop a server
 > # POST  /servers/{server_id}/action (os-stop)
 > # Intended scope(s): system, project
 > "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
 > 
 > # Resume suspended server
 > # POST  /servers/{server_id}/action (resume)
 > # Intended scope(s): system, project
 > "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"
 > 
 > # Suspend server
 > # POST  /servers/{server_id}/action (suspend)
 > # Intended scope(s): system, project
 > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
 > 


From smooney at redhat.com  Mon Feb  7 17:23:21 2022
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 07 Feb 2022 17:23:21 +0000
Subject: [nova][ops] Problem with nova policies for resume operation
In-Reply-To: <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>
References: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
 <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>
 <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>
Message-ID: <bf05eeeeb8d1899e22a614241f89945f2177a54c.camel@redhat.com>

On Mon, 2022-02-07 at 18:06 +0100, Massimo Sgaravatto wrote:
> Thanks
> 
> Actually in the past support for user_id in the resume operation worked as
> expected
> E.g. I have a train installation where I defined this rule in the
> policy.json file:
> 
> "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
> user_id:%(user_id)s",
> 
> and it works
resume has a seperate policy
https://github.com/openstack/nova/blob/master/nova/policies/suspend_server.py#L25-L35
so you would likely have to update both.

os_compute_api:os-suspend-server:suspend only covers suppend
os_compute_api:os-suspend-server:resume applies to resume.

this was also the case in train by the way.

technially upstream does not "support" custom policy in that if you use custom policy and a feature is missing
like passing user_id to a specifc policy check its not a bug this  a feature request.
however you can make the consitency arguemnt that takashi has made in https://bugs.launchpad.net/nova/+bug/1960247 to
position it as a bug.

technially the set of varible that are aviale however are not defined as part of the api so you should not assume user_id
is always avaiable.

usering custom policy shoudl also be done sparingly. for a private cloud this
is fine but it woudl be an interoperablity issue to do this in a public cloud.
server are own by projects not users so we woudl expect anyone in the porjec to be able to suspend or resume it in
a could by default.

you obviously have other requirements which is fine and why we support custom policy but this is really a feature request.
its a trivial one for the most part and we may consider trating this as a bug but i think we would have to dicuss this at
the nova team meeting before agreeing to trat this as a backportable bugfix rather then a new feature.

i have triaged the bug as whishlist for now.
> 
> Cheers, Massimo
> 
> 
> 
> On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
> 
> > Quickly checking the current code, it seems support for user_id was
> > introduced to only suspend api[1]
> >  [1] https://review.opendev.org/c/openstack/nova/+/353344
> > 
> > I've opened a bug for nova[2] because supporting consistent rules for
> > suspend and resume
> > makes clear sense to me.
> >  [2] https://bugs.launchpad.net/nova/+bug/1960247
> > 
> > 
> > On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <
> > massimo.sgaravatto at gmail.com> wrote:
> > 
> > > Dear all
> > > 
> > > I am running a Xena installation
> > > 
> > > I have modified the nova policy fail so that certain operations can be
> > > done only by the user who created the instance, or by the administrator
> > > This [*] is my policy.yaml file.
> > > While the suspend operation works as intended (I can suspend only my
> > > instances and I am not allowed to suspend an instance created by another
> > > user) I am not able to resume an instance that I own and that I have
> > > previously suspended.
> > > I get this error:
> > > 
> > > ERROR (Forbidden): Policy doesn't allow
> > > os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403)
> > > (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
> > > 
> > > Only removing the line:
> > > 
> > > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
> > > user_id:%(user_id)s"
> > > 
> > > from the policy file, I am able to resume the instance.
> > > 
> > > I am not able to understand what is wrong with that policy. Any hints ?
> > > 
> > > Thanks, Massimo
> > > 
> > > 
> > > [*]
> > > 
> > > # Pause a server
> > > # POST  /servers/{server_id}/action (pause)
> > > # Intended scope(s): system, project
> > > "os_compute_api:os-pause-server:pause": "rule:admin_api or
> > > user_id:%(user_id)s"
> > > 
> > > # Delete a server
> > > # DELETE  /servers/{server_id}
> > > # Intended scope(s): system, project
> > > "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
> > > 
> > > # Resize a server
> > > # POST  /servers/{server_id}/action (resize)
> > > # Intended scope(s): system, project
> > > "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"
> > > 
> > > # Rebuild a server
> > > # POST  /servers/{server_id}/action (rebuild)
> > > # Intended scope(s): system, project
> > > "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"
> > > 
> > > # Stop a server
> > > # POST  /servers/{server_id}/action (os-stop)
> > > # Intended scope(s): system, project
> > > "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
> > > 
> > > # Resume suspended server
> > > # POST  /servers/{server_id}/action (resume)
> > > # Intended scope(s): system, project
> > > "os_compute_api:os-suspend-server:resume": "rule:admin_api or
> > > user_id:%(user_id)s"
> > > 
> > > # Suspend server
> > > # POST  /servers/{server_id}/action (suspend)
> > > # Intended scope(s): system, project
> > > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
> > > user_id:%(user_id)s"
> > > 
> > 



From gmann at ghanshyammann.com  Mon Feb  7 17:29:03 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 07 Feb 2022 11:29:03 -0600
Subject: [nova][ops] Problem with nova policies for resume operation
In-Reply-To: <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com>
References: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
 <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>
 <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>
 <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com>
Message-ID: <17ed53b5743.dee52ed373697.6491334868007810351@ghanshyammann.com>

 ---- On Mon, 07 Feb 2022 11:10:37 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote ----
 >  > Thanks
 >  > Actually in the past support for user_id in the resume operation worked as expectedE.g. I have a train installation where I defined this rule in the policy.json file:
 >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s",
 >  > 
 >  > and it works
 >  > Cheers, Massimo
 >  > 
 >  > 
 >  > On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
 >  > Quickly checking the current code, it seems support for user_id was introduced to only suspend api[1] [1] https://review.opendev.org/c/openstack/nova/+/353344
 >  > I've opened a bug for nova[2] because supporting consistent rules for suspend and resumemakes clear sense to me.
 >  >  [2] https://bugs.launchpad.net/nova/+bug/1960247
 >  > 
 >  > On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote:
 >  > Dear all
 >  > 
 >  > I am running a Xena installation
 >  > I have modified the nova policy fail so that certain operations can be done only by the user who created the instance, or by the administratorThis [*] is my policy.yaml file.While the suspend operation works as intended (I can suspend only my instances and I am not allowed to suspend an instance created by another user) I am not able to resume an instance that I own and that I have previously suspended.I get this error:
 >  > ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
 >  > 
 >  > Only removing the line:
 >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
 >  > from the policy file, I am able to resume the instance.
 >  > I am not able to understand what is wrong with that policy. Any hints ?

And as long as your user belong to same project instance is booted for then you should be able
to resume instance by any user of that project even you suspended it with other user of same project
and user_id policy enmforcement in suspend policy. Or you suspended server with user of other project
and trying to resume by other project?

-gmann

 > 
 > I think we had the same conversation in June 2020 also[1].
 > 
 > Nova does not restrict the policy by user_id except keypairs API. We have kept it for a few of the
 > destructive actions (for backwards compatibility) and intent to remove them too in future. I remember
 > we discussed this in 2016 but I could not find the ML thread for that but
 > the consensus that time was we do not intend to support user_id based restriction permission in the API.
 > 
 > This is the spec where we kept the user_id support for destructive actions and the reason.
 > 
 > https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html
 > 
 > As we are moving our policy to new defaults (with new direction), after that we should discuss to remove all the user_id
 > enforcement support except keypair. But defiantly should not extend it for any other action.
 > 
 > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015273.html
 > 
 > -gmann
 > 
 >  > Thanks, Massimo
 >  > 
 >  > [*]
 >  > # Pause a server
 >  > # POST  /servers/{server_id}/action (pause)
 >  > # Intended scope(s): system, project
 >  > "os_compute_api:os-pause-server:pause": "rule:admin_api or user_id:%(user_id)s"
 >  > 
 >  > # Delete a server
 >  > # DELETE  /servers/{server_id}
 >  > # Intended scope(s): system, project
 >  > "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
 >  > 
 >  > # Resize a server
 >  > # POST  /servers/{server_id}/action (resize)
 >  > # Intended scope(s): system, project
 >  > "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"
 >  > 
 >  > # Rebuild a server
 >  > # POST  /servers/{server_id}/action (rebuild)
 >  > # Intended scope(s): system, project
 >  > "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"
 >  > 
 >  > # Stop a server
 >  > # POST  /servers/{server_id}/action (os-stop)
 >  > # Intended scope(s): system, project
 >  > "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
 >  > 
 >  > # Resume suspended server
 >  > # POST  /servers/{server_id}/action (resume)
 >  > # Intended scope(s): system, project
 >  > "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"
 >  > 
 >  > # Suspend server
 >  > # POST  /servers/{server_id}/action (suspend)
 >  > # Intended scope(s): system, project
 >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
 >  > 
 > 
 > 


From smooney at redhat.com  Mon Feb  7 17:32:10 2022
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 07 Feb 2022 17:32:10 +0000
Subject: [nova][ops] Problem with nova policies for resume operation
In-Reply-To: <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com>
References: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
 <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>
 <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>
 <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com>
Message-ID: <4a85184cc9a5044a81df2d1f4c41793380cc1cfd.camel@redhat.com>

On Mon, 2022-02-07 at 11:10 -0600, Ghanshyam Mann wrote:
>  ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote ----
>  > Thanks
>  > Actually in the past support for user_id in the resume operation worked as expectedE.g. I have a train installation where I defined this rule in the policy.json file:
>  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s",
>  > 
>  > and it works
>  > Cheers, Massimo
>  > 
>  > 
>  > On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
>  > Quickly checking the current code, it seems support for user_id was introduced to only suspend api[1] [1] https://review.opendev.org/c/openstack/nova/+/353344
>  > I've opened a bug for nova[2] because supporting consistent rules for suspend and resumemakes clear sense to me.
>  >  [2] https://bugs.launchpad.net/nova/+bug/1960247
>  > 
>  > On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote:
>  > Dear all
>  > 
>  > I am running a Xena installation
>  > I have modified the nova policy fail so that certain operations can be done only by the user who created the instance, or by the administratorThis [*] is my policy.yaml file.While the suspend operation works as intended (I can suspend only my instances and I am not allowed to suspend an instance created by another user) I am not able to resume an instance that I own and that I have previously suspended.I get this error:
>  > ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
>  > 
>  > Only removing the line:
>  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
>  > from the policy file, I am able to resume the instance.
>  > I am not able to understand what is wrong with that policy. Any hints ?
> 
> I think we had the same conversation in June 2020 also[1].
> 
> Nova does not restrict the policy by user_id except keypairs API. We have kept it for a few of the
> destructive actions (for backwards compatibility) and intent to remove them too in future. I remember
> we discussed this in 2016 but I could not find the ML thread for that but
> the consensus that time was we do not intend to support user_id based restriction permission in the API.
> 
> This is the spec where we kept the user_id support for destructive actions and the reason.
> 
> https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html
> 
> As we are moving our policy to new defaults (with new direction), after that we should discuss to remove all the user_id
> enforcement support except keypair. But defiantly should not extend it for any other action.
> 
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015273.html

thanks i had forgot about that spec entirly.
i have marked the bug as opinion and whistlist
https://bugs.launchpad.net/nova/+bug/1960247
we can continue to disucss it but i think we would need to come to a concenus about this and given the previous spec likely
treat this as a spec/feature not a bug. we certenly woudl have to consider how this woudl work with secure rbac and if this
aligns with the project direction as a whole.

> 
> -gmann
> 
>  > Thanks, Massimo
>  > 
>  > [*]
>  > # Pause a server
>  > # POST  /servers/{server_id}/action (pause)
>  > # Intended scope(s): system, project
>  > "os_compute_api:os-pause-server:pause": "rule:admin_api or user_id:%(user_id)s"
>  > 
>  > # Delete a server
>  > # DELETE  /servers/{server_id}
>  > # Intended scope(s): system, project
>  > "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
>  > 
>  > # Resize a server
>  > # POST  /servers/{server_id}/action (resize)
>  > # Intended scope(s): system, project
>  > "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"
>  > 
>  > # Rebuild a server
>  > # POST  /servers/{server_id}/action (rebuild)
>  > # Intended scope(s): system, project
>  > "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"
>  > 
>  > # Stop a server
>  > # POST  /servers/{server_id}/action (os-stop)
>  > # Intended scope(s): system, project
>  > "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
>  > 
>  > # Resume suspended server
>  > # POST  /servers/{server_id}/action (resume)
>  > # Intended scope(s): system, project
>  > "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"
>  > 
>  > # Suspend server
>  > # POST  /servers/{server_id}/action (suspend)
>  > # Intended scope(s): system, project
>  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
>  > 
> 



From franck.vedel at univ-grenoble-alpes.fr  Mon Feb  7 17:42:17 2022
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Mon, 7 Feb 2022 18:42:17 +0100
Subject: [kolla-ansible][nova] volume creation time
In-Reply-To: <20220207095528.Horde.TLJ23YmLfAbOaPxt2gc-22M@webmail.nde.ag>
References: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr>
 <CAOAKi8wQ=MafWcRwh1duyuoGtF07j+ctQBma3vG25WTKCs8yYA@mail.gmail.com>
 <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr>
 <CAOAKi8w-XN7zpqbFME0mrVW8+wv+LKO7fPhvxOTAPS9R8Ppcqg@mail.gmail.com>
 <2143074A-B762-4455-ADD4-86A001919D8D@univ-grenoble-alpes.fr>
 <20220207095528.Horde.TLJ23YmLfAbOaPxt2gc-22M@webmail.nde.ag>
Message-ID: <F866FF47-A64F-4932-BD97-E9F2A875F1B3@univ-grenoble-alpes.fr>

Hi Eugen,
thanks for your help
We have 3 servers (s1, s2 , s3) and an iscsi bay attached on s3.
Multinode: 
[control]
s1
s2

[compute]
s1
s2
s3

[storage]
s3

on s1: more /etc/kolla/globals.yml
...
enable_cinder: "yes"
enable_cinder_backend_iscsi: "yes"
enable_cinder_backend_lvm: ? yes"
enable_iscsid: ? yes"
cinder_volume_group: "cinder-volumes ?
...
enable_glance_image_cache: "yes"
glance_cache_max_size: "21474836480"
glance_file_datadir_volume: ? /images/? 
...

on s3:  /images is on the iscsi bay 
mount |grep images
/dev/mapper/VG--IMAGES-LV--IMAGES on /images type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=1024,swidth=1024,noquota)

lsblk
sdf                                                                             8:80   0   500G  0 disk
??mpathc                                                                      253:3    0   500G  0 mpath
  ??mpathc1                                                                   253:4    0   500G  0 part
    ??VG--IMAGES-LV--IMAGES                                                   253:5    0   500G  0 lvm   /images


ls -l /images:
drwxr-x---. 5 42415 42415 4096  6 f?vr. 18:40 image-cache
drwxr-x---. 2 42415 42415 4096  4 f?vr. 15:16 images
drwxr-x---. 2 42415 42415    6 22 nov.  12:03 staging
drwxr-x---. 2 42415 42415    6 22 nov.  12:03 tasks_work_dir

ls -l /images/image-cache
total 71646760
-rw-r-----. 1 42415 42415   360841216  2 d?c.  11:52 3e3aada8-7610-4c55-b116-a12db68f8ea4
-rw-r-----. 1 42415 42415   237436928 28 nov.  16:56 6419642b-fcbd-4e5d-9c77-46a48d2af93f
-rw-r-----. 1 42415 42415 10975379456 26 nov.  14:59 7490e914-8001-4d56-baea-fabf80f425e1
-rw-r-----. 1 42415 42415 21474836480 22 nov.  16:46 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5
-rw-r-----. 1 42415 42415  2694512640 15 d?c.  18:07 890fd2e8-2fac-42c6-956b-6b10f2253a56
-rw-r-----. 1 42415 42415 12048400384  1 d?c.  17:04 9a235763-ff0c-40fd-9a8d-7cdca3d3e9ce
-rw-r-----. 1 42415 42415  5949227008 15 d?c.  20:41 9cbba37b-1de1-482a-87f2-631d2143cd46
-rw-r-----. 1 42415 42415   566994944  6 d?c.  12:32 b6e29dd9-a66d-4569-a222-6fc0bd9b1b11
-rw-r-----. 1 42415 42415   578748416  2 d?c.  11:24 c40953ee-4b39-43a5-8f6c-b48a046c38e9
-rw-r-----. 1 42415 42415    16300544 27 janv. 12:19 c88630c7-a7c6-44ff-bfa0-e5af4b1720e3
-rw-r-----. 1 42415 42415       12288  6 f?vr. 18:40 cache.db
-rw-r-----. 1 42415 42415 12324503552  1 d?c.  07:50 e0d4fddd-5aa7-4177-a1d6-e6b4c56f12e8
-rw-r-----. 1 42415 42415  6139084800 22 nov.  15:05 eda93204-9846-4216-a6e8-c29977fdcf2f
-rw-r-----. 1 42415 42415           0 22 nov.  12:03 image_cache_db_init
drwxr-x---. 2 42415 42415           6 27 janv. 12:19 incomplete
drwxr-x---. 2 42415 42415           6 22 nov.  12:03 invalid
drwxr-x---. 2 42415 42415           6 22 nov.  12:03 queue

on s1
openstack image list
+--------------------------------------+-----------------------------+--------+
| ID                                   | Name                        | Status |
+--------------------------------------+-----------------------------+--------+
?..
| 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5 | rocky8.4                    | active |
?.
| 7490e914-8001-4d56-baea-fabf80f425e1 | win10_2104                  | active |
?.
+???????????????????+-----------------------------+????+


openstack image show 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5
disk_format      | raw

when I try to add an instance from this image (2G RAM, 40G HDD): 
[Error : Build of instance baa06bef-9628-407f-8bae-500ef7bce065 aborted: Volume be0f28eb-1045-4687-8bdb-5a6d385be6fa did not finish being created even after we waited 187 seconds or 61 attempts. And its status is downloading.

it?s impossible. I need to add the volume from image first, and after add instance from volume.

Is it normal ? 


Franck 

> Le 7 f?vr. 2022 ? 10:55, Eugen Block <eblock at nde.ag> a ?crit :
> 
> Hi Franck,
> 
> although it's a different topic than your original question I wanted to comment on the volume creation time (maybe a new thread would make sense). What is your storage back end? If it is ceph, are your images in raw format? Otherwise cinder has to download the image from glance (to /var/lib/cinder/conversion) and convert it, then upload it back to ceph. It's similar with nova, nova stores base images in /var/lib/nova/instances/_base to prevent the compute nodes from downloading it every time. This may save some time for the download, but the upload has to happen anyway. And if you don't use shared storage for nova (e.g. for live-migration) you may encounter that some compute nodes are quicker creating an instance because they only have to upload, others will first have to download, convert and then upload it.
> 
> You would see the conversion in the logs of cinder:
> 
> INFO cinder.image.image_utils [req-f2062570-4006-464b-a1f5-d0d5ac34670d d71f59600f1c40c394022738d4864915 31b9b4900a4d4bdaabaf263d0b4021be - - -] Converted 2252.00 MB image at 757.52 MB/s
> 
> Hope this helps.
> 
> Eugen
> 
> 
> Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:
> 
>> Sunday morning: my openstack works?. OUF.
>> the "kolla-ansible -i multimode mariadb_recovery"  command (which is magic anyway) fixed the problem and then the mariadb and nova containers started.
>> Once solved the problems between my serv3 and the iscsi bay, restart the container glance, everything seems to work.
>> 
>>> 4 minutes to create a 20GB empty volume seems too long to me. For an actual 20GB image, it's going to depend on the speed of the backing storage tech.
>> 4 minutes is for a volume from an image. I will see this problem next summer , I will retry to change the MTU value.
>> 
>> Thanks a lot, really
>> 
>> 
>> Franck
>> 
>>> Le 5 f?vr. 2022 ? 17:08, Laurent Dumont <laurentfdumont at gmail.com> a ?crit :
>>> 
>>> Any chance to revert back switches + server? That would indicate that MTU was the issue.
>>> Dont ping the iscsi bay, ping between the controllers in Openstack, they are the ones running mariadb/galera.
>>> Since the icmp packets are small, it might not trigger the MTU issues. Can you try something like "ping -s 8972 -M do -c 4 $mariadb_host_2" from $ mariadb_host_1?
>>> What is your network setup on the servers? Two ports in a bond? Did you change both physical interface MTU + bond interface itself?
>>> 
>>> 4 minutes to create a 20GB empty volume seems too long to me. For an actual 20GB image, it's going to depend on the speed of the backing storage tech.
>>> 
>>> On Sat, Feb 5, 2022 at 1:51 AM Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>> Thanks for your help.
>>> 
>>> 
>>>> What was the starting value for MTU?
>>> 1500
>>>> What was the starting value changed to for MTU?
>>> 9000
>>>> Can ping between all your controllers?
>>> yes, all container starts except nova-conductor, nova-scheduler, maraidb
>>> 
>>> 
>>>> Do you just have two controllers running mariadb?
>>> yes
>>>> How did you change MTU?
>>> 
>>> On the 3 servers:
>>> nmcli connection modify team0-port1 802-3-ethernet.mtu 9000
>>> nmcli connection modify team1-port2 802-3-ethernet.mtu 9000
>>> nmcli connection modify type team0 team.runner lack ethernet.mtu 9000
>>> nmcli con down team0
>>> nmcli con down team1
>>> 
>>> 
>>>> Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)
>>> I didn?t change Mtu on network (switches) , but ping -s 10.0.5.117 (iscsi bay) was working from serv3.
>>> 
>>> I changed the value of the mtu because the creation of the volumes takes a lot of time I find (4 minutes for 20G, which is too long for what I want to do, the patience of the students decreases with the years)
>>> 
>>> Franck
>>> 
>>>> Le 4 f?vr. 2022 ? 23:12, Laurent Dumont <laurentfdumont at gmail.com <mailto:laurentfdumont at gmail.com>> a ?crit :
>>>> 
>>>> What was the starting value for MTU?
>>>> What was the starting value changed to for MTU?
>>>> Can ping between all your controllers?
>>>> Do you just have two controllers running mariadb?
>>>> How did you change MTU?
>>>> Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)
>>>> 4567 seems to be the port for galera (clustering for mariadb) <>
>>>> On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>>> Hello,
>>>> I am in an emergency situation, quite catastrophic situation because I do not know what to do.
>>>> 
>>>> I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was doing so well?
>>>> 
>>>> 
>>>> A network admin came to me and told me to change an MTU on the cards. I knew it shouldn't be done...I shouldn't have done it.
>>>> I did it.
>>>> Of course, it didn't work as expected. I went back to my starting configuration and there I have a big problem with mariadb which is set up on serv1 and serv2.
>>>> 
>>>> Here are my errors:
>>>> 
>>>> 
>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
>>>> 	 at gcomm/src/pc.cpp:connect():160
>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out)
>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': <> -110 (Connection timed out)
>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed out
>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567 <>) failed: 7
>>>> 2022-02-04 17:40:36 0 [ERROR] Aborting
>>>> 
>>>> 
>>>> 
>>>> 
>>>> I do not know what to do. My installation is done with kolla-ansible, mariadb docker restarts every 30 seconds.
>>>> 
>>>> Can the "kolla-ansible reconfigure mariadb" command be a solution?
>>>> Could the command "kolla-ansible mariadb recovery" be a solution?
>>>> 
>>>> Thanks in advance if you can help me.
>>>> 
>>>> 
>>>> 
>>>> Franck
>>>> 
>>>> 
>>> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/ed1c8f32/attachment-0001.htm>

From massimo.sgaravatto at gmail.com  Mon Feb  7 18:08:36 2022
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Mon, 7 Feb 2022 19:08:36 +0100
Subject: [nova][ops] Problem with nova policies for resume operation
In-Reply-To: <4a85184cc9a5044a81df2d1f4c41793380cc1cfd.camel@redhat.com>
References: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
 <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>
 <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>
 <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com>
 <4a85184cc9a5044a81df2d1f4c41793380cc1cfd.camel@redhat.com>
Message-ID: <CALaZjRFg7MNSYpWj9C6s7WG9R_70HN_Dq9O1HEOJrm5q8RPAeg@mail.gmail.com>

Ok, now I remember the discussion.
So:

- I am aware that support for user_id is implemented only for destructive
operations
- I am aware that such support will be removed

Indeed in my policy files I am listing only destructive operations, apart
from this resume operation (I can't remember why it is there).

And I was wrong when I said that the support for user_id for resume worked
in Train.
I have just double checked and it seems to me that there is just a
different behavior:

- In Train if you have:

"os_compute_api:os-suspend-server:resume": "rule:admin_api or
user_id:%(user_id)s",

you are able to resume your instance but you are able also to resume
instances owned by other users of the same project

- In Xena if you have:

"os_compute_api:os-suspend-server:resume": "rule:admin_api or
user_id:%(user_id)s"

you are not even able to resume your instances


So:
1: I am going to remove the user_id based policy for the resume operation
in the policy file
2: I personally don't really need to have issue #1960247 addressed
3: Sorry for the noise !

Cheers, Massimo

On Mon, Feb 7, 2022 at 6:32 PM Sean Mooney <smooney at redhat.com> wrote:

> On Mon, 2022-02-07 at 11:10 -0600, Ghanshyam Mann wrote:
> >  ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto <
> massimo.sgaravatto at gmail.com> wrote ----
> >  > Thanks
> >  > Actually in the past support for user_id in the resume operation
> worked as expectedE.g. I have a train installation where I defined this
> rule in the policy.json file:
> >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
> user_id:%(user_id)s",
> >  >
> >  > and it works
> >  > Cheers, Massimo
> >  >
> >  >
> >  > On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <tkajinam at redhat.com>
> wrote:
> >  > Quickly checking the current code, it seems support for user_id was
> introduced to only suspend api[1] [1]
> https://review.opendev.org/c/openstack/nova/+/353344
> >  > I've opened a bug for nova[2] because supporting consistent rules for
> suspend and resumemakes clear sense to me.
> >  >  [2] https://bugs.launchpad.net/nova/+bug/1960247
> >  >
> >  > On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <
> massimo.sgaravatto at gmail.com> wrote:
> >  > Dear all
> >  >
> >  > I am running a Xena installation
> >  > I have modified the nova policy fail so that certain operations can
> be done only by the user who created the instance, or by the
> administratorThis [*] is my policy.yaml file.While the suspend operation
> works as intended (I can suspend only my instances and I am not allowed to
> suspend an instance created by another user) I am not able to resume an
> instance that I own and that I have previously suspended.I get this error:
> >  > ERROR (Forbidden): Policy doesn't allow
> os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403)
> (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
> >  >
> >  > Only removing the line:
> >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
> user_id:%(user_id)s"
> >  > from the policy file, I am able to resume the instance.
> >  > I am not able to understand what is wrong with that policy. Any hints
> ?
> >
> > I think we had the same conversation in June 2020 also[1].
> >
> > Nova does not restrict the policy by user_id except keypairs API. We
> have kept it for a few of the
> > destructive actions (for backwards compatibility) and intent to remove
> them too in future. I remember
> > we discussed this in 2016 but I could not find the ML thread for that but
> > the consensus that time was we do not intend to support user_id based
> restriction permission in the API.
> >
> > This is the spec where we kept the user_id support for destructive
> actions and the reason.
> >
> >
> https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html
> >
> > As we are moving our policy to new defaults (with new direction), after
> that we should discuss to remove all the user_id
> > enforcement support except keypair. But defiantly should not extend it
> for any other action.
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015273.html
>
> thanks i had forgot about that spec entirly.
> i have marked the bug as opinion and whistlist
> https://bugs.launchpad.net/nova/+bug/1960247
> we can continue to disucss it but i think we would need to come to a
> concenus about this and given the previous spec likely
> treat this as a spec/feature not a bug. we certenly woudl have to consider
> how this woudl work with secure rbac and if this
> aligns with the project direction as a whole.
>
> >
> > -gmann
> >
> >  > Thanks, Massimo
> >  >
> >  > [*]
> >  > # Pause a server
> >  > # POST  /servers/{server_id}/action (pause)
> >  > # Intended scope(s): system, project
> >  > "os_compute_api:os-pause-server:pause": "rule:admin_api or
> user_id:%(user_id)s"
> >  >
> >  > # Delete a server
> >  > # DELETE  /servers/{server_id}
> >  > # Intended scope(s): system, project
> >  > "os_compute_api:servers:delete": "rule:admin_api or
> user_id:%(user_id)s"
> >  >
> >  > # Resize a server
> >  > # POST  /servers/{server_id}/action (resize)
> >  > # Intended scope(s): system, project
> >  > "os_compute_api:servers:resize": "rule:admin_api or
> user_id:%(user_id)s"
> >  >
> >  > # Rebuild a server
> >  > # POST  /servers/{server_id}/action (rebuild)
> >  > # Intended scope(s): system, project
> >  > "os_compute_api:servers:rebuild": "rule:admin_api or
> user_id:%(user_id)s"
> >  >
> >  > # Stop a server
> >  > # POST  /servers/{server_id}/action (os-stop)
> >  > # Intended scope(s): system, project
> >  > "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
> >  >
> >  > # Resume suspended server
> >  > # POST  /servers/{server_id}/action (resume)
> >  > # Intended scope(s): system, project
> >  > "os_compute_api:os-suspend-server:resume": "rule:admin_api or
> user_id:%(user_id)s"
> >  >
> >  > # Suspend server
> >  > # POST  /servers/{server_id}/action (suspend)
> >  > # Intended scope(s): system, project
> >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or
> user_id:%(user_id)s"
> >  >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/8429d489/attachment.htm>

From gmann at ghanshyammann.com  Mon Feb  7 18:48:27 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 07 Feb 2022 12:48:27 -0600
Subject: [nova][ops] Problem with nova policies for resume operation
In-Reply-To: <CALaZjRFg7MNSYpWj9C6s7WG9R_70HN_Dq9O1HEOJrm5q8RPAeg@mail.gmail.com>
References: <CALaZjRG+Z-Nd+yjb4O6soVJbM1goX5b+bjv5Oa8xUrVsHdz8BQ@mail.gmail.com>
 <CAL_crJQxk-vNjaUJtqjZnXbLcgHVxwJ6BoY=cYoWy4MWkjTkzg@mail.gmail.com>
 <CALaZjRG80z648ZttM_AaJ6BMg49FXxZqSRLwZ_1-8sqqJp-Kww@mail.gmail.com>
 <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com>
 <4a85184cc9a5044a81df2d1f4c41793380cc1cfd.camel@redhat.com>
 <CALaZjRFg7MNSYpWj9C6s7WG9R_70HN_Dq9O1HEOJrm5q8RPAeg@mail.gmail.com>
Message-ID: <17ed5840b1d.d942645878061.3862190353728356128@ghanshyammann.com>

 ---- On Mon, 07 Feb 2022 12:08:36 -0600 Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote ----
 > Ok, now I remember the discussion.So:
 > - I am aware that support for user_id is implemented only for destructive operations- I am aware that such support will be removed
 > Indeed in my policy files I am listing only destructive operations, apart from this resume operation (I can't remember why it is there).
 > And I was wrong when I said that the support for user_id for resume worked in Train.I have just double checked and it seems to me that there is just a different behavior:
 > - In Train if you have: 
 > "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s",
 > 
 > you are able to resume your instance but you are able also to resume instances owned by other users of the same project
 > - In Xena if you have:
 > "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"
 > 
 > you are not even able to resume your instances

In train, we were not even passing the server's project_id as target to oslo policy and after that
we started passign it so that admin or owner or server (owner means any user in that project)
can be allowed
- https://github.com/openstack/nova/blob/stable/ussuri/nova/api/openstack/compute/suspend_server.py#L58

 > 
 > So:1: I am going to remove the user_id based policy for the resume operation in the policy file

+1.

-gmann

2: I personally don't really need to have issue #1960247 addressed3: Sorry for the noise !
 > Cheers, Massimo 
 > On Mon, Feb 7, 2022 at 6:32 PM Sean Mooney <smooney at redhat.com> wrote:
 > On Mon, 2022-02-07 at 11:10 -0600, Ghanshyam Mann wrote:
 > >  ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote ----
 > >  > Thanks
 > >  > Actually in the past support for user_id in the resume operation worked as expectedE.g. I have a train installation where I defined this rule in the policy.json file:
 > >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s",
 > >  > 
 > >  > and it works
 > >  > Cheers, Massimo
 > >  > 
 > >  > 
 > >  > On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
 > >  > Quickly checking the current code, it seems support for user_id was introduced to only suspend api[1] [1] https://review.opendev.org/c/openstack/nova/+/353344
 > >  > I've opened a bug for nova[2] because supporting consistent rules for suspend and resumemakes clear sense to me.
 > >  >  [2] https://bugs.launchpad.net/nova/+bug/1960247
 > >  > 
 > >  > On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote:
 > >  > Dear all
 > >  > 
 > >  > I am running a Xena installation
 > >  > I have modified the nova policy fail so that certain operations can be done only by the user who created the instance, or by the administratorThis [*] is my policy.yaml file.While the suspend operation works as intended (I can suspend only my instances and I am not allowed to suspend an instance created by another user) I am not able to resume an instance that I own and that I have previously suspended.I get this error:
 > >  > ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)
 > >  > 
 > >  > Only removing the line:
 > >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
 > >  > from the policy file, I am able to resume the instance.
 > >  > I am not able to understand what is wrong with that policy. Any hints ?
 > > 
 > > I think we had the same conversation in June 2020 also[1].
 > > 
 > > Nova does not restrict the policy by user_id except keypairs API. We have kept it for a few of the
 > > destructive actions (for backwards compatibility) and intent to remove them too in future. I remember
 > > we discussed this in 2016 but I could not find the ML thread for that but
 > > the consensus that time was we do not intend to support user_id based restriction permission in the API.
 > > 
 > > This is the spec where we kept the user_id support for destructive actions and the reason.
 > > 
 > > https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html
 > > 
 > > As we are moving our policy to new defaults (with new direction), after that we should discuss to remove all the user_id
 > > enforcement support except keypair. But defiantly should not extend it for any other action.
 > > 
 > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015273.html
 > 
 > thanks i had forgot about that spec entirly.
 > i have marked the bug as opinion and whistlist
 > https://bugs.launchpad.net/nova/+bug/1960247
 > we can continue to disucss it but i think we would need to come to a concenus about this and given the previous spec likely
 > treat this as a spec/feature not a bug. we certenly woudl have to consider how this woudl work with secure rbac and if this
 > aligns with the project direction as a whole.
 > 
 > > 
 > > -gmann
 > > 
 > >  > Thanks, Massimo
 > >  > 
 > >  > [*]
 > >  > # Pause a server
 > >  > # POST  /servers/{server_id}/action (pause)
 > >  > # Intended scope(s): system, project
 > >  > "os_compute_api:os-pause-server:pause": "rule:admin_api or user_id:%(user_id)s"
 > >  > 
 > >  > # Delete a server
 > >  > # DELETE  /servers/{server_id}
 > >  > # Intended scope(s): system, project
 > >  > "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
 > >  > 
 > >  > # Resize a server
 > >  > # POST  /servers/{server_id}/action (resize)
 > >  > # Intended scope(s): system, project
 > >  > "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"
 > >  > 
 > >  > # Rebuild a server
 > >  > # POST  /servers/{server_id}/action (rebuild)
 > >  > # Intended scope(s): system, project
 > >  > "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"
 > >  > 
 > >  > # Stop a server
 > >  > # POST  /servers/{server_id}/action (os-stop)
 > >  > # Intended scope(s): system, project
 > >  > "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"
 > >  > 
 > >  > # Resume suspended server
 > >  > # POST  /servers/{server_id}/action (resume)
 > >  > # Intended scope(s): system, project
 > >  > "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"
 > >  > 
 > >  > # Suspend server
 > >  > # POST  /servers/{server_id}/action (suspend)
 > >  > # Intended scope(s): system, project
 > >  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
 > >  > 
 > > 
 > 
 > 


From opensrloo at gmail.com  Mon Feb  7 20:17:56 2022
From: opensrloo at gmail.com (Ruby Loo)
Date: Mon, 7 Feb 2022 15:17:56 -0500
Subject: [ironic]Anaconda deploy interface config
In-Reply-To: <CACkzpE4on7MutKbBjRfE_zshdDN9r+enRsNigmJHs55kzxbR3A@mail.gmail.com>
References: <CACkzpE4A11he8EDmF-tDVOb2ZMR0FnaHogpBOq9EpWdYZ36ahg@mail.gmail.com>
 <CAJkGiNuPMD-wMJpn_=eMK63j9SBuYOOmTQGS9HsVh8XYH5aQWw@mail.gmail.com>
 <CACkzpE4on7MutKbBjRfE_zshdDN9r+enRsNigmJHs55kzxbR3A@mail.gmail.com>
Message-ID: <CAJkGiNtOYN2iEGkhWExOe7ODXtD_D3N8oKrcsjDM+nMmxWzr4g@mail.gmail.com>

On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard <cbouchar at redhat.com> wrote:

> Hi Ruby:
>
> I couldn't use your whole changeset since it introduced a different
> issue.  With your patch, I was seeing the
> following error and it never reached the code creating squashfs.img as a
> directory.  So I removed the patch
> and only applied the pxe_util.py changes in cache_ramdisk_kernel() and
> I've made further progress.
>
> *| last_error | Failed to prepare to deploy: Cannot validate driver
> deploy. Some parameters were missing in node's instance_info. Missing are:
> ['root_gb'] |*
>
> Is this root_gb a new requirement?  More background: At the moment, I
> don't have baremetal devices and I'm starting my work by
> using VMs bifrost created for me.  Also I'm using the xena branch of
> bifrost/ironic.
>
> Carol
>
>
root_gb is old. I suspect bifrost doesn't use/need that information. If all
the info you have for using the anaconda deploy interface is in the OS
image or via configs, you'll be ok. Although when that patch merges, it'll
break your use case if the VM-ironic-node doesn't have
instance_info['root_gb'] specified. That code is getting triggered via:

   PXEAnacondaDeploy.prepare(): node.instance_info =
deploy_utils.build_instance_info_for_deploy(
                task).
   which causes this code to be invoked [1]

To get around it, you could set the ironic node's instance_info to have
'root_gb' = <some value>. Eg: "openstack baremetal node set <node>
--instance-info root_gb=10"

It seems to me that we might want to modify the code to handle this (any
takers?)

--ruby

[1]:
https://opendev.org/openstack/ironic/src/commit/a4a89d6b20a03e692e0550e3a34a97c7a63f266c/ironic/drivers/modules/deploy_utils.py#L866-L870



On Mon, Feb 7, 2022 at 11:56 AM Ruby Loo <opensrloo at gmail.com> wrote:
>
>> Hi Carol,
>>
>> Thanks for reporting this! It is a bug :-( The fix is in
>> https://review.opendev.org/c/openstack/ironic/+/827924.
>>
>> --ruby
>>
>> On Fri, Feb 4, 2022 at 11:44 AM Carol Bouchard <cbouchar at redhat.com>
>> wrote:
>>
>>> Ironic folks:
>>>
>>> I'm trying to spawn a RHEL7 image using a kickstart file and having
>>> issues with stage2 file.
>>> First I used bifrost to initially setup a couple of VMs.  (There is no
>>> openstack/glance).
>>> I'm now using one of those VMs to boot up with RHEL7. I changed the VM
>>> config
>>> with the following:
>>>
>>> *| deploy_interface       | anaconda*
>>> * | instance_info          | {'kernel': 'http://myip:8080/RHEL7/vmlinuz
>>> <http://myip:8080/RHEL7/vmlinuz>', 'ramdisk':
>>> 'http://myip:8080/RHEL7/initrd.img <http://myip:8080/RHEL7/initrd.img>',
>>> 'image_source': 'http://myip:8080/RHEL7/initrd.img
>>> <http://myip:8080/RHEL7/initrd.img>', 'stage2':
>>> 'http://myip:8080/RHEL7/squashfs.img
>>> <http://myip:8080/RHEL7/squashfs.img>', 'ks_cfg':
>>> 'http://myip:8080/RHEL7/ks.cfg.template
>>> <http://myip:8080/RHEL7/ks.cfg.template>', 'ks_template':
>>> 'http://myip:8080/RHEL7/ks.cfg.template
>>> <http://myip:8080/RHEL7/ks.cfg.template>'}*
>>>
>>> ironic.conf changes I made are as follows:
>>>
>>> *enabled_deploy_interfaces = direct,ramdisk,anaconda*
>>>
>>> *[anaconda]default_ks_template = file:///etc/ironic/ks.cfg.template*
>>>
>>> The error I'm getting is as follows:
>>>  *$ baremetal node show testvm1 --field last_error*
>>>
>>> *| last_error | Deploy step deploy.deploy failed with IsADirectoryError:
>>> [Errno 21] Is a directory:
>>> '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'.*
>>> Tail end of traceback is as follows:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> * ironic-conductor[]:   ERROR ironic.conductor.utils   File
>>> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/common/pxe_utils.py",
>>> line 1245, in cache_ramdisk_kernel ironic-conductor[]:   ERROR
>>> ironic.conductor.utils     deploy_utils.fetch_images(ctx, TFTPImageCache(),
>>> list(t_pxe_info.values()), ironic-conductor[]:   ERROR
>>> ironic.conductor.utils   File
>>> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/deploy_utils.py",
>>> line 240, in fetch_images ironic-conductor[]:   ERROR
>>> ironic.conductor.utils     cache.fetch_image(href, path, ctx=ctx,
>>> force_raw=force_raw) ironic-conductor[]:   ERROR ironic.conductor.utils
>>> File
>>> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py",
>>> line 120, in fetch_image ironic-conductor[]:   ERROR ironic.conductor.utils
>>>     dest_up_to_date =
>>> _delete_dest_path_if_stale(master_path, ironic-conductor[]:   ERROR
>>> ironic.conductor.utils   File
>>> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py",
>>> line 460, in _delete_dest_path_if_stale ironic-conductor[]:   ERROR
>>> ironic.conductor.utils     os.unlink(dest_path) ironic-conductor[]:   ERROR
>>> ironic.conductor.utils IsADirectoryError: [Errno 21] Is a directory:
>>> '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'*
>>>
>>> Please advise.
>>>
>>> Carol
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/72e6b708/attachment-0001.htm>

From juliaashleykreger at gmail.com  Mon Feb  7 20:30:02 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Mon, 7 Feb 2022 12:30:02 -0800
Subject: [ironic]Anaconda deploy interface config
In-Reply-To: <CAJkGiNtOYN2iEGkhWExOe7ODXtD_D3N8oKrcsjDM+nMmxWzr4g@mail.gmail.com>
References: <CACkzpE4A11he8EDmF-tDVOb2ZMR0FnaHogpBOq9EpWdYZ36ahg@mail.gmail.com>
 <CAJkGiNuPMD-wMJpn_=eMK63j9SBuYOOmTQGS9HsVh8XYH5aQWw@mail.gmail.com>
 <CACkzpE4on7MutKbBjRfE_zshdDN9r+enRsNigmJHs55kzxbR3A@mail.gmail.com>
 <CAJkGiNtOYN2iEGkhWExOe7ODXtD_D3N8oKrcsjDM+nMmxWzr4g@mail.gmail.com>
Message-ID: <CAF7gwdgmCJ4h5xJUgfuEJ8_AJAL7zxzhX+e7rQEoAqjv716-vg@mail.gmail.com>

On Mon, Feb 7, 2022 at 12:21 PM Ruby Loo <opensrloo at gmail.com> wrote:
>
>
>
> On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard <cbouchar at redhat.com> wrote:
>>
[trim]
>> Is this root_gb a new requirement?  More background: At the moment, I don't have baremetal devices and I'm starting my work by
>> using VMs bifrost created for me.  Also I'm using the xena branch of bifrost/ironic.
>>
>> Carol
>>
>
> root_gb is old. I suspect bifrost doesn't use/need that information. If all the info you have for using the anaconda deploy interface is in the OS image or via configs, you'll be ok. Although when that patch merges, it'll break your use case if the VM-ironic-node doesn't have instance_info['root_gb'] specified. That code is getting triggered via:
>
>    PXEAnacondaDeploy.prepare(): node.instance_info = deploy_utils.build_instance_info_for_deploy(
>                 task).
>    which causes this code to be invoked [1]
>
> To get around it, you could set the ironic node's instance_info to have 'root_gb' = <some value>. Eg: "openstack baremetal node set <node> --instance-info root_gb=10"

Yeah, we really need to nuke the requirement, but I could see it still
being needed if someone tries to perform a partition image deployment.
That being said, I don't think we should be requiring it on the
anaconda deployment interface.

Bifrost largely was designed around just deploying whole disk images,
which is why it is not present on the node.

>
> It seems to me that we might want to modify the code to handle this (any takers?)
>
> --ruby
>
[trim]


From rishat.azizov at gmail.com  Sun Feb  6 18:09:31 2022
From: rishat.azizov at gmail.com (=?utf-8?B?0KDQuNGI0LDRgiDQkNC30LjQt9C+0LI=?=)
Date: Mon, 7 Feb 2022 00:09:31 +0600
Subject: OpenStack Trove experimental datastores
Message-ID: <10DE5E61-5A25-49FB-88D7-D918823EF53A@gmail.com>

Hello!

Why were the experimental datastores removed in the Trove OpenStack Victoria release? https://review.opendev.org/c/openstack/trove/+/728419 <https://review.opendev.org/c/openstack/trove/+/728419>

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/2a353df8/attachment.htm>

From anyrude10 at gmail.com  Mon Feb  7 12:47:33 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Mon, 7 Feb 2022 18:17:33 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
Message-ID: <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>

Hi Julia,

Thanks a lot for your responses and support.
To Update on the ongoing issue, I tried deploying the overcloud with your
valuable suggestions i.e by passing "*DhcpAgentNotification: true*" in
ironic-overcloud.yaml
The setup came up successfully, but with this configuration the IP
allocated on the system is one which is being configured while creating the
subnet in openstack.

[image: image.png]

The system is still getting the IP (172.23.3.212) from neutron. The subnet
range was configured as *172.23.3.210-172.23.3.240 *while creating the
provisioning subnet.
The system gets stuck here and no action is performed after this.

Is there any way to resolve this and make successful  provisioning the
baremetal node in *TripleO Train Release* (Since RHOSP 16 was on Train, so
I thought to go with that version for better stability)
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index

I have some queries:


   1. Is passing "*DhcpAgentNotification: true" *enough or do we have to
   make some other changes as well?
   2. Although there are some security concerns specified in the document,
   but Currently I am focusing on the default flat bare metal approach which
   has dedicated interface for bare metal Provisioning. There is one
   composable method approach as well. Keeping aside the security concerns,
   which approach is better and functional?
      1.
      https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
   3. Will moving to upper openstack release version make this deployment
   possible?
      1. If Yes, which release should I go with as till wallaby the
      ironic-overcloud.yml file has no option of including
"*DhcpAgentNotification:
      true*" by default
         1.
         https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml


Looking forward for your valuable feedback/response.

Regards
Anirudh Gupta


On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta <anyrude10 at gmail.com> wrote:

> Hi,
>
> Surely I'll revert the status once it gets deployed.
> Bdw the suspicion is because of Train Release or it is something else?
>
> Regards
> Anirudh Gupta
>
> On Fri, 4 Feb, 2022, 20:29 Julia Kreger, <juliaashleykreger at gmail.com>
> wrote:
>
>>
>>
>> On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta <anyrude10 at gmail.com> wrote:
>>
>>> Hi Julia
>>>
>>> Thanks for your response.
>>>
>>> Earlier I was passing both ironic.yaml and ironic-overcloud.yaml located
>>> at path /usr/share/openstack-tripleo-heat-templates/environments/services/
>>>
>>> My current understanding now says that since I am using OVN, not OVS so
>>> I should pass only ironic-overcloud.yaml in my deployment.
>>>
>>> I am currently on Train Release and my default ironic-overcloud.yaml
>>> file has no such entry
>>> DhcpAgentNotification: true
>>>
>>>
>> I suspect that should work. Let us know if it does.
>>
>>
>>
>>> I would add this there and re deploy the setup.
>>>
>>> Would that be enough to make my deployment successful?
>>>
>>> Regards
>>> Anirudh Gupta
>>>
>>>
>>> On Fri, 4 Feb, 2022, 18:40 Julia Kreger, <juliaashleykreger at gmail.com>
>>> wrote:
>>>
>>>> It is not a matter of disabling OVN, but a matter of enabling the
>>>> dnsmasq service and notifications.
>>>>
>>>>
>>>> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
>>>> may provide some insight.
>>>>
>>>> I suspect if you're using stable/wallaby based branches and it is not
>>>> working, there may need to be a patch backported by the TripleO maintainers.
>>>>
>>>> On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta <anyrude10 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Julia,
>>>>>
>>>>> Thanks for your response.
>>>>> For the overcloud deployment, I am executing the following command:
>>>>>
>>>>> openstack overcloud deploy --templates \
>>>>>     -n /home/stack/templates/network_data.yaml \
>>>>>     -r /home/stack/templates/roles_data.yaml \
>>>>>     -e /home/stack/templates/node-info.yaml \
>>>>>     -e /home/stack/templates/environment.yaml \
>>>>>     -e /home/stack/templates/environments/network-isolation.yaml \
>>>>>     -e /home/stack/templates/environments/network-environment.yaml \
>>>>>     -e
>>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
>>>>> \
>>>>>     -e
>>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>>>>> \
>>>>>     -e
>>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>>>>> \
>>>>>     -e
>>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>>>>> \
>>>>>     -e /home/stack/templates/ironic-config.yaml \
>>>>>     -e
>>>>> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>>>>>     -e
>>>>> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>>>>>     -e /home/stack/containers-prepare-parameter.yaml
>>>>>
>>>>> I can see some OVN related stuff in my roles_data and
>>>>> environments/network-isolation.yaml
>>>>>
>>>>> [stack at undercloud ~]$ grep -inr "ovn"
>>>>> roles_data.yaml:34:    *OVNCMSOptions: "enable-chassis-as-gw"*
>>>>> roles_data.yaml:168:    - *OS::TripleO::Services::OVNDBs*
>>>>> roles_data.yaml:169:    - *OS::TripleO::Services::OVNController*
>>>>> roles_data.yaml:279:    - *OS::TripleO::Services::OVNController*
>>>>> roles_data.yaml:280:    - *OS::TripleO::Services::OVNMetadataAgent*
>>>>> environments/network-isolation.yaml:16:  *OS::TripleO::Network::Ports::OVNDBsVipPort:
>>>>> ../network/ports/vip.yaml*
>>>>>
>>>>> What is your recommendation and how to disable OVN....should I remove
>>>>> it from roles_data.yaml and then render so that it doesn't get generated
>>>>> in environments/network-isolation.yaml
>>>>> Please suggest some pointers.
>>>>>
>>>>> Regards
>>>>> Anirudh Gupta
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> It seems OVN is getting installed in ironic
>>>>>
>>>>>
>>>>> On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger <
>>>>> juliaashleykreger at gmail.com> wrote:
>>>>>
>>>>>> My guess: You're running OVN. You need neutron-dhcp-agent running as
>>>>>> well. OVN disables it by default and OVN's integrated DHCP service does not
>>>>>> support options for network booting.
>>>>>>
>>>>>> -Julia
>>>>>>
>>>>>> On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta <anyrude10 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Team
>>>>>>>
>>>>>>> I am trying to Provision Bare Metal Node from my tripleo Overcloud.
>>>>>>> For this, while deploying the overcloud, I have followed the *"default
>>>>>>> flat" *network approach specified in the below link
>>>>>>>
>>>>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>>>>>>>
>>>>>>> Just to highlight the changes, I have defined the
>>>>>>>
>>>>>>> *ironic-config.yaml*
>>>>>>>
>>>>>>> parameter_defaults:
>>>>>>>     ...
>>>>>>>     ...
>>>>>>>     IronicIPXEEnabled: true
>>>>>>>     IronicInspectorSubnets:
>>>>>>>     - ip_range: *172.23.3.100,172.23.3.150*
>>>>>>>     IronicInspectorInterface: 'br-baremetal'
>>>>>>>
>>>>>>> Also modified the file *~/templates/network-environment.yaml*
>>>>>>>
>>>>>>> parameter_defaults:
>>>>>>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>>>>>>   NeutronFlatNetworks: datacentre,baremetal
>>>>>>>
>>>>>>> With this I have Followed all the steps of creating br-baremetal
>>>>>>> bridge on controller, given in the link below:
>>>>>>>
>>>>>>>
>>>>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>>>>>>>
>>>>>>>   - type: ovs_bridge
>>>>>>>      name: br-baremetal
>>>>>>>      use_dhcp: false
>>>>>>>      members:
>>>>>>>      - type: interface
>>>>>>>        name: nic3
>>>>>>>
>>>>>>> Post Deployment, I have also create a flat network on "datacentre"
>>>>>>> physical network and subnet having the range *172.23.3.200,172.23.3.240
>>>>>>> *(as suggested subnet is same as of inspector and range is
>>>>>>> different) and the router
>>>>>>>
>>>>>>> Also created a baremetal node and ran *"openstack baremetal node
>>>>>>> manage bm1", *the state of which was a success.
>>>>>>>
>>>>>>> Observation:
>>>>>>>
>>>>>>> On executing  "openstack baremetal node *provide* bm1", the machine
>>>>>>> gets power on and ideally it should take an IP from ironic inspector range
>>>>>>> and PXE Boot.
>>>>>>> But nothing of this sort happens and we see an IP from neutron range
>>>>>>> "*172.23.3.239*" (attached the screenshot)
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> I have checked overcloud ironic inspector podman logs alongwith the
>>>>>>> tcpdump.
>>>>>>> In tcpdump, I can only see dhcp discover request on br-baremetal and
>>>>>>> nothing happens after that.
>>>>>>>
>>>>>>> I have tried to explain my issue in detail, but I would be happy to
>>>>>>> share more details in case still required.
>>>>>>> Can someone please help in resolving my issue.
>>>>>>>
>>>>>>> Regards
>>>>>>> Anirudh Gupta
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/00dc0feb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/00dc0feb/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 215792 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/00dc0feb/attachment-0003.png>

From juliaashleykreger at gmail.com  Mon Feb  7 14:35:59 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Mon, 7 Feb 2022 06:35:59 -0800
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
Message-ID: <CAF7gwdjhzwuaZ3uxJZwW--n+e5_r=pFgnatw_SyM_SSPukD6Mg@mail.gmail.com>

On Mon, Feb 7, 2022 at 4:47 AM Anirudh Gupta <anyrude10 at gmail.com> wrote:

> Hi Julia,
>
> Thanks a lot for your responses and support.
> To Update on the ongoing issue, I tried deploying the overcloud with your
> valuable suggestions i.e by passing "*DhcpAgentNotification: true*" in
> ironic-overcloud.yaml
> The setup came up successfully, but with this configuration the IP
> allocated on the system is one which is being configured while creating the
> subnet in openstack.
>
> [image: image.png]
>
> The system is still getting the IP (172.23.3.212) from neutron. The subnet
> range was configured as *172.23.3.210-172.23.3.240 *while creating the
> provisioning subnet.
> The system gets stuck here and no action is performed after this.
>
> Is there any way to resolve this and make successful  provisioning the
> baremetal node in *TripleO Train Release* (Since RHOSP 16 was on Train,
> so I thought to go with that version for better stability)
>
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
>
> I have some queries:
>
>
>    1. Is passing "*DhcpAgentNotification: true" *enough or do we have to
>    make some other changes as well?
>
>
I have no way to really know. My understanding is based on the contents in
the templates you have chosen and/or modified, then the neutron-dhcp-agent
can be disabled. It would be easy to see if it is in place or not by
running `openstack network agent list` and looking for a neutron dhcp
agent. If not present, something is disabling the agent which is required
for bare metal to function as the integrated DHCP server in OVN does not
support PXE options such as those used to facilitate network booting.

>
>    1. Although there are some security concerns specified in the
>    document, but Currently I am focusing on the default flat bare
>    metal approach which has dedicated interface for bare metal Provisioning.
>    There is one composable method approach as well. Keeping aside the security
>    concerns, which approach is better and functional?
>       1.
>       https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
>
>
You're referencing RH docs, which makes me wonder if you're a RH customer
or if you're trying to use RH docs with upstream TripleO which may not
exactly be ideal. If you are a RH customer, it wouldn't be a bad idea to
reach out to RH support.  Anyway, starting out you likely want  to focus on
the basics and not use a composible network. Once you have that working it
would make sense to evolve towards a composed network. Trying to do it now
introduces more variables which will make it harder to configure it for
your environment.

>
>    1. Will moving to upper openstack release version make this deployment
>    possible?
>       1. If Yes, which release should I go with as till wallaby the
>       ironic-overcloud.yml file has no option of including "*DhcpAgentNotification:
>       true*" by default
>          1.
>          https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
>
>
>
Possibly, I honestly don't know the entire change history and interaction
of the templates and overrides which exist with all the various options
you can choose with TripleO.


> Looking forward for your valuable feedback/response.
>
> Regards
> Anirudh Gupta
>
>
> On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta <anyrude10 at gmail.com> wrote:
>
>> Hi,
>>
>> Surely I'll revert the status once it gets deployed.
>> Bdw the suspicion is because of Train Release or it is something else?
>>
>> Regards
>> Anirudh Gupta
>>
>> On Fri, 4 Feb, 2022, 20:29 Julia Kreger, <juliaashleykreger at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta <anyrude10 at gmail.com>
>>> wrote:
>>>
>>>> Hi Julia
>>>>
>>>> Thanks for your response.
>>>>
>>>> Earlier I was passing both ironic.yaml and ironic-overcloud.yaml
>>>> located at path
>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/
>>>>
>>>> My current understanding now says that since I am using OVN, not OVS so
>>>> I should pass only ironic-overcloud.yaml in my deployment.
>>>>
>>>> I am currently on Train Release and my default ironic-overcloud.yaml
>>>> file has no such entry
>>>> DhcpAgentNotification: true
>>>>
>>>>
>>> I suspect that should work. Let us know if it does.
>>>
>>>
>>>
>>>> I would add this there and re deploy the setup.
>>>>
>>>> Would that be enough to make my deployment successful?
>>>>
>>>> Regards
>>>> Anirudh Gupta
>>>>
>>>>
>>>> On Fri, 4 Feb, 2022, 18:40 Julia Kreger, <juliaashleykreger at gmail.com>
>>>> wrote:
>>>>
>>>>> It is not a matter of disabling OVN, but a matter of enabling the
>>>>> dnsmasq service and notifications.
>>>>>
>>>>>
>>>>> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
>>>>> may provide some insight.
>>>>>
>>>>> I suspect if you're using stable/wallaby based branches and it is not
>>>>> working, there may need to be a patch backported by the TripleO maintainers.
>>>>>
>>>>> On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta <anyrude10 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Julia,
>>>>>>
>>>>>> Thanks for your response.
>>>>>> For the overcloud deployment, I am executing the following command:
>>>>>>
>>>>>> openstack overcloud deploy --templates \
>>>>>>     -n /home/stack/templates/network_data.yaml \
>>>>>>     -r /home/stack/templates/roles_data.yaml \
>>>>>>     -e /home/stack/templates/node-info.yaml \
>>>>>>     -e /home/stack/templates/environment.yaml \
>>>>>>     -e /home/stack/templates/environments/network-isolation.yaml \
>>>>>>     -e /home/stack/templates/environments/network-environment.yaml \
>>>>>>     -e
>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
>>>>>> \
>>>>>>     -e
>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>>>>>> \
>>>>>>     -e
>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>>>>>> \
>>>>>>     -e
>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>>>>>> \
>>>>>>     -e /home/stack/templates/ironic-config.yaml \
>>>>>>     -e
>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>>>>>>     -e
>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>>>>>>     -e /home/stack/containers-prepare-parameter.yaml
>>>>>>
>>>>>> I can see some OVN related stuff in my roles_data and
>>>>>> environments/network-isolation.yaml
>>>>>>
>>>>>> [stack at undercloud ~]$ grep -inr "ovn"
>>>>>> roles_data.yaml:34:    *OVNCMSOptions: "enable-chassis-as-gw"*
>>>>>> roles_data.yaml:168:    - *OS::TripleO::Services::OVNDBs*
>>>>>> roles_data.yaml:169:    - *OS::TripleO::Services::OVNController*
>>>>>> roles_data.yaml:279:    - *OS::TripleO::Services::OVNController*
>>>>>> roles_data.yaml:280:    - *OS::TripleO::Services::OVNMetadataAgent*
>>>>>> environments/network-isolation.yaml:16:  *OS::TripleO::Network::Ports::OVNDBsVipPort:
>>>>>> ../network/ports/vip.yaml*
>>>>>>
>>>>>> What is your recommendation and how to disable OVN....should I remove
>>>>>> it from roles_data.yaml and then render so that it doesn't get generated
>>>>>> in environments/network-isolation.yaml
>>>>>> Please suggest some pointers.
>>>>>>
>>>>>> Regards
>>>>>> Anirudh Gupta
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> It seems OVN is getting installed in ironic
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger <
>>>>>> juliaashleykreger at gmail.com> wrote:
>>>>>>
>>>>>>> My guess: You're running OVN. You need neutron-dhcp-agent running as
>>>>>>> well. OVN disables it by default and OVN's integrated DHCP service does not
>>>>>>> support options for network booting.
>>>>>>>
>>>>>>> -Julia
>>>>>>>
>>>>>>> On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta <anyrude10 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Team
>>>>>>>>
>>>>>>>> I am trying to Provision Bare Metal Node from my tripleo Overcloud.
>>>>>>>> For this, while deploying the overcloud, I have followed the *"default
>>>>>>>> flat" *network approach specified in the below link
>>>>>>>>
>>>>>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>>>>>>>>
>>>>>>>> Just to highlight the changes, I have defined the
>>>>>>>>
>>>>>>>> *ironic-config.yaml*
>>>>>>>>
>>>>>>>> parameter_defaults:
>>>>>>>>     ...
>>>>>>>>     ...
>>>>>>>>     IronicIPXEEnabled: true
>>>>>>>>     IronicInspectorSubnets:
>>>>>>>>     - ip_range: *172.23.3.100,172.23.3.150*
>>>>>>>>     IronicInspectorInterface: 'br-baremetal'
>>>>>>>>
>>>>>>>> Also modified the file *~/templates/network-environment.yaml*
>>>>>>>>
>>>>>>>> parameter_defaults:
>>>>>>>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>>>>>>>   NeutronFlatNetworks: datacentre,baremetal
>>>>>>>>
>>>>>>>> With this I have Followed all the steps of creating br-baremetal
>>>>>>>> bridge on controller, given in the link below:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>>>>>>>>
>>>>>>>>   - type: ovs_bridge
>>>>>>>>      name: br-baremetal
>>>>>>>>      use_dhcp: false
>>>>>>>>      members:
>>>>>>>>      - type: interface
>>>>>>>>        name: nic3
>>>>>>>>
>>>>>>>> Post Deployment, I have also create a flat network on "datacentre"
>>>>>>>> physical network and subnet having the range *172.23.3.200,172.23.3.240
>>>>>>>> *(as suggested subnet is same as of inspector and range is
>>>>>>>> different) and the router
>>>>>>>>
>>>>>>>> Also created a baremetal node and ran *"openstack baremetal node
>>>>>>>> manage bm1", *the state of which was a success.
>>>>>>>>
>>>>>>>> Observation:
>>>>>>>>
>>>>>>>> On executing  "openstack baremetal node *provide* bm1", the
>>>>>>>> machine gets power on and ideally it should take an IP from ironic
>>>>>>>> inspector range and PXE Boot.
>>>>>>>> But nothing of this sort happens and we see an IP from neutron
>>>>>>>> range "*172.23.3.239*" (attached the screenshot)
>>>>>>>>
>>>>>>>> [image: image.png]
>>>>>>>>
>>>>>>>> I have checked overcloud ironic inspector podman logs alongwith the
>>>>>>>> tcpdump.
>>>>>>>> In tcpdump, I can only see dhcp discover request on br-baremetal
>>>>>>>> and nothing happens after that.
>>>>>>>>
>>>>>>>> I have tried to explain my issue in detail, but I would be happy to
>>>>>>>> share more details in case still required.
>>>>>>>> Can someone please help in resolving my issue.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Anirudh Gupta
>>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/8b0024f0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47711 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/8b0024f0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 215792 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/8b0024f0/attachment-0003.png>

From cbouchar at redhat.com  Mon Feb  7 19:20:11 2022
From: cbouchar at redhat.com (Carol Bouchard)
Date: Mon, 7 Feb 2022 14:20:11 -0500
Subject: [ironic]Anaconda deploy interface config
In-Reply-To: <CAJkGiNuPMD-wMJpn_=eMK63j9SBuYOOmTQGS9HsVh8XYH5aQWw@mail.gmail.com>
References: <CACkzpE4A11he8EDmF-tDVOb2ZMR0FnaHogpBOq9EpWdYZ36ahg@mail.gmail.com>
 <CAJkGiNuPMD-wMJpn_=eMK63j9SBuYOOmTQGS9HsVh8XYH5aQWw@mail.gmail.com>
Message-ID: <CACkzpE4on7MutKbBjRfE_zshdDN9r+enRsNigmJHs55kzxbR3A@mail.gmail.com>

Hi Ruby:

I couldn't use your whole changeset since it introduced a different issue.
With your patch, I was seeing the
following error and it never reached the code creating squashfs.img as a
directory.  So I removed the patch
and only applied the pxe_util.py changes in cache_ramdisk_kernel() and I've
made further progress.

*| last_error | Failed to prepare to deploy: Cannot validate driver deploy.
Some parameters were missing in node's instance_info. Missing are:
['root_gb'] |*

Is this root_gb a new requirement?  More background: At the moment, I don't
have baremetal devices and I'm starting my work by
using VMs bifrost created for me.  Also I'm using the xena branch of
bifrost/ironic.

Carol

On Mon, Feb 7, 2022 at 11:56 AM Ruby Loo <opensrloo at gmail.com> wrote:

> Hi Carol,
>
> Thanks for reporting this! It is a bug :-( The fix is in
> https://review.opendev.org/c/openstack/ironic/+/827924.
>
> --ruby
>
> On Fri, Feb 4, 2022 at 11:44 AM Carol Bouchard <cbouchar at redhat.com>
> wrote:
>
>> Ironic folks:
>>
>> I'm trying to spawn a RHEL7 image using a kickstart file and having
>> issues with stage2 file.
>> First I used bifrost to initially setup a couple of VMs.  (There is no
>> openstack/glance).
>> I'm now using one of those VMs to boot up with RHEL7. I changed the VM
>> config
>> with the following:
>>
>> *| deploy_interface       | anaconda*
>> * | instance_info          | {'kernel': 'http://myip:8080/RHEL7/vmlinuz
>> <http://myip:8080/RHEL7/vmlinuz>', 'ramdisk':
>> 'http://myip:8080/RHEL7/initrd.img <http://myip:8080/RHEL7/initrd.img>',
>> 'image_source': 'http://myip:8080/RHEL7/initrd.img
>> <http://myip:8080/RHEL7/initrd.img>', 'stage2':
>> 'http://myip:8080/RHEL7/squashfs.img
>> <http://myip:8080/RHEL7/squashfs.img>', 'ks_cfg':
>> 'http://myip:8080/RHEL7/ks.cfg.template
>> <http://myip:8080/RHEL7/ks.cfg.template>', 'ks_template':
>> 'http://myip:8080/RHEL7/ks.cfg.template
>> <http://myip:8080/RHEL7/ks.cfg.template>'}*
>>
>> ironic.conf changes I made are as follows:
>>
>> *enabled_deploy_interfaces = direct,ramdisk,anaconda*
>>
>> *[anaconda]default_ks_template = file:///etc/ironic/ks.cfg.template*
>>
>> The error I'm getting is as follows:
>>  *$ baremetal node show testvm1 --field last_error*
>>
>> *| last_error | Deploy step deploy.deploy failed with IsADirectoryError:
>> [Errno 21] Is a directory:
>> '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'.*
>> Tail end of traceback is as follows:
>>
>>
>>
>>
>>
>>
>>
>>
>> * ironic-conductor[]:   ERROR ironic.conductor.utils   File
>> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/common/pxe_utils.py",
>> line 1245, in cache_ramdisk_kernel ironic-conductor[]:   ERROR
>> ironic.conductor.utils     deploy_utils.fetch_images(ctx, TFTPImageCache(),
>> list(t_pxe_info.values()), ironic-conductor[]:   ERROR
>> ironic.conductor.utils   File
>> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/deploy_utils.py",
>> line 240, in fetch_images ironic-conductor[]:   ERROR
>> ironic.conductor.utils     cache.fetch_image(href, path, ctx=ctx,
>> force_raw=force_raw) ironic-conductor[]:   ERROR ironic.conductor.utils
>> File
>> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py",
>> line 120, in fetch_image ironic-conductor[]:   ERROR ironic.conductor.utils
>>     dest_up_to_date =
>> _delete_dest_path_if_stale(master_path, ironic-conductor[]:   ERROR
>> ironic.conductor.utils   File
>> "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py",
>> line 460, in _delete_dest_path_if_stale ironic-conductor[]:   ERROR
>> ironic.conductor.utils     os.unlink(dest_path) ironic-conductor[]:   ERROR
>> ironic.conductor.utils IsADirectoryError: [Errno 21] Is a directory:
>> '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'*
>>
>> Please advise.
>>
>> Carol
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/37fb5d8b/attachment.htm>

From gmann at ghanshyammann.com  Mon Feb  7 22:20:19 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 07 Feb 2022 16:20:19 -0600
Subject: [all][tc] Technical Committee next weekly meeting on Feb 10th at
 1500 UTC
Message-ID: <17ed6460183.11c21ffe984234.3082030242553298999@ghanshyammann.com>

Hello Everyone,

Technical Committee's next weekly meeting is scheduled for Feb 10th at 1500 UTC.

If you would like to add topics for discussion, please add them to the below wiki page by
Wednesday, Feb 9th, at 2100 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

-gmann



From rosmaita.fossdev at gmail.com  Tue Feb  8 00:02:20 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Mon, 7 Feb 2022 19:02:20 -0500
Subject: [election][ptl][cinder] PTL non-candidacy
Message-ID: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>

Hello Argonauts,

With the election season rapidly approaching [0], I want to communicate 
my intentions to the team, to wit, I will not be standing for PTL for 
the Z cycle.

I've served as PTL for five cycles, which conflicts with my belief that 
it's good for open source projects to rotate leadership.  I think the 
Cinder project is fairly healthy, but it will be good to have someone 
take the Cinder helm who has a fresh perspective and who will be as 
excited to be PTL as I was way back in Ussuri.

We have an excellent project team, and I have no doubt that whoever 
steps up will have plenty of support from the Cinder community 
(including me, I don't have any intention of going anywhere in the near 
term).


cheers,
brian


[0] 
http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070.html


From gagehugo at gmail.com  Tue Feb  8 05:11:45 2022
From: gagehugo at gmail.com (Gage Hugo)
Date: Mon, 7 Feb 2022 23:11:45 -0600
Subject: [openstack-helm] No Meeting Tomorrow
Message-ID: <CAE4Awf8T7H8ST4LSUfmyn58QVBANVpjfQ9tD0hsGgUwKFSB6YA@mail.gmail.com>

Hey team,

Since there's nothing on the agenda for tomorrow's meeting, it has been
cancelled. We will meet again next week.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220207/e58bd6d5/attachment.htm>

From ricolin at ricolky.com  Tue Feb  8 05:50:08 2022
From: ricolin at ricolky.com (Rico Lin)
Date: Tue, 8 Feb 2022 13:50:08 +0800
Subject: [election][heat][ptl] PTL non-candidacy
Message-ID: <CA+WCyyoZ=5TSJE=CaUggXfYMe8Arn0w+pcNy7mgg9soLa6i0+A@mail.gmail.com>

Hi all,

As the PTL election will soon start, I would like to share my statement on
not planning to run another term of Heat PTL. And Instead, I encourage
anyone (core reviewer or not) who is interested to put their name on.
I will definitely still stay around and help with reviews and patches.

cheers,

*Rico Lin*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/aa180f5b/attachment.htm>

From dtantsur at redhat.com  Tue Feb  8 08:15:02 2022
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Tue, 8 Feb 2022 09:15:02 +0100
Subject: [ironic] Each deploy overwrites the entire target disk
In-Reply-To: <CAKZ_x7_W5SWSu09kXnya_Oo7rw8AYcZm+GJ732-e00DS_zzvYg@mail.gmail.com>
References: <CAKZ_x7_W5SWSu09kXnya_Oo7rw8AYcZm+GJ732-e00DS_zzvYg@mail.gmail.com>
Message-ID: <CACNgkFx_mpbG=+u-78UynHanoGu5niLwCpvnGKREde5U=r-jbg@mail.gmail.com>

Hi!

On Mon, Feb 7, 2022 at 4:50 PM Rados?aw Piliszek <
radoslaw.piliszek at gmail.com> wrote:

> Dears,
>
> I have a question regarding the default behaviour of Ironic Python
> Agent - it seems that each deploy causes the entire target disk to be
> overwritten. I have noticed this after replacing disks with larger
> ones, the deployment process started taking considerably longer and I
> observed that each sector is rewritten on the target device.
> Is that expected? Can I somehow avoid it?
>

I think we only overwrite metadata on the target disk, not zero it. Are you
sure it's not cleaning?

Dmitry


> I am using whole-disk, qcow2 images that are much smaller than the
> disk size (even in raw form).
> I am running Ironic Wallaby.
> The deployment method is direct.
>
> Kind regards,
> -yoctozepto
>
>

-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/8e2f98f8/attachment-0001.htm>

From radoslaw.piliszek at gmail.com  Tue Feb  8 08:28:47 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Tue, 8 Feb 2022 09:28:47 +0100
Subject: [ironic] Each deploy overwrites the entire target disk
In-Reply-To: <CACNgkFx_mpbG=+u-78UynHanoGu5niLwCpvnGKREde5U=r-jbg@mail.gmail.com>
References: <CAKZ_x7_W5SWSu09kXnya_Oo7rw8AYcZm+GJ732-e00DS_zzvYg@mail.gmail.com>
 <CACNgkFx_mpbG=+u-78UynHanoGu5niLwCpvnGKREde5U=r-jbg@mail.gmail.com>
Message-ID: <CAKZ_x79xMfeMym7mbKcq8akhsZh8+ukg7YB6HR3kv+A9tjdeYg@mail.gmail.com>

On Tue, 8 Feb 2022 at 09:15, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> Hi!
>
> On Mon, Feb 7, 2022 at 4:50 PM Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote:
>>
>> Dears,
>>
>> I have a question regarding the default behaviour of Ironic Python
>> Agent - it seems that each deploy causes the entire target disk to be
>> overwritten. I have noticed this after replacing disks with larger
>> ones, the deployment process started taking considerably longer and I
>> observed that each sector is rewritten on the target device.
>> Is that expected? Can I somehow avoid it?
>
>
> I think we only overwrite metadata on the target disk, not zero it. Are you sure it's not cleaning?

Nope, the cleaning process is quick, this is on deploy.
The command that does the entire overwrite is qemu-img convert from IPA.
I wonder if some semantics changed in the meantime.
I am using Debian Buster (10) based images.
So with this https://packages.debian.org/buster/qemu-utils

-yoctozepto


From mark at stackhpc.com  Tue Feb  8 09:28:09 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Tue, 8 Feb 2022 09:28:09 +0000
Subject: [kolla-ansible] custom configuration override issue.
In-Reply-To: <CAPgF-fqr8+3OFvxmo4Xu1H7n6ZoztA9WRfihhrqQZmjt74NdDg@mail.gmail.com>
References: <CAPgF-fqr8+3OFvxmo4Xu1H7n6ZoztA9WRfihhrqQZmjt74NdDg@mail.gmail.com>
Message-ID: <CAFHSqWovuV_Q+m9DgCgztd=yReNzJFPM58qcENwevg7MJf=XGg@mail.gmail.com>

On Mon, 7 Feb 2022 at 15:11, Satish Patel <satish.txt at gmail.com> wrote:
>
> Folks,
>
> I have a working kolla-ansible environment and now I want to push out
> some nova custom changes to specific compute nodes and I am trying the
> following override but somehow it doesn't work for me.
>
> Ansible inventory file multinode
>
> [control]
> 192.168.75.141 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> 192.168.75.142 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> 192.168.75.143 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> [compute]
> 192.168.75.[144:175] ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key

FYI you can use hostnames but still use IPs to connect:

myhost ansible_host=1.2.3.4

>
>
> I want to change some option on 192.168.75.199 compute server, I don't
> have compute name in inventory so i am using IP address for override
> but somehow that doesn't work
>
> /etc/kolla/config/nova/192.168.75.199/nova.conf

That is the correct path, when using the default config location.

Sanity check: .199 isn't in the above inventory.

>
> I have tried the following to use hypervisor hostname but that doesn't
> work. What am I doing wrong here?
>
> /etc/kolla/config/nova/COMP01.local/nova.conf

We use inventory_hostname to determine the path, so it will be
whatever you use as the name in your inventory. In your example it's
IPs.

>
>
> Following works for me but they are for global not for specific nodes.
> How do i override specific node file?
>
> /etc/kolla/config/nova/nova-compute.conf
>


From dtantsur at redhat.com  Tue Feb  8 10:25:28 2022
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Tue, 8 Feb 2022 11:25:28 +0100
Subject: [ironic] Each deploy overwrites the entire target disk
In-Reply-To: <CAKZ_x79xMfeMym7mbKcq8akhsZh8+ukg7YB6HR3kv+A9tjdeYg@mail.gmail.com>
References: <CAKZ_x7_W5SWSu09kXnya_Oo7rw8AYcZm+GJ732-e00DS_zzvYg@mail.gmail.com>
 <CACNgkFx_mpbG=+u-78UynHanoGu5niLwCpvnGKREde5U=r-jbg@mail.gmail.com>
 <CAKZ_x79xMfeMym7mbKcq8akhsZh8+ukg7YB6HR3kv+A9tjdeYg@mail.gmail.com>
Message-ID: <CACNgkFzt+u1GAEORdF6UQi=Oz92ogC88b4FnL7KJRX+9EJGM0g@mail.gmail.com>

On Tue, Feb 8, 2022 at 9:29 AM Rados?aw Piliszek <
radoslaw.piliszek at gmail.com> wrote:

> On Tue, 8 Feb 2022 at 09:15, Dmitry Tantsur <dtantsur at redhat.com> wrote:
> >
> > Hi!
> >
> > On Mon, Feb 7, 2022 at 4:50 PM Rados?aw Piliszek <
> radoslaw.piliszek at gmail.com> wrote:
> >>
> >> Dears,
> >>
> >> I have a question regarding the default behaviour of Ironic Python
> >> Agent - it seems that each deploy causes the entire target disk to be
> >> overwritten. I have noticed this after replacing disks with larger
> >> ones, the deployment process started taking considerably longer and I
> >> observed that each sector is rewritten on the target device.
> >> Is that expected? Can I somehow avoid it?
> >
> >
> > I think we only overwrite metadata on the target disk, not zero it. Are
> you sure it's not cleaning?
>
> Nope, the cleaning process is quick, this is on deploy.
> The command that does the entire overwrite is qemu-img convert from IPA.
> I wonder if some semantics changed in the meantime.
> I am using Debian Buster (10) based images.
> So with this https://packages.debian.org/buster/qemu-utils


Ah, you may need this change then:
https://review.opendev.org/c/openstack/ironic-lib/+/808993

Dmitry


>
>
> -yoctozepto
>
>

-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/043eb626/attachment.htm>

From radoslaw.piliszek at gmail.com  Tue Feb  8 11:01:56 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Tue, 8 Feb 2022 12:01:56 +0100
Subject: [ironic] Each deploy overwrites the entire target disk
In-Reply-To: <CACNgkFzt+u1GAEORdF6UQi=Oz92ogC88b4FnL7KJRX+9EJGM0g@mail.gmail.com>
References: <CAKZ_x7_W5SWSu09kXnya_Oo7rw8AYcZm+GJ732-e00DS_zzvYg@mail.gmail.com>
 <CACNgkFx_mpbG=+u-78UynHanoGu5niLwCpvnGKREde5U=r-jbg@mail.gmail.com>
 <CAKZ_x79xMfeMym7mbKcq8akhsZh8+ukg7YB6HR3kv+A9tjdeYg@mail.gmail.com>
 <CACNgkFzt+u1GAEORdF6UQi=Oz92ogC88b4FnL7KJRX+9EJGM0g@mail.gmail.com>
Message-ID: <CAKZ_x781Pu1U0fLiFrrSi9DNvdACsBstRrX4yuH=L1i-aeZ1mQ@mail.gmail.com>

On Tue, 8 Feb 2022 at 11:26, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
>
>
> On Tue, Feb 8, 2022 at 9:29 AM Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote:
>>
>> On Tue, 8 Feb 2022 at 09:15, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>> >
>> > Hi!
>> >
>> > On Mon, Feb 7, 2022 at 4:50 PM Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote:
>> >>
>> >> Dears,
>> >>
>> >> I have a question regarding the default behaviour of Ironic Python
>> >> Agent - it seems that each deploy causes the entire target disk to be
>> >> overwritten. I have noticed this after replacing disks with larger
>> >> ones, the deployment process started taking considerably longer and I
>> >> observed that each sector is rewritten on the target device.
>> >> Is that expected? Can I somehow avoid it?
>> >
>> >
>> > I think we only overwrite metadata on the target disk, not zero it. Are you sure it's not cleaning?
>>
>> Nope, the cleaning process is quick, this is on deploy.
>> The command that does the entire overwrite is qemu-img convert from IPA.
>> I wonder if some semantics changed in the meantime.
>> I am using Debian Buster (10) based images.
>> So with this https://packages.debian.org/buster/qemu-utils
>
>
> Ah, you may need this change then: https://review.opendev.org/c/openstack/ironic-lib/+/808993

Thanks, that's it!

-yoctozepto

>
> Dmitry
>
>>
>>
>>
>> -yoctozepto
>>
>
>
> --
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


From elod.illes at est.tech  Tue Feb  8 11:17:28 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Tue, 8 Feb 2022 12:17:28 +0100
Subject: [stable] sphinx docs jobs fail on old stable branches (no more py2
 support)
Message-ID: <d6e48183-f1c9-f0bf-a20f-a777fdc16404@est.tech>

Hi stable maintainers,

This mail is about to get some attention to build-openstack-sphinx-docs 
job that recently started to fail on old stable branches (Queens and 
Pike) and block gates for about ~30 repositories. (The failures are also 
visible in periodic stable jobs). This is because py27 support from 
sphinx jobs were removed [1] recently. (Python 3 (py35) support was 
mostly done in Rocky so that branch is not affected)

To unblock the gates I see the following options:

1. fix sphinx jobs to work with py35 (most probably requires some 
patches to backport - in a squashed patch - and maybe some resolution of 
requirement conflicts)

2. set sphinx jobs to non-voting (even better to remove them to do not 
use resources unnecessarily)

3. revert the patch [1] that removed the py2 support of sphinx (maybe 
the easiest thing to do, though i understand that py2 support is 
something that shouldn't be kept forever)

4. teams examine their old branches and if they are not really 
maintained, haven't merged patches recently, then probably it is a good 
time to propose their EOL transition according to the EOL process [1]

Some additional thoughts:
- When Extended Maintenance was introduced the community agreed that 
certain CI jobs can be removed, CI coverage can be reduced as time goes.
- To keep open an old branch in Extended Maintenance helps the 
cooperation between vendors / users as instead of maintaining it by 
themselves it can be done with a common effort, which could be 
beneficial for everyone. On the other hand, if there are no maintainers 
or invested efforts to keep the branch and CI alive, then it is a 
reasonable decision to transition the branch to End of Life.

Please consider the above options and act to eliminate the gate failures 
/ periodic stable job failures.


[1] https://review.opendev.org/c/zuul/zuul-jobs/+/827588
<https://review.opendev.org/#/q/I98c3da5b02a4ac7fb9d7bd8e00170762e77b9f40>[2] 
https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life

Thanks,

El?d

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/8e23bcd1/attachment-0001.htm>

From rdhasman at redhat.com  Tue Feb  8 11:38:07 2022
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Tue, 8 Feb 2022 17:08:07 +0530
Subject: [election][ptl][cinder] PTL non-candidacy
In-Reply-To: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
References: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
Message-ID: <CAARK8KQH0--7rAuE-TBu3THPkvsTDgmxJ3gVtXynOKoXBkfeAw@mail.gmail.com>

Thanks Brian for all your work and efforts to make cinder better!

On Tue, Feb 8, 2022 at 5:36 AM Brian Rosmaita <rosmaita.fossdev at gmail.com>
wrote:

> Hello Argonauts,
>
> With the election season rapidly approaching [0], I want to communicate
> my intentions to the team, to wit, I will not be standing for PTL for
> the Z cycle.
>
> I've served as PTL for five cycles, which conflicts with my belief that
> it's good for open source projects to rotate leadership.  I think the
> Cinder project is fairly healthy, but it will be good to have someone
> take the Cinder helm who has a fresh perspective and who will be as
> excited to be PTL as I was way back in Ussuri.
>
> We have an excellent project team, and I have no doubt that whoever
> steps up will have plenty of support from the Cinder community
> (including me, I don't have any intention of going anywhere in the near
> term).
>
>
> cheers,
> brian
>
>
> [0]
>
> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/85104645/attachment.htm>

From radoslaw.piliszek at gmail.com  Tue Feb  8 12:03:37 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Tue, 8 Feb 2022 13:03:37 +0100
Subject: [election][tc] My TC non-candidacy
Message-ID: <CAKZ_x79ggkvHGDNBxRFTa3-26NZwp5X9V_53T=Hw7pXkw8uZnQ@mail.gmail.com>

Dears,

I am hereby announcing my TC non-candidacy.

It was a great pleasure to work with you but my personal and
professional life has shifted away from OpenStack enough to make it
hard for me to dedicate the time the TC deserves.

Kind regards,
-yoctozepto


From hjensas at redhat.com  Tue Feb  8 12:50:59 2022
From: hjensas at redhat.com (Harald Jensas)
Date: Tue, 8 Feb 2022 13:50:59 +0100
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
Message-ID: <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>

On 2/7/22 13:47, Anirudh Gupta wrote:
> Hi?Julia,
> 
> Thanks a lot for your responses and support.
> To Update on the ongoing issue, I tried deploying the overcloud with 
> your valuable suggestions i.e by passing "*DhcpAgentNotification: true*" 
> in ironic-overcloud.yaml
> The setup came up successfully, but with this configuration the IP 
> allocated on the system is one which is being configured while creating 
> the subnet in openstack.
> 
> image.png
> 
> The system is still getting the IP (172.23.3.212) from neutron. The 
> subnet range was configured as *172.23.3.210-172.23.3.240 *while 
> creating the provisioning subnet.


The node is supposed to get an IP address from the neutron subnet on the 
provisioning network when:
a) provisioning node
b) cleaning node.

When you do "baremetal node provide" cleaning is most likely 
automatically initiated. (Since cleaning is enabled by default for 
Ironic in overcloud AFIK.)

The only time you will get an address from the IronicInspectorSubnets 
(ip_range: 172.23.3.100,172.23.3.150 in your case) is when you start 
ironic node introspection.

> The system gets stuck here and no action is performed after this.
>

It seems the system is getting an address from the expected DHCP server, 
but it does not boot. I would start looking into the pxe properties in 
the DHCP Reply.

What is the status of the node in ironic at this stage?
  `openstack baremetal node list`
  `openstack baremetal node show <node-uuid>`

Check the `extra_dhcp_opts` on the neutron port, it should set the 
nextserver and bootfile parameters. Does the bootfile exist in 
/var/lib/ironic/tftpboot? Inspect the 
`/var/lib/ironic/tftpboot/pxelinux.cfg/` directory, you should see a 
file matching the MAC address of your system. Does the content make sense?

Can you capture DHCP and TFTP traffic on the provisioning network?

> Is there any way to resolve this and make successful? provisioning the 
> baremetal?node in *TripleO Train Release* (Since RHOSP 16 was on Train, 
> so I thought to go with that version for better stability)
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index 
> <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index>
> 
> I have some queries:
> 
>  1. Is passing "*DhcpAgentNotification: true" *enough or do we have to
>     make some other changes as well?

I belive in train "DhcpAgentNotification" defaults to True.
The change to default to false was added more recently, and it was not 
backported. 
(https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761)

NOTE, the environment for enabling ironi for the overcloud 
'environments/services/ironic-overcloud.yaml' overrides this to 'true' 
in later releases.

>  2. Although there are some security concerns specified in the document,
>     but Currently I am focusing on the default flat bare metal?approach
>     which has dedicated?interface for bare metal?Provisioning. There is
>     one composable method approach as well. Keeping aside the security
>     concerns, which approach is better and functional?
>      1. https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
>         <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning>

Both should work, using the composable network is more secure since 
baremetal nodes does not have access to the control plane network.

>  3. Will moving to upper openstack release version make this deployment
>     possible?
>      1. If Yes, which release should I go with as till wallaby the
>         ironic-overcloud.yml file has no option of including
>         "*DhcpAgentNotification: true*" by default
>          1. https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
>             <https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml>
> 
> 
> Looking forward for your valuable feedback/response.
> 
> Regards
> Anirudh Gupta
> 
> 
> On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta <anyrude10 at gmail.com 
> <mailto:anyrude10 at gmail.com>> wrote:
> 
>     Hi,
> 
>     Surely I'll revert the status once it gets deployed.
>     Bdw the suspicion is because of Train Release or it is something else?
> 
>     Regards
>     Anirudh Gupta
> 
>     On Fri, 4 Feb, 2022, 20:29 Julia Kreger,
>     <juliaashleykreger at gmail.com <mailto:juliaashleykreger at gmail.com>>
>     wrote:
> 
> 
> 
>         On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta
>         <anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>> wrote:
> 
>             Hi Julia
> 
>             Thanks for your response.
> 
>             Earlier I was passing both ironic.yaml and
>             ironic-overcloud.yaml located at path
>             /usr/share/openstack-tripleo-heat-templates/environments/services/
> 
>             My current understanding now says that since I am using OVN,
>             not OVS so I should pass only ironic-overcloud.yaml in my
>             deployment.
> 
>             I am currently on Train Release and my default
>             ironic-overcloud.yaml file has no such entry
>             DhcpAgentNotification: true
> 
> 
>         I suspect that should work. Let us know if it does.
> 
>             I would add this there and re deploy the setup.
> 
>             Would that be enough to make my deployment successful?
> 
>             Regards
>             Anirudh Gupta
> 
> 
>             On Fri, 4 Feb, 2022, 18:40 Julia Kreger,
>             <juliaashleykreger at gmail.com
>             <mailto:juliaashleykreger at gmail.com>> wrote:
> 
>                 It is not a matter of disabling OVN, but a matter of
>                 enabling the dnsmasq service and notifications.
> 
>                 https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
>                 <https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml>
>                 may provide some insight.
> 
>                 I suspect if you're using stable/wallaby based branches
>                 and it is not working, there may need to be a patch
>                 backported by the TripleO maintainers.
> 
>                 On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta
>                 <anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>> wrote:
> 
>                     Hi?Julia,
> 
>                     Thanks for your response.
>                     For the overcloud deployment, I am executing the
>                     following command:
> 
>                     openstack overcloud deploy --templates \
>                      ? ? -n /home/stack/templates/network_data.yaml \
>                      ? ? -r /home/stack/templates/roles_data.yaml \
>                      ? ? -e /home/stack/templates/node-info.yaml \
>                      ? ? -e /home/stack/templates/environment.yaml \
>                      ? ? -e
>                     /home/stack/templates/environments/network-isolation.yaml
>                     \
>                      ? ? -e
>                     /home/stack/templates/environments/network-environment.yaml
>                     \
>                      ? ? -e
>                     /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
>                     \
>                      ? ? -e
>                     /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>                     \
>                      ? ? -e
>                     /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>                     \
>                      ? ? -e
>                     /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>                     \
>                      ? ? -e /home/stack/templates/ironic-config.yaml \
>                      ? ? -e
>                     /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
>                     \
>                      ? ? -e
>                     /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml
>                     \
>                      ? ? -e /home/stack/containers-prepare-parameter.yaml
> 
>                     I can see some OVN related stuff in my roles_data
>                     and environments/network-isolation.yaml
> 
>                     [stack at undercloud ~]$ grep -inr "ovn"
>                     roles_data.yaml:34: *OVNCMSOptions:
>                     "enable-chassis-as-gw"*
>                     roles_data.yaml:168: ? ?-
>                     *OS::TripleO::Services::OVNDBs*
>                     roles_data.yaml:169: ? ?-
>                     *OS::TripleO::Services::OVNController*
>                     roles_data.yaml:279: ? ?-
>                     *OS::TripleO::Services::OVNController*
>                     roles_data.yaml:280: ? ?-
>                     *OS::TripleO::Services::OVNMetadataAgent*
>                     environments/network-isolation.yaml:16:
>                     *OS::TripleO::Network::Ports::OVNDBsVipPort:
>                     ../network/ports/vip.yaml*
>                     *
>                     *
>                     What is your recommendation and how to disable
>                     OVN....should I remove it from roles_data.yaml and
>                     then render so that it doesn't get generated
>                     in?environments/network-isolation.yaml
>                     Please suggest some pointers.
> 
>                     Regards
>                     Anirudh Gupta
>                     *
>                     *
>                     *
>                     *
> 
> 
> 
> 
>                     It seems OVN is getting installed in ironic
> 
> 
>                     On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger
>                     <juliaashleykreger at gmail.com
>                     <mailto:juliaashleykreger at gmail.com>> wrote:
> 
>                         My guess: You're running OVN. You need
>                         neutron-dhcp-agent running as well. OVN disables
>                         it by default and OVN's?integrated DHCP service
>                         does not support options for network booting.
> 
>                         -Julia
> 
>                         On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta
>                         <anyrude10 at gmail.com
>                         <mailto:anyrude10 at gmail.com>> wrote:
> 
>                             Hi Team
> 
>                             I am trying to Provision Bare Metal Node
>                             from my tripleo Overcloud.
>                             For this, while deploying the overcloud, I
>                             have followed the *"default flat" *network
>                             approach specified in the below link
>                             https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>                             <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning>
> 
>                             Just to highlight the changes, I have
>                             defined the
> 
>                             *ironic-config.yaml*
> 
>                             parameter_defaults:
>                              ? ? ...
>                              ? ? ...
>                              ? ? IronicIPXEEnabled: true
>                              ? ? IronicInspectorSubnets:
>                              ? ? - ip_range: *172.23.3.100,172.23.3.150*
>                              ? ? IronicInspectorInterface: 'br-baremetal'
> 
>                             Also modified the file
>                             *~/templates/network-environment.yaml*
> 
>                             parameter_defaults:
>                              ? NeutronBridgeMappings:
>                             datacentre:br-ex,baremetal:br-baremetal
>                              ? NeutronFlatNetworks: datacentre,baremetal
> 
>                             With this I have Followed all the steps of
>                             creating br-baremetal bridge on controller,
>                             given in the link below:
> 
>                             https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>                             <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy>
> 
>                              ? - type: ovs_bridge
>                              ? ? ?name: br-baremetal
>                              ? ? ?use_dhcp: false
>                              ? ? ?members:
>                              ? ? ?- type: interface
>                              ? ? ? ?name: nic3
> 
>                             Post Deployment, I have also?create a flat
>                             network on "datacentre" physical?network and
>                             subnet having the range
>                             *172.23.3.200,172.23.3.240 *(as suggested
>                             subnet is same as of inspector and range is
>                             different) and the router
> 
>                             Also created a baremetal?node and ran
>                             *"openstack baremetal node manage bm1", *the
>                             state of which was a success.
> 
>                             Observation:
> 
>                             On executing "openstack baremetal node
>                             *provide* bm1", the machine gets power on
>                             and ideally it should take an IP from ironic
>                             inspector range and PXE Boot.
>                             But nothing of this sort happens and we see
>                             an IP from neutron range "*172.23.3.239*"
>                             (attached the screenshot)
> 
>                             image.png
> 
>                             I have checked overcloud ironic inspector
>                             podman logs alongwith the tcpdump.
>                             In tcpdump, I can only see dhcp discover
>                             request on br-baremetal and nothing happens
>                             after that.
> 
>                             I have tried to explain my issue in detail,
>                             but I would be happy to share more details
>                             in case still required.
>                             Can someone please help in resolving my issue.
> 
>                             Regards
>                             Anirudh Gupta
> 



From adivya1.singh at gmail.com  Tue Feb  8 12:55:39 2022
From: adivya1.singh at gmail.com (Adivya Singh)
Date: Tue, 8 Feb 2022 18:25:39 +0530
Subject: Floating IP issue regarding Latest upgrade to XENA
Message-ID: <CA+ykd62GXjAW67j+8RNprFL1qY1xZgPOSGTnH=+m6Knx94CnKg@mail.gmail.com>

Hi Team,

We have the latest upgrade to XENA, and we are facing an issue with XENA
release , where a few times, even Floating IP attached to the instance are
not reachable.

I tried various ways to troubleshoot the issue, Regarding The IP is
reachable from the router Namespace, The router IP is reachable, L3 agent
is working Fine, as other Floating IP are reachable which are hosted
through router on L3 agent, All ports are up, Interfaces are up, SNAT and
DNAT are working Fine,

But as soon as i dissociate and associate the Floating IP , it started
working Fine

Any Idea, why this Happening , and later on Fixed when Floating IP is
dissociate and associate again, and later again starts happening

Regards
Adivya Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/f5ec04ae/attachment.htm>

From jungleboyj at gmail.com  Tue Feb  8 13:50:21 2022
From: jungleboyj at gmail.com (Jay Bryant)
Date: Tue, 8 Feb 2022 07:50:21 -0600
Subject: [election][ptl][cinder] PTL non-candidacy
In-Reply-To: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
References: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
Message-ID: <7d8471ee-f608-950e-4bf7-4b3606238fb2@gmail.com>

Brian,

Thank you for being PTL for the last 5 cycles!? Where has the time gone?

You have been a fantastic leader and the project is better for it!

Jay

On 2/7/2022 6:02 PM, Brian Rosmaita wrote:
> Hello Argonauts,
>
> With the election season rapidly approaching [0], I want to 
> communicate my intentions to the team, to wit, I will not be standing 
> for PTL for the Z cycle.
>
> I've served as PTL for five cycles, which conflicts with my belief 
> that it's good for open source projects to rotate leadership.? I think 
> the Cinder project is fairly healthy, but it will be good to have 
> someone take the Cinder helm who has a fresh perspective and who will 
> be as excited to be PTL as I was way back in Ussuri.
>
> We have an excellent project team, and I have no doubt that whoever 
> steps up will have plenty of support from the Cinder community 
> (including me, I don't have any intention of going anywhere in the 
> near term).
>
>
> cheers,
> brian
>
>
> [0] 
> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070.html
>


From akanevsk at redhat.com  Tue Feb  8 14:07:00 2022
From: akanevsk at redhat.com (Arkady Kanevsky)
Date: Tue, 8 Feb 2022 08:07:00 -0600
Subject: [election][ptl][cinder] PTL non-candidacy
In-Reply-To: <7d8471ee-f608-950e-4bf7-4b3606238fb2@gmail.com>
References: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
 <7d8471ee-f608-950e-4bf7-4b3606238fb2@gmail.com>
Message-ID: <CAEbdGYNEud3nUj7Dx=LS2a7J4B09sV7xzB-U8GcfvTk0cuAMGQ@mail.gmail.com>

Thanks Brian for your service to the community.

On Tue, Feb 8, 2022 at 7:52 AM Jay Bryant <jungleboyj at gmail.com> wrote:

> Brian,
>
> Thank you for being PTL for the last 5 cycles!  Where has the time gone?
>
> You have been a fantastic leader and the project is better for it!
>
> Jay
>
> On 2/7/2022 6:02 PM, Brian Rosmaita wrote:
> > Hello Argonauts,
> >
> > With the election season rapidly approaching [0], I want to
> > communicate my intentions to the team, to wit, I will not be standing
> > for PTL for the Z cycle.
> >
> > I've served as PTL for five cycles, which conflicts with my belief
> > that it's good for open source projects to rotate leadership.  I think
> > the Cinder project is fairly healthy, but it will be good to have
> > someone take the Cinder helm who has a fresh perspective and who will
> > be as excited to be PTL as I was way back in Ussuri.
> >
> > We have an excellent project team, and I have no doubt that whoever
> > steps up will have plenty of support from the Cinder community
> > (including me, I don't have any intention of going anywhere in the
> > near term).
> >
> >
> > cheers,
> > brian
> >
> >
> > [0]
> >
> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070.html
> >
>
>

-- 
Arkady Kanevsky, Ph.D.
Phone: 972 707-6456
Corporate Phone: 919 729-5744 ext. 8176456
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/3f6b179d/attachment.htm>

From fungi at yuggoth.org  Tue Feb  8 14:41:01 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 8 Feb 2022 14:41:01 +0000
Subject: [stable][docs][i18n] sphinx docs jobs fail on old stable
 branches (no more py2 support)
In-Reply-To: <d6e48183-f1c9-f0bf-a20f-a777fdc16404@est.tech>
References: <d6e48183-f1c9-f0bf-a20f-a777fdc16404@est.tech>
Message-ID: <20220208144100.5g4jpvfbi6o3d3vi@yuggoth.org>

On 2022-02-08 12:17:28 +0100 (+0100), El?d Ill?s wrote:
[...]
> 3. revert the patch [1] that removed the py2 support of sphinx (maybe the
> easiest thing to do, though i understand that py2 support is something that
> shouldn't be kept forever)
[...]
> [1] https://review.opendev.org/c/zuul/zuul-jobs/+/827588
[...]

There are also some middle-ground options:

Because the primary impetus of that change was that the
ensure-sphinx role was installing Sphinx with Python 2 by default,
and required explicit overriding of the sphinx_python rolevar by any
consumers wishing to use a modern Python interpreter to do
documentation builds, it's possible the Zuul maintainers would agree
to revert it while switching the default sphinx_python to python3.
If they agree, I expect they'd want to set a deprecation timer to
remove it at some point in the future, so would still need to
address this problem sooner or later.

We could also copy the old role into the openstack-zuul-jobs repo
and use that, though we'd be forking from the zuul-jobs version and
taking on future maintenance of ours in the OpenStack community (at
least until we can safely drop Python 2.7 support and switch back to
the proper role again).

It's worth noting, that change brought something else to light...
our translation import jobs, which never overrode sphinx_python,
were using Python 2.7 all this time. There's some brainstorming
underway now to try and figure out how to squash the bitrot which
has accumulated there as a result.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/2699eb99/attachment.sig>

From amy at demarco.com  Tue Feb  8 14:46:03 2022
From: amy at demarco.com (Amy Marrich)
Date: Tue, 8 Feb 2022 08:46:03 -0600
Subject: [election][ptl][cinder] PTL non-candidacy
In-Reply-To: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
References: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
Message-ID: <CAFs83Qp9mutMUe_CAHsFnnZtY-ks5R7iqjFiE0s0x_USaOHYgw@mail.gmail.com>

Brian,

Thanks for all your hard work over the years. Glad to know you're not going
anywhere!

Amy (spotz)

On Mon, Feb 7, 2022 at 6:05 PM Brian Rosmaita <rosmaita.fossdev at gmail.com>
wrote:

> Hello Argonauts,
>
> With the election season rapidly approaching [0], I want to communicate
> my intentions to the team, to wit, I will not be standing for PTL for
> the Z cycle.
>
> I've served as PTL for five cycles, which conflicts with my belief that
> it's good for open source projects to rotate leadership.  I think the
> Cinder project is fairly healthy, but it will be good to have someone
> take the Cinder helm who has a fresh perspective and who will be as
> excited to be PTL as I was way back in Ussuri.
>
> We have an excellent project team, and I have no doubt that whoever
> steps up will have plenty of support from the Cinder community
> (including me, I don't have any intention of going anywhere in the near
> term).
>
>
> cheers,
> brian
>
>
> [0]
>
> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/b50fcf9c/attachment.htm>

From amy at demarco.com  Tue Feb  8 14:47:49 2022
From: amy at demarco.com (Amy Marrich)
Date: Tue, 8 Feb 2022 08:47:49 -0600
Subject: [election][tc] My TC non-candidacy
In-Reply-To: <CAKZ_x79ggkvHGDNBxRFTa3-26NZwp5X9V_53T=Hw7pXkw8uZnQ@mail.gmail.com>
References: <CAKZ_x79ggkvHGDNBxRFTa3-26NZwp5X9V_53T=Hw7pXkw8uZnQ@mail.gmail.com>
Message-ID: <CAFs83QozXoqfk8QSENTf1Rh8d1cbxYZdBdihi6_XH8gbv=6WoQ@mail.gmail.com>

Radoslaw,

You will be missed. It's been a pleasure serving with you on the TC and
working together in the community.

Amy (spotz)


On Tue, Feb 8, 2022 at 6:07 AM Rados?aw Piliszek <
radoslaw.piliszek at gmail.com> wrote:

> Dears,
>
> I am hereby announcing my TC non-candidacy.
>
> It was a great pleasure to work with you but my personal and
> professional life has shifted away from OpenStack enough to make it
> hard for me to dedicate the time the TC deserves.
>
> Kind regards,
> -yoctozepto
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/858f3f75/attachment.htm>

From amy at demarco.com  Tue Feb  8 14:50:37 2022
From: amy at demarco.com (Amy Marrich)
Date: Tue, 8 Feb 2022 08:50:37 -0600
Subject: [election][heat][ptl] PTL non-candidacy
In-Reply-To: <CA+WCyyoZ=5TSJE=CaUggXfYMe8Arn0w+pcNy7mgg9soLa6i0+A@mail.gmail.com>
References: <CA+WCyyoZ=5TSJE=CaUggXfYMe8Arn0w+pcNy7mgg9soLa6i0+A@mail.gmail.com>
Message-ID: <CAFs83QrB3DOHQvb5NzWL64JpfhBs0qa7KbMMsy25Zn+hkQry1A@mail.gmail.com>

Rico,

Thank you for all your hard work as PTL for Heat over the years!

Amy (spotz)



On Mon, Feb 7, 2022 at 11:54 PM Rico Lin <ricolin at ricolky.com> wrote:

> Hi all,
>
> As the PTL election will soon start, I would like to share my statement on
> not planning to run another term of Heat PTL. And Instead, I encourage
> anyone (core reviewer or not) who is interested to put their name on.
> I will definitely still stay around and help with reviews and patches.
>
> cheers,
>
> *Rico Lin*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/3af20db1/attachment.htm>

From gmann at ghanshyammann.com  Tue Feb  8 14:51:15 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 08 Feb 2022 08:51:15 -0600
Subject: [all][elections][ptl][tc] Combined PTL/TC z cycle Election
 Nominations Kickoff
Message-ID: <17ed9d13dd9.ec4537d6145693.3111750922224373283@ghanshyammann.com>

Hello Everyone,

Nominations for OpenStack PTLs (Project Team Leads) and TC
(Technical Committee) positions (5 positions) are now open
and will remain open until Feb 15, 2022 23:45 UTC.

All nominations must be submitted as a text file to the
openstack/election repository as explained at
https://governance.openstack.org/election/#how-to-submit-a-candidacy

Please make sure to follow the candidacy file naming convention:
candidates/z/<Project_Name or "TC">/<email_address>
(for example, "candidates/z/TC/stacker at example.org").

The name of the file should match an email address for your current
OpenStack Foundation Individual Membership. Take this opportunity to
ensure that your OSF member profile contains current information:
https://www.openstack.org/profile/

Any OpenStack Foundation Individual Member can propose their

candidacy for an available, directly-elected seat on the Technical
Committee.

In order to be an eligible candidate for PTL you must be an
OpenStack Foundation Individual Member. PTL candidates must also
have contributed to the corresponding team during the Xena to Yoga
timeframe, Mar 26, 2021 00:00 UTC - Feb 15, 2022 00:00 UTC. Your
Gerrit account must also have a verified email address matching the
one used in your candidacy filename.

Both PTL and TC elections will be held from Feb 22, 2022 23:45 UTC
through to Mar 01, 2022 23:45 UTC. The electorate for the TC election
are the OpenStack Foundation Individual Members who have a code
contribution to one of the official teams over the Xena to Yoga
timeframe, Mar 26, 2021 00:00 UTC - Feb 15, 2022 00:00 UTC, as well as
any Extra ATCs who are acknowledged by the TC. The electorate for a
PTL election are the OpenStack Foundation Individual Members who
have a code contribution over the Xena to Yoga timeframe,
Mar 26, 2021 00:00 UTC - Feb 15, 2022 00:00 UTC, in a deliverable
repository maintained by the team which the PTL would lead, as
well as the Extra ATCs who are acknowledged by the TC for that
specific team. The list of project teams can be found at
https://governance.openstack.org/tc/reference/projects/ and their
individual team pages include lists of corresponding Extra ATCs.

Please find below the timeline:

    PTL + TC nomination starts   @ Feb 08, 2022 23:45 UTC
    PTL + TC nomination ends     @ Feb 15, 2022 23:45 UTC
    TC campaigning starts  @ Feb 15, 2022 23:45 UTC
    TC campaigning ends    @ Feb 22, 2022 23:45 UTC
    PTL + TC elections start     @ Feb 22, 2022 23:45 UTC
    PTL + TC elections end       @ Mar 01, 2022 23:45 UTC

Shortly after election officials approve candidates, they will be
listed on the https://governance.openstack.org/election/ page.

The electorate is requested to confirm their email addresses in
Gerrit prior to 2022-02-15 00:00:00+00:00, so that the emailed ballots
are sent to the correct email address. This email address should
match one which was provided in your foundation member profile as
well. Gerrit account information and OSF member profiles can be
updated at https://review.openstack.org/#/settings/contact and
https://www.openstack.org/profile/ accordingly.

If you have any questions please be sure to either ask them on the
mailing list or to the elections officials:
https://governance.openstack.org/election/#election-officials


-gmann & The OpenStack Technical Election Officials



From gmann at ghanshyammann.com  Tue Feb  8 14:59:28 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 08 Feb 2022 08:59:28 -0600
Subject: [election][tc] My TC non-candidacy
In-Reply-To: <CAKZ_x79ggkvHGDNBxRFTa3-26NZwp5X9V_53T=Hw7pXkw8uZnQ@mail.gmail.com>
References: <CAKZ_x79ggkvHGDNBxRFTa3-26NZwp5X9V_53T=Hw7pXkw8uZnQ@mail.gmail.com>
Message-ID: <17ed9d8c273.108c51b20146757.5852235299022814258@ghanshyammann.com>

Thank you yoctozepto for all your hard work and all the contribution in TC. We will
miss you for sure but very best wishes for your new role.

-gmann

 ---- On Tue, 08 Feb 2022 06:03:37 -0600 Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote ----
 > Dears,
 > 
 > I am hereby announcing my TC non-candidacy.
 > 
 > It was a great pleasure to work with you but my personal and
 > professional life has shifted away from OpenStack enough to make it
 > hard for me to dedicate the time the TC deserves.
 > 
 > Kind regards,
 > -yoctozepto
 > 
 > 


From gmann at ghanshyammann.com  Tue Feb  8 15:01:22 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 08 Feb 2022 09:01:22 -0600
Subject: [election][ptl][cinder] PTL non-candidacy
In-Reply-To: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
References: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
Message-ID: <17ed9da7ea5.1169b6950146979.6025744526554618041@ghanshyammann.com>

Thanks Brian for your leadership in Cinder for so many years.

-gmann

 ---- On Mon, 07 Feb 2022 18:02:20 -0600 Brian Rosmaita <rosmaita.fossdev at gmail.com> wrote ----
 > Hello Argonauts,
 > 
 > With the election season rapidly approaching [0], I want to communicate 
 > my intentions to the team, to wit, I will not be standing for PTL for 
 > the Z cycle.
 > 
 > I've served as PTL for five cycles, which conflicts with my belief that 
 > it's good for open source projects to rotate leadership.  I think the 
 > Cinder project is fairly healthy, but it will be good to have someone 
 > take the Cinder helm who has a fresh perspective and who will be as 
 > excited to be PTL as I was way back in Ussuri.
 > 
 > We have an excellent project team, and I have no doubt that whoever 
 > steps up will have plenty of support from the Cinder community 
 > (including me, I don't have any intention of going anywhere in the near 
 > term).
 > 
 > 
 > cheers,
 > brian
 > 
 > 
 > [0] 
 > http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070.html
 > 
 > 


From gmann at ghanshyammann.com  Tue Feb  8 15:01:54 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 08 Feb 2022 09:01:54 -0600
Subject: [election][heat][ptl] PTL non-candidacy
In-Reply-To: <CA+WCyyoZ=5TSJE=CaUggXfYMe8Arn0w+pcNy7mgg9soLa6i0+A@mail.gmail.com>
References: <CA+WCyyoZ=5TSJE=CaUggXfYMe8Arn0w+pcNy7mgg9soLa6i0+A@mail.gmail.com>
Message-ID: <17ed9dafeaf.101940e11147035.4239229946557751337@ghanshyammann.com>

Thanks Rico for leading Heat project for so many years.

-gmann

 ---- On Mon, 07 Feb 2022 23:50:08 -0600 Rico Lin <ricolin at ricolky.com> wrote ----
 > Hi all,
 > As the PTL election will soon start, I would like to share my statement on not planning to run another term of Heat PTL. And Instead, I encourage anyone (core reviewer or not) who is interested to put their name on.I will definitely still stay around and help with reviews and patches.
 > cheers,
 > Rico Lin
 > 


From jungleboyj at gmail.com  Tue Feb  8 15:13:29 2022
From: jungleboyj at gmail.com (Jay Bryant)
Date: Tue, 8 Feb 2022 09:13:29 -0600
Subject: [election][tc] My TC non-candidacy
In-Reply-To: <CAFs83QozXoqfk8QSENTf1Rh8d1cbxYZdBdihi6_XH8gbv=6WoQ@mail.gmail.com>
References: <CAKZ_x79ggkvHGDNBxRFTa3-26NZwp5X9V_53T=Hw7pXkw8uZnQ@mail.gmail.com>
 <CAFs83QozXoqfk8QSENTf1Rh8d1cbxYZdBdihi6_XH8gbv=6WoQ@mail.gmail.com>
Message-ID: <c3c8ef7a-610a-f4a7-c2e2-195948dd3925@gmail.com>

Radoslaw,

Has been great to work with you on the TC!? Thank you for your service 
to the community.

Jay

(jungleboyj)

On 2/8/2022 8:47 AM, Amy Marrich wrote:
> Radoslaw,
>
> You will be missed. It's been a pleasure serving with you on the TC 
> and working together in the community.
>
> Amy (spotz)
>
>
> On Tue, Feb 8, 2022 at 6:07 AM Rados?aw Piliszek 
> <radoslaw.piliszek at gmail.com> wrote:
>
>     Dears,
>
>     I am hereby announcing my TC non-candidacy.
>
>     It was a great pleasure to work with you but my personal and
>     professional life has shifted away from OpenStack enough to make it
>     hard for me to dedicate the time the TC deserves.
>
>     Kind regards,
>     -yoctozepto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/4e530926/attachment.htm>

From satish.txt at gmail.com  Tue Feb  8 15:19:01 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 8 Feb 2022 10:19:01 -0500
Subject: [kolla-ansible] custom configuration override issue.
In-Reply-To: <CAFHSqWovuV_Q+m9DgCgztd=yReNzJFPM58qcENwevg7MJf=XGg@mail.gmail.com>
References: <CAPgF-fqr8+3OFvxmo4Xu1H7n6ZoztA9WRfihhrqQZmjt74NdDg@mail.gmail.com>
 <CAFHSqWovuV_Q+m9DgCgztd=yReNzJFPM58qcENwevg7MJf=XGg@mail.gmail.com>
Message-ID: <CAPgF-fqEzAfqgAihLm+c8vMY5_edT=5tr72rycnT3LvgJy31XQ@mail.gmail.com>

Thank you mark, i think you found my typo :)  that was it.

How do i group nodes and pass configuration to specific group like.
for example i have GPU and IB compute nodes. i want to group them so i
can push out to config to GPU group related GPU and IB (infiniband)
related IB config

[gpu]
1.1.1.1
2.2.2.2
3.3.3.3

[ib]
4.4.4.4
5.5.5.5
6.6.6.6

[compute:children]
gpu
ib

Can i apply config like following for group related?  what is the best
way to handle groups in kolla-ansible?

/etc/kolla/config/nova/gpu/nova.conf
/etc/kolla/config/nova/ib/nova.conf

On Tue, Feb 8, 2022 at 4:28 AM Mark Goddard <mark at stackhpc.com> wrote:
>
> On Mon, 7 Feb 2022 at 15:11, Satish Patel <satish.txt at gmail.com> wrote:
> >
> > Folks,
> >
> > I have a working kolla-ansible environment and now I want to push out
> > some nova custom changes to specific compute nodes and I am trying the
> > following override but somehow it doesn't work for me.
> >
> > Ansible inventory file multinode
> >
> > [control]
> > 192.168.75.141 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> > 192.168.75.142 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> > 192.168.75.143 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> > [compute]
> > 192.168.75.[144:175] ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
>
> FYI you can use hostnames but still use IPs to connect:
>
> myhost ansible_host=1.2.3.4
>
> >
> >
> > I want to change some option on 192.168.75.199 compute server, I don't
> > have compute name in inventory so i am using IP address for override
> > but somehow that doesn't work
> >
> > /etc/kolla/config/nova/192.168.75.199/nova.conf
>
> That is the correct path, when using the default config location.
>
> Sanity check: .199 isn't in the above inventory.
>
> >
> > I have tried the following to use hypervisor hostname but that doesn't
> > work. What am I doing wrong here?
> >
> > /etc/kolla/config/nova/COMP01.local/nova.conf
>
> We use inventory_hostname to determine the path, so it will be
> whatever you use as the name in your inventory. In your example it's
> IPs.
>
> >
> >
> > Following works for me but they are for global not for specific nodes.
> > How do i override specific node file?
> >
> > /etc/kolla/config/nova/nova-compute.conf
> >


From jimmy at openinfra.dev  Tue Feb  8 14:30:21 2022
From: jimmy at openinfra.dev (Jimmy McArthur)
Date: Tue, 8 Feb 2022 08:30:21 -0600
Subject: [election][ptl][cinder] PTL non-candidacy
In-Reply-To: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
References: <a8cc5922-c2ce-f4dc-9e9b-7bd0cc328684@gmail.com>
Message-ID: <E4AEF205-0891-4993-8C32-139D5E02E827@getmailspring.com>

Thanks Brian for all the support and work you put into the community :)

Cheers,
Jimmy

On Feb 7 2022, at 6:02 pm, Brian Rosmaita <rosmaita.fossdev at gmail.com> wrote:
> Hello Argonauts,
>
> With the election season rapidly approaching [0], I want to communicate
> my intentions to the team, to wit, I will not be standing for PTL for
> the Z cycle.
>
> I've served as PTL for five cycles, which conflicts with my belief that
> it's good for open source projects to rotate leadership. I think the
> Cinder project is fairly healthy, but it will be good to have someone
> take the Cinder helm who has a fresh perspective and who will be as
> excited to be PTL as I was way back in Ussuri.
>
> We have an excellent project team, and I have no doubt that whoever
> steps up will have plenty of support from the Cinder community
> (including me, I don't have any intention of going anywhere in the near
> term).
>
>
> cheers,
> brian
>
>
> [0]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070.html
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/72e5068b/attachment-0001.htm>

From jcrawford at quadrivium.com  Tue Feb  8 15:02:15 2022
From: jcrawford at quadrivium.com (Joshua Crawford)
Date: Tue, 8 Feb 2022 15:02:15 +0000
Subject: [Update Process]
Message-ID: <1d26f9142927f518c3de872e764803db2b9e3a7c.camel@quadrivium.com>

Hi,

I have been given the task of updating our openstack/swift setup.
Currently, we are on openstack 2.3.1 with python-swiftclient 3.0.0 on
Ubuntu 16.04. My plan is to upgrade Ubuntu to 18.04 and then to 20.04.
Then focus on updating openstack and swift.

I do not have any previous experience with openstack or swift, but from
what I have read so far, our current version is not supported on
anything newer than Ubuntu 16.04. Should I revise my plan and look at
updating openstack/swift first, or is my plan to update Ubuntu first a
good path forward.

Thank you,
joshua.


[cid:d105ac7d-e828-4289-8ff1-70d919cdb057.jpg]
[cid:Quadrivium-Logo_Horizontal-OneColor-CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg]
        Joshua Crawford | Senior Engineer
Quadrivium Inc. | 5537 Bleaux Ave.
Springdale, AR 72762
479.419.4600 | quadrivium.com<https://quadrivium.com>
[cid:cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg]


This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Quadrivium-Logo_Horizontal-OneColor-CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg
Type: image/jpeg
Size: 13098 bytes
Desc: Quadrivium-Logo_Horizontal-OneColor-CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/6b138ff8/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg
Type: image/jpeg
Size: 17743 bytes
Desc: cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/6b138ff8/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Review_email_graphic_horizontal_77598f78-471b-42f6-9459-d48ed6e721d2.png
Type: image/png
Size: 12060 bytes
Desc: Review_email_graphic_horizontal_77598f78-471b-42f6-9459-d48ed6e721d2.png
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/6b138ff8/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d105ac7d-e828-4289-8ff1-70d919cdb057.jpg
Type: image/jpeg
Size: 4475 bytes
Desc: d105ac7d-e828-4289-8ff1-70d919cdb057.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/6b138ff8/attachment-0005.jpg>

From gthiemonge at redhat.com  Tue Feb  8 16:52:04 2022
From: gthiemonge at redhat.com (Gregory Thiemonge)
Date: Tue, 8 Feb 2022 17:52:04 +0100
Subject: [all][Neutron][Octavia][Nova][Kuryr] Bump pyroute2 version to
 0.6.5 in stable/wallaby
In-Reply-To: <CAB1EZBr2q7K3opZyZbP-+92Letvyo4Gv5tMarqzJFMbG4zySZA@mail.gmail.com>
References: <CAB1EZBr2q7K3opZyZbP-+92Letvyo4Gv5tMarqzJFMbG4zySZA@mail.gmail.com>
Message-ID: <CAKsmYT2Ht4-_vhO5GiLYyPPTAKwZQ41hAop2rBj4u8vhoX6D2A@mail.gmail.com>

Hi Lucas,

I gave +1 to the patch. Looks fine for Octavia.

Greg

On Mon, Feb 7, 2022 at 4:57 PM Lucas Alvares Gomes <lucasagomes at gmail.com>
wrote:

> Hi,
>
> I currently have a patch up for openstack/requirements [0] bumping the
> version of the pyroute2 library from 0.5.14 to 0.6.5 as the older
> version have a memory leak issue [1] in the NDB module which can cause
> the service using the library to be killed by the OOM killer because
> of an out-of-memory condition.
>
> This email was a suggestion by a core reviewer to raise awareness from
> the broader community to this change/issue.
>
> Please if you have any concerning about this version bump let us know
> here on in the patch itself [0]
>
> [0] https://review.opendev.org/c/openstack/requirements/+/828091
> [1] https://github.com/svinota/pyroute2/issues/789
>
> Cheers,
> Lucas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/93834428/attachment.htm>

From rdhasman at redhat.com  Tue Feb  8 17:31:17 2022
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Tue, 8 Feb 2022 23:01:17 +0530
Subject: [election][cinder] PTL Candidacy for Z
Message-ID: <CAARK8KRnRxFXDdt9y_gbCvQKFp3t+Be_2r6KAvCKyep3+tOjPQ@mail.gmail.com>

Hi All,

I would like to announce my candidacy for PTL of the Cinder project for the
Z cycle.

Since this is the first time I'm proposing my candidacy, I would like to
briefly introduce myself. I started contributing to OpenStack back in the
Queens release (although not very actively) and started focusing on the
Cinder project in the Rocky release. I became a core reviewer in Cinder in
the mid of the Stein release and since then I've been actively contributing
to the Cinder project in terms of features, bug fixes, reviews etc. I'm
also a part of Cinder's core security group and a stable core and currently
serving as release liaison for Cinder for the past 3 releases.

Coming to the focus for the Z release, Cinder receives an abundance of
commits every cycle in terms of new drivers, driver features, core cinder
features, bug fixes, improvements etc and we've always faced a shortage in
reviews. It is not due to fewer people working actively but more of a
priority issue in their respective roles. I would like to encourage
contributors to discuss with their managers about the importance of code
review in opensource and how it is helpful for the community and the
individuals as well.

Apart from that, I would like to revisit the security issues backlog since
that hasn't been looked upon in quite some time and if we encounter
something that needs attention, we can also hold core security meetings
from time to time to address the issues.

We are also getting active driver contributions every cycle which is a good
thing, but sadly the driver implementation patches seem to have a lot of
mistakes which are well documented in the driver contribution docs and
something I would like to highlight in the Z PTG (as most of the vendors
join it and propose their driver ideas). Again, the documentation is not
perfect as we discussed in Yoga PTG.  Following up upon this and improving
it is another focus I support for Cinder.

Lastly, I would like to put more emphasis upon the 3rd Party CI compliance
check which we haven't done in a while and it would be good to know how
many vendors are actually maintaining their CI consistently.

There are some new ideas started by Brian in the past releases which I
would like to continue. Some examples include the last cinder meeting being
a video+IRC meeting and every third Friday of the month, we have a festival
of XS reviews which significantly reduced the backlog of open patches.

In the end, I would like to say, I want to continue the good trends set in
the Cinder community and improve on certain areas where there is not much
attention being given.  I will do my best to address the above mentioned
items during my time as PTL. Thanks for considering me.

Rajat Dhasmana (whoami-rajat)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/e2a8b3b8/attachment.htm>

From opensrloo at gmail.com  Tue Feb  8 18:05:30 2022
From: opensrloo at gmail.com (Ruby Loo)
Date: Tue, 8 Feb 2022 13:05:30 -0500
Subject: [ironic]Anaconda deploy interface config
In-Reply-To: <CAF7gwdgmCJ4h5xJUgfuEJ8_AJAL7zxzhX+e7rQEoAqjv716-vg@mail.gmail.com>
References: <CACkzpE4A11he8EDmF-tDVOb2ZMR0FnaHogpBOq9EpWdYZ36ahg@mail.gmail.com>
 <CAJkGiNuPMD-wMJpn_=eMK63j9SBuYOOmTQGS9HsVh8XYH5aQWw@mail.gmail.com>
 <CACkzpE4on7MutKbBjRfE_zshdDN9r+enRsNigmJHs55kzxbR3A@mail.gmail.com>
 <CAJkGiNtOYN2iEGkhWExOe7ODXtD_D3N8oKrcsjDM+nMmxWzr4g@mail.gmail.com>
 <CAF7gwdgmCJ4h5xJUgfuEJ8_AJAL7zxzhX+e7rQEoAqjv716-vg@mail.gmail.com>
Message-ID: <CAJkGiNsEy+MF5qEkwf2XUUcJOQyv7q7ZAP2v30Xi3vQcshKjNQ@mail.gmail.com>

On Mon, Feb 7, 2022 at 3:30 PM Julia Kreger <juliaashleykreger at gmail.com>
wrote:

> On Mon, Feb 7, 2022 at 12:21 PM Ruby Loo <opensrloo at gmail.com> wrote:
> >
> >
> >
> > On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard <cbouchar at redhat.com>
> wrote:
> >>
> [trim]
> >> Is this root_gb a new requirement?  More background: At the moment, I
> don't have baremetal devices and I'm starting my work by
> >> using VMs bifrost created for me.  Also I'm using the xena branch of
> bifrost/ironic.
> >>
> >> Carol
> >>
> >
> > root_gb is old. I suspect bifrost doesn't use/need that information. If
> all the info you have for using the anaconda deploy interface is in the OS
> image or via configs, you'll be ok. Although when that patch merges, it'll
> break your use case if the VM-ironic-node doesn't have
> instance_info['root_gb'] specified. That code is getting triggered via:
> >
> >    PXEAnacondaDeploy.prepare(): node.instance_info =
> deploy_utils.build_instance_info_for_deploy(
> >                 task).
> >    which causes this code to be invoked [1]
> >
> > To get around it, you could set the ironic node's instance_info to have
> 'root_gb' = <some value>. Eg: "openstack baremetal node set <node>
> --instance-info root_gb=10"
>
> Yeah, we really need to nuke the requirement, but I could see it still
> being needed if someone tries to perform a partition image deployment.
> That being said, I don't think we should be requiring it on the
> anaconda deployment interface.
>
> Bifrost largely was designed around just deploying whole disk images,
> which is why it is not present on the node.
>
> <snip>


Ok, I updated the PR [1] to skip the root_gb check. The updated PR won't
automatically backport nicely (because of a recent change to master) but it
isn't too difficult to manually fix. Hopefully there won't be other issues
;)

[1] https://review.opendev.org/c/openstack/ironic/+/827924/3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/3821480e/attachment.htm>

From lucasagomes at gmail.com  Tue Feb  8 18:22:37 2022
From: lucasagomes at gmail.com (Lucas Alvares Gomes)
Date: Tue, 8 Feb 2022 18:22:37 +0000
Subject: [all][Neutron][Octavia][Nova][Kuryr] Bump pyroute2 version to
 0.6.5 in stable/wallaby
In-Reply-To: <CAKsmYT2Ht4-_vhO5GiLYyPPTAKwZQ41hAop2rBj4u8vhoX6D2A@mail.gmail.com>
References: <CAB1EZBr2q7K3opZyZbP-+92Letvyo4Gv5tMarqzJFMbG4zySZA@mail.gmail.com>
 <CAKsmYT2Ht4-_vhO5GiLYyPPTAKwZQ41hAop2rBj4u8vhoX6D2A@mail.gmail.com>
Message-ID: <CAB1EZBr7EwHZ8RpVtMw53k3ZnuV7NQXg4vhTvUwY9s_a=+jD_w@mail.gmail.com>

On Tue, Feb 8, 2022 at 4:52 PM Gregory Thiemonge <gthiemonge at redhat.com> wrote:
>
> Hi Lucas,
>
> I gave +1 to the patch. Looks fine for Octavia.
>
> Greg
>

Thanks very much Greg for verifying it for Octavia!

Cheers,
Lucas

> On Mon, Feb 7, 2022 at 4:57 PM Lucas Alvares Gomes <lucasagomes at gmail.com> wrote:
>>
>> Hi,
>>
>> I currently have a patch up for openstack/requirements [0] bumping the
>> version of the pyroute2 library from 0.5.14 to 0.6.5 as the older
>> version have a memory leak issue [1] in the NDB module which can cause
>> the service using the library to be killed by the OOM killer because
>> of an out-of-memory condition.
>>
>> This email was a suggestion by a core reviewer to raise awareness from
>> the broader community to this change/issue.
>>
>> Please if you have any concerning about this version bump let us know
>> here on in the patch itself [0]
>>
>> [0] https://review.opendev.org/c/openstack/requirements/+/828091
>> [1] https://github.com/svinota/pyroute2/issues/789
>>
>> Cheers,
>> Lucas
>>


From erin at openstack.org  Tue Feb  8 23:04:27 2022
From: erin at openstack.org (Erin Disney)
Date: Tue, 8 Feb 2022 17:04:27 -0600
Subject: OpenInfra Summit Berlin- CFP Deadline in 24 Hours! 
Message-ID: <5691EB1C-54F5-4ED6-878E-F60F8FB9BA95@openstack.org>

The deadline for the upcoming OpenInfra Summit?s Call for Presentations is in 24 hours! 

CFP for the Berlin Summit (June 7-9th) is still open until February 9th at 22:59 UTC (4:59 PM CT). Reminder that Summit attendance fees are waived for all accepted speakers. 

Submit your talk for the OpenInfra Summit here: https://cfp.openinfra.dev/app/berlin-2022 

2022 Summit Tracks:
5G, NFV & Edge
AI, Machine Learning & HPC
CI/CD
Container Infrastructure
Getting Started
Hands-on Workshops
NEW: Hardware Enablement 
Open Development
Private & Hybrid Cloud
Public Cloud
Security

More Summit resources:
Registration is live at Early Bird pricing: https://openinfrasummitberlin.eventbrite.com/
Sponsorships are available: https://openinfra.dev/summit-sponsor
Apply for the Travel Support Program: https://openinfrafoundation.formstack.com/forms/TSP_Berlin2022

Questions or issues with your submission? Email speakersupport at openinfra.dev and we will be happy to help you sort it out.

Thanks, 
Erin 

Erin Disney
Event Marketing 
Open Infrastructure Foundation 



Erin Disney
Event Marketing 
Open Infrastructure Foundation 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/6b43cef1/attachment-0001.htm>

From laurentfdumont at gmail.com  Wed Feb  9 01:56:20 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Tue, 8 Feb 2022 20:56:20 -0500
Subject: [Update Process]
In-Reply-To: <1d26f9142927f518c3de872e764803db2b9e3a7c.camel@quadrivium.com>
References: <1d26f9142927f518c3de872e764803db2b9e3a7c.camel@quadrivium.com>
Message-ID: <CAOAKi8zkEaPSFWspFmOumNgH5_A8=LajT6_XWD4qW7KoFA-Y3w@mail.gmail.com>

That's a loaded question.

   - How was Openstack deployed?
   - How was the Swift component deployed?

Answering these two questions will impact what tooling you can use to
upgrade your packages. It will be split between the Openstack packages and
the regular distro packages.

On Tue, Feb 8, 2022 at 11:17 AM Joshua Crawford <jcrawford at quadrivium.com>
wrote:

> Hi,
>
> I have been given the task of updating our openstack/swift setup.
> Currently, we are on openstack 2.3.1 with python-swiftclient 3.0.0 on
> Ubuntu 16.04. My plan is to upgrade Ubuntu to 18.04 and then to 20.04.
> Then focus on updating openstack and swift.
>
> I do not have any previous experience with openstack or swift, but from
> what I have read so far, our current version is not supported on
> anything newer than Ubuntu 16.04. Should I revise my plan and look at
> updating openstack/swift first, or is my plan to update Ubuntu first a
> good path forward.
>
> Thank you,
> joshua.
>
>
> [cid:d105ac7d-e828-4289-8ff1-70d919cdb057.jpg]
>
> [cid:Quadrivium-Logo_Horizontal-OneColor-CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg]
>         Joshua Crawford | Senior Engineer
> Quadrivium Inc. | 5537 Bleaux Ave.
> Springdale, AR 72762
> 479.419.4600 | quadrivium.com<https://quadrivium.com>
> [cid:cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg]
>
>
> This message is confidential. It may also be privileged or otherwise
> protected by work product immunity or other legal rules. If you have
> received it by mistake, please let us know by e-mail reply and delete it
> from your system; you may not copy this message or disclose its contents to
> anyone. The integrity and security of this message cannot be guaranteed on
> the Internet.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/dace3950/attachment.htm>

From ykarel at redhat.com  Wed Feb  9 05:56:32 2022
From: ykarel at redhat.com (Yatin Karel)
Date: Wed, 9 Feb 2022 11:26:32 +0530
Subject: [neutron] Bug deputy report for week of January 31
In-Reply-To: <CALg0jK=wpsd2a6hBM+6vMEy9mYR2GSJitE4p0CqkuinaB_v3rA@mail.gmail.com>
References: <CALg0jK=wpsd2a6hBM+6vMEy9mYR2GSJitE4p0CqkuinaB_v3rA@mail.gmail.com>
Message-ID: <CAPU8nTHn=+mhsZogEEsEnXeoDQKnLFTU2NUit-qDv5Y5S8+wRQ@mail.gmail.com>

Hi,

On Mon, Feb 7, 2022 at 7:17 PM Lajos Katona <katonalala at gmail.com> wrote:

> Hi Neutron Team
>
> I was bug deputy in neutron last week.
>
> Summary
> =======
>
> Needs attention
> ============
> * Neutron-dynamic-routing does not work with OVN (
> https://bugs.launchpad.net/neutron/+bug/1959666)
> * [stein][neutron] Static rules losed (
> https://bugs.launchpad.net/neutron/+bug/1959884)
> * VM gets wrong ipv6 address from neutron-dhcp-agent after ipv6 address on
> port was changed (https://bugs.launchpad.net/neutron/+bug/1959697)
>
> Bugs with assignees
> ================
> * Random Tempest test failures(SSH failure) in openvswitch jobs  (
> https://bugs.launchpad.net/neutron/+bug/1959564)
> ** https://review.opendev.org/c/openstack/neutron/+/827315
>
> * QoS Ingress bandwidth limit with OVS backend may not work as expected (
> https://bugs.launchpad.net/neutron/+bug/1959567)
> ** WIP: https://review.opendev.org/c/openstack/neutron/+/827112
>
> * test_local_ip_connectivity test failing in stable/xena jobs (
> https://bugs.launchpad.net/neutron/+bug/1959573):
> ** MERGED: https://review.opendev.org/c/openstack/neutron/+/827057
>
> * pip 22 breaks python3.6 jobs (Victoria and older CI jobs) (
> https://bugs.launchpad.net/neutron/+bug/1959600)
> ** MERGED:
> https://review.opendev.org/q/Iab2c391d5388461fe9e9037cee81884ce8032e72
>
> * minimum_packet_rate qos rule type is not visible in the GET
> /v2.0/qos/rule-types response (
> https://bugs.launchpad.net/neutron/+bug/1959749)
> ** https://review.opendev.org/q/topic:bug%252F1959749
>
> * "get_rule_type" should not check the context admin status (
> https://bugs.launchpad.net/neutron/+bug/1959778)
> ** https://review.opendev.org/c/openstack/neutron-lib/+/827533
>
> * ovn-octavia loadbalancer not working when VIP is on a dual-stack
> provider network (https://bugs.launchpad.net/neutron/+bug/1959903 )
> ** https://review.opendev.org/c/openstack/ovn-octavia-provider/+/827670
>
> * [ovn] Stale ports in the OVN database at churn (
> https://bugs.launchpad.net/neutron/+bug/1960006)
> ** https://review.opendev.org/c/openstack/neutron/+/827834
>
> * neutron-tempest-with-uwsgi job failing tempest tests with: Floating ip
> <fip> failed to associate with server <server id> in time (
> https://bugs.launchpad.net/neutron/+bug/1960022 )
> ** MERGED: https://review.opendev.org/c/openstack/tempest/+/814085
>
 Just to update, the MERGED patch is the one that caused the issue, it's
being reverted with https://review.opendev.org/c/openstack/tempest/+/828245,
so until then ussuri/victoria is blocked.

>
> * NullQuota driver returns None that breaks client API (
> https://bugs.launchpad.net/neutron/+bug/1960032)
> ** https://review.opendev.org/c/openstack/neutron/+/827875
>
> Low hanging fruit
> =============
> * potential performance issue when scheduling network segments (
> https://bugs.launchpad.net/neutron/+bug/1959750)
>
> Need more information
> ==================
> * Disallow users to allocate gateway ip of external subnets as floating ip
> (https://bugs.launchpad.net/neutron/+bug/1959699 )
>
> Regards
> Lajos Katona (lajoskatona)
>


Thanks and Regards
Yatin Karel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/06f4d64c/attachment.htm>

From eblock at nde.ag  Wed Feb  9 08:12:11 2022
From: eblock at nde.ag (Eugen Block)
Date: Wed, 09 Feb 2022 08:12:11 +0000
Subject: [kolla-ansible][nova] volume creation time
Message-ID: <20220209081211.Horde.WAVvbmDzp-FEZWmNHXHb6GR@webmail.nde.ag>

I haven't used iscsi as a backend yet, but for HDDs the speed looks  
relatable, on a system with HDD ceph backend the volume creation of a  
volume (image is 2 GB) takes about 40 seconds, as you yee the download  
is quite slow, the conversion is a little faster:

Image download 541.00 MB at 28.14 MB/s
Converted 2252.00 MB image at 172.08 MB/s

With a factor of 10 (20 GB) I would probably end up with similar  
creation times. Just for comparison, this is almost the same image  
(also 2 GB) in a different ceph cluster where I mounted the cinder  
conversion path from cephfs, SSD pool:

Image download 555.12 MB at 41.34 MB/s
Converted 2252.00 MB image at 769.17 MB/s

This volume was created within 20 seconds. You might also want to  
tweak these options:

block_device_allocate_retries = 300
block_device_allocate_retries_interval = 10

These are the defaults:

block_device_allocate_retries = 60
block_device_allocate_retries_interval = 3

This would fit your error message:

> Volume be0f28eb-1045-4687-8bdb-5a6d385be6fa did not finish being  
> created even after we waited 187 seconds or 61 attempts. And its  
> status is downloading.

It tried 60 times with a 3 second interval, apparently that's not  
enough. Can you see any bottlenecks in the network or disk utilization  
which would slow down the download?


Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:

> Hi Eugen,
> thanks for your help
> We have 3 servers (s1, s2 , s3) and an iscsi bay attached on s3.
> Multinode:
> [control]
> s1
> s2
>
> [compute]
> s1
> s2
> s3
>
> [storage]
> s3
>
> on s1: more /etc/kolla/globals.yml
> ...
> enable_cinder: "yes"
> enable_cinder_backend_iscsi: "yes"
> enable_cinder_backend_lvm: ? yes"
> enable_iscsid: ? yes"
> cinder_volume_group: "cinder-volumes ?
> ...
> enable_glance_image_cache: "yes"
> glance_cache_max_size: "21474836480"
> glance_file_datadir_volume: ? /images/?
> ...
>
> on s3:  /images is on the iscsi bay
> mount |grep images
> /dev/mapper/VG--IMAGES-LV--IMAGES on /images type xfs  
> (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=1024,swidth=1024,noquota)
>
> lsblk
> sdf                                                                   
>            8:80   0   500G  0 disk
> ??mpathc                                                              
>          253:3    0   500G  0 mpath
>  ??mpathc1                                                            
>         253:4    0   500G  0 part
>    ??VG--IMAGES-LV--IMAGES                                            
>         253:5    0   500G  0 lvm   /images
>
>
> ls -l /images:
> drwxr-x---. 5 42415 42415 4096  6 f?vr. 18:40 image-cache
> drwxr-x---. 2 42415 42415 4096  4 f?vr. 15:16 images
> drwxr-x---. 2 42415 42415    6 22 nov.  12:03 staging
> drwxr-x---. 2 42415 42415    6 22 nov.  12:03 tasks_work_dir
>
> ls -l /images/image-cache
> total 71646760
> -rw-r-----. 1 42415 42415   360841216  2 d?c.  11:52  
> 3e3aada8-7610-4c55-b116-a12db68f8ea4
> -rw-r-----. 1 42415 42415   237436928 28 nov.  16:56  
> 6419642b-fcbd-4e5d-9c77-46a48d2af93f
> -rw-r-----. 1 42415 42415 10975379456 26 nov.  14:59  
> 7490e914-8001-4d56-baea-fabf80f425e1
> -rw-r-----. 1 42415 42415 21474836480 22 nov.  16:46  
> 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5
> -rw-r-----. 1 42415 42415  2694512640 15 d?c.  18:07  
> 890fd2e8-2fac-42c6-956b-6b10f2253a56
> -rw-r-----. 1 42415 42415 12048400384  1 d?c.  17:04  
> 9a235763-ff0c-40fd-9a8d-7cdca3d3e9ce
> -rw-r-----. 1 42415 42415  5949227008 15 d?c.  20:41  
> 9cbba37b-1de1-482a-87f2-631d2143cd46
> -rw-r-----. 1 42415 42415   566994944  6 d?c.  12:32  
> b6e29dd9-a66d-4569-a222-6fc0bd9b1b11
> -rw-r-----. 1 42415 42415   578748416  2 d?c.  11:24  
> c40953ee-4b39-43a5-8f6c-b48a046c38e9
> -rw-r-----. 1 42415 42415    16300544 27 janv. 12:19  
> c88630c7-a7c6-44ff-bfa0-e5af4b1720e3
> -rw-r-----. 1 42415 42415       12288  6 f?vr. 18:40 cache.db
> -rw-r-----. 1 42415 42415 12324503552  1 d?c.  07:50  
> e0d4fddd-5aa7-4177-a1d6-e6b4c56f12e8
> -rw-r-----. 1 42415 42415  6139084800 22 nov.  15:05  
> eda93204-9846-4216-a6e8-c29977fdcf2f
> -rw-r-----. 1 42415 42415           0 22 nov.  12:03 image_cache_db_init
> drwxr-x---. 2 42415 42415           6 27 janv. 12:19 incomplete
> drwxr-x---. 2 42415 42415           6 22 nov.  12:03 invalid
> drwxr-x---. 2 42415 42415           6 22 nov.  12:03 queue
>
> on s1
> openstack image list
> +--------------------------------------+-----------------------------+--------+
> | ID                                   | Name                         
> | Status |
> +--------------------------------------+-----------------------------+--------+
> ?..
> | 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5 | rocky8.4                     
> | active |
> ?.
> | 7490e914-8001-4d56-baea-fabf80f425e1 | win10_2104                   
> | active |
> ?.
> +???????????????????+-----------------------------+????+
>
>
> openstack image show 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5
> disk_format      | raw
>
> when I try to add an instance from this image (2G RAM, 40G HDD):
> [Error : Build of instance baa06bef-9628-407f-8bae-500ef7bce065  
> aborted: Volume be0f28eb-1045-4687-8bdb-5a6d385be6fa did not finish  
> being created even after we waited 187 seconds or 61 attempts. And  
> its status is downloading.
>
> it?s impossible. I need to add the volume from image first, and  
> after add instance from volume.
>
> Is it normal ?
>
>
> Franck
>
>> Le 7 f?vr. 2022 ? 10:55, Eugen Block <eblock at nde.ag> a ?crit :
>>
>> Hi Franck,
>>
>> although it's a different topic than your original question I  
>> wanted to comment on the volume creation time (maybe a new thread  
>> would make sense). What is your storage back end? If it is ceph,  
>> are your images in raw format? Otherwise cinder has to download the  
>> image from glance (to /var/lib/cinder/conversion) and convert it,  
>> then upload it back to ceph. It's similar with nova, nova stores  
>> base images in /var/lib/nova/instances/_base to prevent the compute  
>> nodes from downloading it every time. This may save some time for  
>> the download, but the upload has to happen anyway. And if you don't  
>> use shared storage for nova (e.g. for live-migration) you may  
>> encounter that some compute nodes are quicker creating an instance  
>> because they only have to upload, others will first have to  
>> download, convert and then upload it.
>>
>> You would see the conversion in the logs of cinder:
>>
>> INFO cinder.image.image_utils  
>> [req-f2062570-4006-464b-a1f5-d0d5ac34670d  
>> d71f59600f1c40c394022738d4864915 31b9b4900a4d4bdaabaf263d0b4021be -  
>> - -] Converted 2252.00 MB image at 757.52 MB/s
>>
>> Hope this helps.
>>
>> Eugen
>>
>>
>> Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:
>>
>>> Sunday morning: my openstack works?. OUF.
>>> the "kolla-ansible -i multimode mariadb_recovery"  command (which  
>>> is magic anyway) fixed the problem and then the mariadb and nova  
>>> containers started.
>>> Once solved the problems between my serv3 and the iscsi bay,  
>>> restart the container glance, everything seems to work.
>>>
>>>> 4 minutes to create a 20GB empty volume seems too long to me. For  
>>>> an actual 20GB image, it's going to depend on the speed of the  
>>>> backing storage tech.
>>> 4 minutes is for a volume from an image. I will see this problem  
>>> next summer , I will retry to change the MTU value.
>>>
>>> Thanks a lot, really
>>>
>>>
>>> Franck
>>>
>>>> Le 5 f?vr. 2022 ? 17:08, Laurent Dumont  
>>>> <laurentfdumont at gmail.com> a ?crit :
>>>>
>>>> Any chance to revert back switches + server? That would indicate  
>>>> that MTU was the issue.
>>>> Dont ping the iscsi bay, ping between the controllers in  
>>>> Openstack, they are the ones running mariadb/galera.
>>>> Since the icmp packets are small, it might not trigger the MTU  
>>>> issues. Can you try something like "ping -s 8972 -M do -c 4  
>>>> $mariadb_host_2" from $ mariadb_host_1?
>>>> What is your network setup on the servers? Two ports in a bond?  
>>>> Did you change both physical interface MTU + bond interface itself?
>>>>
>>>> 4 minutes to create a 20GB empty volume seems too long to me. For  
>>>> an actual 20GB image, it's going to depend on the speed of the  
>>>> backing storage tech.
>>>>
>>>> On Sat, Feb 5, 2022 at 1:51 AM Franck VEDEL  
>>>> <franck.vedel at univ-grenoble-alpes.fr  
>>>> <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>>> Thanks for your help.
>>>>
>>>>
>>>>> What was the starting value for MTU?
>>>> 1500
>>>>> What was the starting value changed to for MTU?
>>>> 9000
>>>>> Can ping between all your controllers?
>>>> yes, all container starts except nova-conductor, nova-scheduler, maraidb
>>>>
>>>>
>>>>> Do you just have two controllers running mariadb?
>>>> yes
>>>>> How did you change MTU?
>>>>
>>>> On the 3 servers:
>>>> nmcli connection modify team0-port1 802-3-ethernet.mtu 9000
>>>> nmcli connection modify team1-port2 802-3-ethernet.mtu 9000
>>>> nmcli connection modify type team0 team.runner lack ethernet.mtu 9000
>>>> nmcli con down team0
>>>> nmcli con down team1
>>>>
>>>>
>>>>> Was the change reverted at the network level as well (switches  
>>>>> need to be configured higher or at the same MTU value then the  
>>>>> servers)
>>>> I didn?t change Mtu on network (switches) , but ping -s  
>>>> 10.0.5.117 (iscsi bay) was working from serv3.
>>>>
>>>> I changed the value of the mtu because the creation of the  
>>>> volumes takes a lot of time I find (4 minutes for 20G, which is  
>>>> too long for what I want to do, the patience of the students  
>>>> decreases with the years)
>>>>
>>>> Franck
>>>>
>>>>> Le 4 f?vr. 2022 ? 23:12, Laurent Dumont  
>>>>> <laurentfdumont at gmail.com <mailto:laurentfdumont at gmail.com>> a  
>>>>> ?crit :
>>>>>
>>>>> What was the starting value for MTU?
>>>>> What was the starting value changed to for MTU?
>>>>> Can ping between all your controllers?
>>>>> Do you just have two controllers running mariadb?
>>>>> How did you change MTU?
>>>>> Was the change reverted at the network level as well (switches  
>>>>> need to be configured higher or at the same MTU value then the  
>>>>> servers)
>>>>> 4567 seems to be the port for galera (clustering for mariadb) <>
>>>>> On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL  
>>>>> <franck.vedel at univ-grenoble-alpes.fr  
>>>>> <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>>>> Hello,
>>>>> I am in an emergency situation, quite catastrophic situation  
>>>>> because I do not know what to do.
>>>>>
>>>>> I have an Openstack cluster with 3 servers (serv1, serv2,  
>>>>> serv3). He was doing so well?
>>>>>
>>>>>
>>>>> A network admin came to me and told me to change an MTU on the  
>>>>> cards. I knew it shouldn't be done...I shouldn't have done it.
>>>>> I did it.
>>>>> Of course, it didn't work as expected. I went back to my  
>>>>> starting configuration and there I have a big problem with  
>>>>> mariadb which is set up on serv1 and serv2.
>>>>>
>>>>> Here are my errors:
>>>>>
>>>>>
>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm  
>>>>> backend connection: 110: failed to reach primary view: 110  
>>>>> (Connection timed out)
>>>>> 	 at gcomm/src/pc.cpp:connect():160
>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>>>> gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend  
>>>>> connection: -110 (Connection timed out)
>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>>>> gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel  
>>>>> 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': <>  
>>>>> -110 (Connection timed out)
>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed:  
>>>>> Connection timed out
>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>>>> wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567 <>)  
>>>>> failed: 7
>>>>> 2022-02-04 17:40:36 0 [ERROR] Aborting
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I do not know what to do. My installation is done with  
>>>>> kolla-ansible, mariadb docker restarts every 30 seconds.
>>>>>
>>>>> Can the "kolla-ansible reconfigure mariadb" command be a solution?
>>>>> Could the command "kolla-ansible mariadb recovery" be a solution?
>>>>>
>>>>> Thanks in advance if you can help me.
>>>>>
>>>>>
>>>>>
>>>>> Franck
>>>>>
>>>>>
>>>>
>>
>>
>>
>>




From mark at stackhpc.com  Wed Feb  9 09:05:38 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 9 Feb 2022 09:05:38 +0000
Subject: [kolla-ansible] custom configuration override issue.
In-Reply-To: <CAPgF-fqEzAfqgAihLm+c8vMY5_edT=5tr72rycnT3LvgJy31XQ@mail.gmail.com>
References: <CAPgF-fqr8+3OFvxmo4Xu1H7n6ZoztA9WRfihhrqQZmjt74NdDg@mail.gmail.com>
 <CAFHSqWovuV_Q+m9DgCgztd=yReNzJFPM58qcENwevg7MJf=XGg@mail.gmail.com>
 <CAPgF-fqEzAfqgAihLm+c8vMY5_edT=5tr72rycnT3LvgJy31XQ@mail.gmail.com>
Message-ID: <CAFHSqWoHNPK3XQPoOED9QpHaAdpYhXNow=B+6QVhH0v5FwUwEQ@mail.gmail.com>

Kolla-ansible won't lookup config files based on group names, but the
content of those files is templated. See the examples here:
https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration.html#openstack-service-configuration-in-kolla

On Tue, 8 Feb 2022 at 15:19, Satish Patel <satish.txt at gmail.com> wrote:
>
> Thank you mark, i think you found my typo :)  that was it.
>
> How do i group nodes and pass configuration to specific group like.
> for example i have GPU and IB compute nodes. i want to group them so i
> can push out to config to GPU group related GPU and IB (infiniband)
> related IB config
>
> [gpu]
> 1.1.1.1
> 2.2.2.2
> 3.3.3.3
>
> [ib]
> 4.4.4.4
> 5.5.5.5
> 6.6.6.6
>
> [compute:children]
> gpu
> ib
>
> Can i apply config like following for group related?  what is the best
> way to handle groups in kolla-ansible?
>
> /etc/kolla/config/nova/gpu/nova.conf
> /etc/kolla/config/nova/ib/nova.conf
>
> On Tue, Feb 8, 2022 at 4:28 AM Mark Goddard <mark at stackhpc.com> wrote:
> >
> > On Mon, 7 Feb 2022 at 15:11, Satish Patel <satish.txt at gmail.com> wrote:
> > >
> > > Folks,
> > >
> > > I have a working kolla-ansible environment and now I want to push out
> > > some nova custom changes to specific compute nodes and I am trying the
> > > following override but somehow it doesn't work for me.
> > >
> > > Ansible inventory file multinode
> > >
> > > [control]
> > > 192.168.75.141 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> > > 192.168.75.142 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> > > 192.168.75.143 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> > > [compute]
> > > 192.168.75.[144:175] ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
> >
> > FYI you can use hostnames but still use IPs to connect:
> >
> > myhost ansible_host=1.2.3.4
> >
> > >
> > >
> > > I want to change some option on 192.168.75.199 compute server, I don't
> > > have compute name in inventory so i am using IP address for override
> > > but somehow that doesn't work
> > >
> > > /etc/kolla/config/nova/192.168.75.199/nova.conf
> >
> > That is the correct path, when using the default config location.
> >
> > Sanity check: .199 isn't in the above inventory.
> >
> > >
> > > I have tried the following to use hypervisor hostname but that doesn't
> > > work. What am I doing wrong here?
> > >
> > > /etc/kolla/config/nova/COMP01.local/nova.conf
> >
> > We use inventory_hostname to determine the path, so it will be
> > whatever you use as the name in your inventory. In your example it's
> > IPs.
> >
> > >
> > >
> > > Following works for me but they are for global not for specific nodes.
> > > How do i override specific node file?
> > >
> > > /etc/kolla/config/nova/nova-compute.conf
> > >


From mtint.stfc at gmail.com  Wed Feb  9 11:35:40 2022
From: mtint.stfc at gmail.com (Michael STFC)
Date: Wed, 9 Feb 2022 12:35:40 +0100
Subject: Error: Not authorized for image
Message-ID: <CANsWBGtVd2=JX9W+gG=NMrntE5QVfQhq18SFdvoR3zctFF3M9g@mail.gmail.com>

Hi All,

I have a problem with vm. Its in error state and rebooting won?t fixed it
and still no luck.

Error: Failed to perform requested operation on instance
?xxx-production-db?, the instance has an error status: Please try again
later [Error: Not authorized for image
3457dd8a-037a-4360-b77a-059d2782cbbf.].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/c81f0778/attachment.htm>

From satish.txt at gmail.com  Wed Feb  9 12:42:32 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 9 Feb 2022 07:42:32 -0500
Subject: [kolla-ansible] custom configuration override issue.
In-Reply-To: <CAFHSqWoHNPK3XQPoOED9QpHaAdpYhXNow=B+6QVhH0v5FwUwEQ@mail.gmail.com>
References: <CAFHSqWoHNPK3XQPoOED9QpHaAdpYhXNow=B+6QVhH0v5FwUwEQ@mail.gmail.com>
Message-ID: <E8941782-52D8-4AC6-861A-C0E23A5995D7@gmail.com>

Nice!!

[DEFAULT]
{% if 'cell0001' in group_names %}
bandwidth_poll_interval = 100
{% elif 'cell0002' in group_names %}
bandwidth_poll_interval = -1
{% else %}
bandwidth_poll_interval = 300
{% endif %}

Sent from my iPhone

> On Feb 9, 2022, at 4:05 AM, Mark Goddard <mark at stackhpc.com> wrote:
> 
> ?Kolla-ansible won't lookup config files based on group names, but the
> content of those files is templated. See the examples here:
> https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration.html#openstack-service-configuration-in-kolla
> 
>> On Tue, 8 Feb 2022 at 15:19, Satish Patel <satish.txt at gmail.com> wrote:
>> 
>> Thank you mark, i think you found my typo :)  that was it.
>> 
>> How do i group nodes and pass configuration to specific group like.
>> for example i have GPU and IB compute nodes. i want to group them so i
>> can push out to config to GPU group related GPU and IB (infiniband)
>> related IB config
>> 
>> [gpu]
>> 1.1.1.1
>> 2.2.2.2
>> 3.3.3.3
>> 
>> [ib]
>> 4.4.4.4
>> 5.5.5.5
>> 6.6.6.6
>> 
>> [compute:children]
>> gpu
>> ib
>> 
>> Can i apply config like following for group related?  what is the best
>> way to handle groups in kolla-ansible?
>> 
>> /etc/kolla/config/nova/gpu/nova.conf
>> /etc/kolla/config/nova/ib/nova.conf
>> 
>>> On Tue, Feb 8, 2022 at 4:28 AM Mark Goddard <mark at stackhpc.com> wrote:
>>> 
>>> On Mon, 7 Feb 2022 at 15:11, Satish Patel <satish.txt at gmail.com> wrote:
>>>> 
>>>> Folks,
>>>> 
>>>> I have a working kolla-ansible environment and now I want to push out
>>>> some nova custom changes to specific compute nodes and I am trying the
>>>> following override but somehow it doesn't work for me.
>>>> 
>>>> Ansible inventory file multinode
>>>> 
>>>> [control]
>>>> 192.168.75.141 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
>>>> 192.168.75.142 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
>>>> 192.168.75.143 ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
>>>> [compute]
>>>> 192.168.75.[144:175] ansible_ssh_private_key_file=/root/.ssh/nodes_ssh_key
>>> 
>>> FYI you can use hostnames but still use IPs to connect:
>>> 
>>> myhost ansible_host=1.2.3.4
>>> 
>>>> 
>>>> 
>>>> I want to change some option on 192.168.75.199 compute server, I don't
>>>> have compute name in inventory so i am using IP address for override
>>>> but somehow that doesn't work
>>>> 
>>>> /etc/kolla/config/nova/192.168.75.199/nova.conf
>>> 
>>> That is the correct path, when using the default config location.
>>> 
>>> Sanity check: .199 isn't in the above inventory.
>>> 
>>>> 
>>>> I have tried the following to use hypervisor hostname but that doesn't
>>>> work. What am I doing wrong here?
>>>> 
>>>> /etc/kolla/config/nova/COMP01.local/nova.conf
>>> 
>>> We use inventory_hostname to determine the path, so it will be
>>> whatever you use as the name in your inventory. In your example it's
>>> IPs.
>>> 
>>>> 
>>>> 
>>>> Following works for me but they are for global not for specific nodes.
>>>> How do i override specific node file?
>>>> 
>>>> /etc/kolla/config/nova/nova-compute.conf
>>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/7700366a/attachment.htm>

From satish.txt at gmail.com  Wed Feb  9 12:59:49 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 9 Feb 2022 07:59:49 -0500
Subject: Home openstack lab
In-Reply-To: <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
References: <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr>
Message-ID: <62A129DC-4F5D-49EB-BD4C-507C51E48DED@gmail.com>

I would recommend to use container for control plan deployment because then it?s very easy to manage. 

We are running 350 compute node production cloud using 3 controller nodes without issue (except rabbitMQ.. hehe) 

I?m using openstack-ansible for deployment. 


Sent from my iPhone

> On Feb 2, 2022, at 1:20 PM, PAIPURI Mahendra <mahendra.paipuri at cnrs.fr> wrote:
> 
> ?Hello Sean and Jean-Fran?ois,
> 
> Thanks for your answers. I am getting myself into the world of Openstack and I have few questions on similar subject.
> 
> You mentioned that the development team is moving towards Debian images for containers for kolla ansible. Does it mean they will drop the support for CentOS 8 Stream in near future?
> 
> From my understanding, Openstack ansible can be deployed without use of linux containers at all. Did someone try this approach? Is it scalable and stable? The problem is we might have restrictions on using containers at our organisation. So, a container-less solution for deploying and operating Openstack would be very helpful for us.
> 
> At what scale TripleO starts to pay off? We will have a cluster of 100-200 nodes soon and we will deploy Openstack on it. What would be a good deployment method for that scale? 
> 
> Thanks
> 
> Regards
> Mahendra
> 
>> On 2 Feb 2022, at 18:44, Sean Mooney <smooney at redhat.com> wrote:
>> 
>>> On Wed, 2022-02-02 at 17:07 +0000, Michael STFC wrote:
>>> Hi All:
>>> 
>>> I am kind of new to Openstack and want to setup openstack learning env or lab at home.
>>> 
>>> I have 3 HP MicroServers g8 with 16GB RAM and 5 HP MicroServers g7 with 8 GB RAM - all have dual or quad NIC and I have a 24 ports Aruba switch with VXLAN feature, older HP Procurve 24 switch. 
>>> 
>>> I am looking into have 3 nodes for run services and 2 for compute and remaining 3 for Ceph. 
>>> 
>>> Any advise on OS and which openstack distro I should and link to the documentations or guides?
>> most common distros have good support for openstack at this point.
>> there are several installers to choose form personally kolla-ansible is my prefered install openstack ansible might also be good for your scale
>> but i have not used it much. triploe is proably overkill and i would not advise using it as your first into to openstack
>> 
>> so assuming you are not going to use this for developing openstack kolla-ansible on debian or ubuntu with the source install option would be
>> my recommendation it has pretty good support for centos too but i belive they are moveing to mainly using debain images for the contianers
>> going forward so using a deb based host might have less issues
>> 
>> openstack ansibale i belive also supports both the rpm and deb worlds so really you can pick your poision with regard to
>> host OS. i would go with what you are most comforatbale with but ubuntu 20.04 is what most of our upstream ci uses
>> 
>> if you are plannig t do developemnt i would use devstack but if you want this as a home lab to then run workload on i would use somethig else.
>> 
>> for ceph cephadm is proably the way to go and you should be able to integrate a standalone ceph cluster with this deployment.
>> kolla support external ceph and i suspect openstack ansible does too.
>> 
>> one thing to note is i proably woudl proably also run the nova compute serive on the contolers to get the most out of the cluster.
>> 
>> even with only 8gb of ram you can run a full contoler and have 1-2 GB of ram left over for vms
>> so unless you decide to have the contoler also run ceph i would co locate the compute service on the contoler too
>> 
>> if you do plan to have ceph and the openstack contolers coloacated then i would reuse the 3 nodes you planned ot dedicated fro ceph as computes.
>> 
>> you certenly can have each system have a singel role but you can consolidate into a hyperconverd toplogy too.
>>> 
>>> Regards,
>>> 
>>> Michael
>>> 
>>> 
>>> 
>> 
>> 
> 


From benedikt.trefzer at cirrax.com  Wed Feb  9 14:46:42 2022
From: benedikt.trefzer at cirrax.com (Benedikt Trefzer)
Date: Wed, 9 Feb 2022 15:46:42 +0100
Subject: [openstacksdk] create object (eg. snapshot) on behalf of user as admin
Message-ID: <67a46fab-a685-d591-1122-05296d2ecd79@cirrax.com>


Hi list

I like to connect as an amin user to an openstack cloud and create a 
snapshot of a volume in the same project as the volume exists.

I use the openstacksdk to achive this in python.
So far I can connect as admin and create the snapshot but the
snapshot is in the admins project, not in the project of the volume.

Code so far:

from openstack import connect
import openstack.config

conn=connect()

conn.volume.create_snapshot(name='test', description='testing', 
volume='volumeIDinANYproject')

I tried to use
conn.connect_as_project('ProjectID')

but was not successfull.

Please direct me in the correct direction to achive this ! Any help 
appreciated.

Greeting

Benedikt


From pierre at stackhpc.com  Wed Feb  9 15:48:25 2022
From: pierre at stackhpc.com (Pierre Riteau)
Date: Wed, 9 Feb 2022 16:48:25 +0100
Subject: [kolla] [horizon] Custom logos (WAS: [Openstack-operators]
 Horizon Custom Logos (Queens, 13.0.1))
In-Reply-To: <89b0b5ba-1449-1533-a9dc-d5aa7aa3d283@pawsey.org.au>
References: <5B7AEF19.5010502@soe.ucsc.edu>
 <CAD28wk10RO-HL_LW84knO2oXQBwrH3FN0oTWabyTmztOEoimsw@mail.gmail.com>
 <4a74f5c6-5da3-d756-1bd2-5b7fa67ce11a@pawsey.org.au>
 <CAFHSqWr4XC9nSziB6UovX4YxpdUO0VxcLWHrmtifrvKt_h8NiQ@mail.gmail.com>
 <89b0b5ba-1449-1533-a9dc-d5aa7aa3d283@pawsey.org.au>
Message-ID: <CA+ny2syUVrvG0j3w1S+V1cJnM2f8=tMDbedJJG4fs+sotO9RVQ@mail.gmail.com>

On Mon, 17 Jan 2022 at 02:19, Gregory Orange <gregory.orange at pawsey.org.au>
wrote:

> On 13/1/22 5:06 pm, Mark Goddard wrote:
> > On Thu, 13 Jan 2022 at 05:19, Gregory Orange
> > <gregory.orange at pawsey.org.au>  wrote:
> >> We have been using Ubuntu VMs for the control plane until now, so it was
> >> a simple matter of inserting our logo-splash.svg and logo.svg into
> >> /var/lib/openstack-dashboard/static/dashboard/img/  and then restarting
> >> services.
> >>
> >> Now we're switching to Kolla, and the relevant path isn't mounted as is
> >> the case with the likes of /etc/kolla/horizon and /var/log/kolla. We
> >> don't (yet?) build our own container images, so I'm wondering what next.
> >>
> > Typically what we do is create a theme repository, e.g.
> > https://github.com/stackhpc/horizon-theme. This is then built into the
> > image in/etc/openstack-dashboard/themes/<theme>.
> >
> > There is another approach proposed which does not involve rebuilding
> > the image, but it is still WIP:
> > https://review.opendev.org/c/openstack/kolla-ansible/+/761364
>
> Good to know, thank you. For now I have figured out that 'docker cp'ing
> the files into place works, although of course that doesn't persist
> across things like reconfigure runs. Curiously though it does persist
> with a container restart, even though I didn't `commit` the change to
> the container image.
>
> Cheers,
> Greg.
>

Hello Greg,

When you restart the Horizon container, it keeps running from the existing,
modified container image. The container image is only recreated from the
pulled image by deploy or reconfigure actions in Kolla. So, if you don't
want to use Kolla to build a new image (which I would recommend as you can
keep your modifications in version control!), you can `docker commit` your
changes into a new image, which you could push to your local registry for
redeploying later.

Best wishes,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/ac131936/attachment.htm>

From katonalala at gmail.com  Wed Feb  9 15:56:10 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Wed, 9 Feb 2022 16:56:10 +0100
Subject: [election][Neutron]PTL candidacy for Z
Message-ID: <CALg0jKkbDDZJwtVVQ-1SNM0TPRh0z8X5KhkEC_jzGE4M5bRx4Q@mail.gmail.com>

Hello Openstack Community,

I write to submit my candidacy for the Neutron PTL position during the
Z cycle.

I have been PTL for the Yoga cycle, and I would like to serve the community
for another cycle.

During the last few cycles the team faced a lot of challenges, like:
* Lack of review capacity, which on the other hand means that we have a
lot to review, and that is good.
* Channel in developers from new companies.
* Keep Neutron stable while at the same time keep the speed of feature
development.
* CI instabilities.
* Keep coverage and decrease the load Neutron jobs cause in the infra.

The team tried to address these, so we have biweekly video meeting for
CI issues (on the other week we kept the IRC for CI meeting), we increased
the size of the drivers team, we included back some retired stadium project
 with new developers who would like to maintain them, or worked actively to
decrease the amount of jobs we execute for each commit.

As a summary I would like to continue with a focus on these items to keep
Networking in Openstack stable and inclusive.

Thank you for your time and consideration.

Lajos Katona (lajoskatona)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/2a62c7ee/attachment.htm>

From cbouchar at redhat.com  Wed Feb  9 12:37:18 2022
From: cbouchar at redhat.com (Carol Bouchard)
Date: Wed, 9 Feb 2022 07:37:18 -0500
Subject: [ironic] kickstart/iso configuration
Message-ID: <CACkzpE64yFdNd3O7Qo1pf0uLRMv6Np9x+abr07LTKohyBCUX7A@mail.gmail.com>

Ironic folks:

I've set-up bifrost which is spawning two VMs to test with.  I'm using the
xena branch
for both bifrost and ironic.  Bifrost sets these VMs up as
whole-disk-images.  I've
undeployed one VM and trying to deploy the same VM by using the default
kickstart
file and a RHEL7 ISO file but I'm not having any success.  Could you
suggest what
configuration changes are expected in this case to get this to work? What
would you expect
deploy-interface and instance-info to look like?

BTW And I've applied portions (changes to cache_ramdisk_kernel() only) of
the patch for https://review.opendev.org/c/openstack/ironic/+/827924.

Carol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/e745eee8/attachment-0001.htm>

From lokendrarathour at gmail.com  Wed Feb  9 14:58:05 2022
From: lokendrarathour at gmail.com (Lokendra Rathour)
Date: Wed, 9 Feb 2022 20:28:05 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
Message-ID: <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>

Hi Harald,
Responding on behalf of Anirudh's email:
Thanks for the response and we now do understand that we are getting IP
from the expected DHCP server.

We tried the scenario and here are our findings, Our admin and internal
endpoints are on subnet: 30.30.30.x
public : 10.0.1.x

(overcloud) [stack at undercloud ~]$ *OpenStack endpoint list | grep ironic*
| 04c163251e5546769446a4fa4fa20484 | regionOne | ironic           |
baremetal               | True    | admin     | http://30.30.30.213:6385
                    |
| 5c8557ae639a4898bdc6121f6e873724 | regionOne | ironic           |
baremetal               | True    | internal  | http://30.30.30.213:6385
                    |
| 62e07a3b2f3f4158bb27d8603a8f5138 | regionOne | ironic-inspector |
baremetal-introspection | True    | public    | http://10.0.1.88:5050
                   |
| af29bd64513546409f44cc5d56ea1082 | regionOne | ironic-inspector |
baremetal-introspection | True    | internal  | http://30.30.30.213:5050
                    |
| b76cdb5e77c54fc6b10cbfeada0e8bf5 | regionOne | ironic-inspector |
baremetal-introspection | True    | admin     | http://30.30.30.213:5050
                    |
| bd2954f41e49419f85669990eb59f51a | regionOne | ironic           |
baremetal               | True    | public    | http://10.0.1.88:6385
                   |
(overcloud) [stack at undercloud ~]$


we are following the flat default n/w approach for ironic provisioning, for
which we are creating a flat network on baremetal physnet. we are still
getting IP from neutron range (172.23.3.220 - 172.23.3.240)  -
172.23.3.240.

Further, we found that once IP (172.23.3.240) is allocated to baremetal
node, it looks for 30.30.30.220( IP of one of the three controllers) for
pxe booting.
Checking the same controllers logs we found that

*`/var/lib/ironic/tftpboot/pxelinux.cfg/` directory exists,* but then there
is *no file matching the mac *address of the baremetal node.

Also checking the *extra_dhcp_opts* we found this:
(overcloud) [stack at undercloud ~]$ *openstack port show
d7e573bf-1028-437a-8118-a2074c7573b2 | grep "extra_dhcp_opts"*

| extra_dhcp_opts         | ip_version='4', opt_name='tag:ipxe,67',
opt_value='http://30.30.30.220:8088/boot.ipxe'


                         [image: image.png]
*Few points as observations:*

   1. Although the baremetal network (172.23.3.x) is routable to the admin
   network (30.30.30.x), but it gets timeout at this window.
   2. in TCPDump we are only getting read requests.
   3. `openstack baremetal node list
      1. (overcloud) [stack at undercloud ~]$ openstack baremetal node list

      +--------------------------------------+------+---------------+-------------+--------------------+-------------+
      | UUID                                 | Name | Instance UUID | Power
      State | Provisioning State | Maintenance |

      +--------------------------------------+------+---------------+-------------+--------------------+-------------+
      | 7066fbe1-9c29-4702-9cd4-2b55daf19630 | bm1  | None          | power
      on    | clean wait         | False       |

      +--------------------------------------+------+---------------+-------------+--------------------+-------------+
      4.  `openstack baremetal node show <node-uuid>`
      1.
      (overcloud) [stack at undercloud ~]$ openstack baremetal node show bm1

      +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
      | Field                  | Value


                                                           |

      +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
      | allocation_uuid        | None


                                                          |
      | automated_clean        | None


                                                          |
      | bios_interface         | no-bios


                                                           |
      | boot_interface         | ipxe


                                                          |
      | chassis_uuid           | None


                                                          |
      | clean_step             | {}


                                                          |
      | conductor              | overcloud-controller-0.localdomain


                                                          |
      | conductor_group        |


                                                           |
      | console_enabled        | False


                                                           |
      | console_interface      | ipmitool-socat


                                                          |
      | created_at             | 2022-02-09T14:21:24+00:00


                                                           |
      | deploy_interface       | iscsi


                                                           |
      | deploy_step            | {}


                                                          |
      | description            | None


                                                          |
      | driver                 | ipmi


                                                          |
      | driver_info            | {'ipmi_address': '10.0.1.183',
      'ipmi_username': 'hsc', 'ipmi_password': '******', 'ipmi_terminal_port':
      623, 'deploy_kernel': '9e1365b6-261a-42a2-abfe-40158945de57',
      'deploy_ramdisk': 'fe608dd2-ce86-4faf-b4b8-cc5cb143eb56'}
           |
      | driver_internal_info   | {'agent_erase_devices_iterations': 1,
      'agent_erase_devices_zeroize': True,
'agent_continue_if_ata_erase_failed':
      False, 'agent_enable_ata_secure_erase': True, 'disk_erasure_concurrency':
      1, 'last_power_state_change': '2022-02-09T14:23:39.525629'} |
      | extra                  | {}


                                                          |
      | fault                  | None


                                                          |
      | inspect_interface      | inspector


                                                           |
      | inspection_finished_at | None


                                                          |
      | inspection_started_at  | None


                                                          |
      | instance_info          | {}


                                                          |
      | instance_uuid          | None


                                                          |
      | last_error             | None


                                                          |
      | maintenance            | False


                                                           |
      | maintenance_reason     | None


                                                          |
      | management_interface   | ipmitool


                                                          |
      | name                   | bm1


                                                           |
      | network_interface      | flat


                                                          |
      | owner                  | None


                                                          |
      | power_interface        | ipmitool


                                                          |
      | power_state            | power on


                                                          |
      | properties             | {'cpus': 20, 'cpu_arch': 'x86_64',
      'capabilities': 'boot_option:local,boot_mode:uefi', 'memory_mb': 63700,
      'local_gb': 470, 'vendor': 'hewlett-packard'}
                                                                      |
      | protected              | False


                                                           |
      | protected_reason       | None


                                                          |
      | provision_state        | clean wait


                                                          |
      | provision_updated_at   | 2022-02-09T14:24:05+00:00


                                                           |
      | raid_config            | {}


                                                          |
      | raid_interface         | no-raid


                                                           |
      | rescue_interface       | agent


                                                           |
      | reservation            | None


                                                          |
      | resource_class         | bm1


                                                           |
      | storage_interface      | noop


                                                          |
      | target_power_state     | None


                                                          |
      | target_provision_state | available


                                                           |
      | target_raid_config     | {}


                                                          |
      | traits                 | []


                                                          |
      | updated_at             | 2022-02-09T14:24:05+00:00


                                                           |
      | uuid                   | 7066fbe1-9c29-4702-9cd4-2b55daf19630


                                                          |
      | vendor_interface       | ipmitool


                                                          |

      +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
      (overcloud) [stack at undercloud ~]$



*Queries:*

   - What are the settings we can do for successfully pxe-boot of the
   baremetal node and provisioning our node successfully ?





On Tue, Feb 8, 2022 at 6:27 PM Harald Jensas <hjensas at redhat.com> wrote:

> On 2/7/22 13:47, Anirudh Gupta wrote:
> > Hi Julia,
> >
> > Thanks a lot for your responses and support.
> > To Update on the ongoing issue, I tried deploying the overcloud with
> > your valuable suggestions i.e by passing "*DhcpAgentNotification: true*"
> > in ironic-overcloud.yaml
> > The setup came up successfully, but with this configuration the IP
> > allocated on the system is one which is being configured while creating
> > the subnet in openstack.
> >
> > image.png
> >
> > The system is still getting the IP (172.23.3.212) from neutron. The
> > subnet range was configured as *172.23.3.210-172.23.3.240 *while
> > creating the provisioning subnet.
>
>
> The node is supposed to get an IP address from the neutron subnet on the
> provisioning network when:
> a) provisioning node
> b) cleaning node.
>
> When you do "baremetal node provide" cleaning is most likely
> automatically initiated. (Since cleaning is enabled by default for
> Ironic in overcloud AFIK.)
>
> The only time you will get an address from the IronicInspectorSubnets
> (ip_range: 172.23.3.100,172.23.3.150 in your case) is when you start
> ironic node introspection.
>
> > The system gets stuck here and no action is performed after this.
> >
>
> It seems the system is getting an address from the expected DHCP server,
> but it does not boot. I would start looking into the pxe properties in
> the DHCP Reply.
>
> What is the status of the node in ironic at this stage?
>   `openstack baremetal node list`
>   `openstack baremetal node show <node-uuid>`
>
> Check the `extra_dhcp_opts` on the neutron port, it should set the
> nextserver and bootfile parameters. Does the bootfile exist in
> /var/lib/ironic/tftpboot? Inspect the
> `/var/lib/ironic/tftpboot/pxelinux.cfg/` directory, you should see a
> file matching the MAC address of your system. Does the content make sense?
>
> Can you capture DHCP and TFTP traffic on the provisioning network?
>
> > Is there any way to resolve this and make successful  provisioning the
> > baremetal node in *TripleO Train Release* (Since RHOSP 16 was on Train,
> > so I thought to go with that version for better stability)
> >
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
> > <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
> >
> >
> > I have some queries:
> >
> >  1. Is passing "*DhcpAgentNotification: true" *enough or do we have to
> >     make some other changes as well?
>
> I belive in train "DhcpAgentNotification" defaults to True.
> The change to default to false was added more recently, and it was not
> backported.
> (https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761)
>
> NOTE, the environment for enabling ironi for the overcloud
> 'environments/services/ironic-overcloud.yaml' overrides this to 'true'
> in later releases.
>
> >  2. Although there are some security concerns specified in the document,
> >     but Currently I am focusing on the default flat bare metal approach
> >     which has dedicated interface for bare metal Provisioning. There is
> >     one composable method approach as well. Keeping aside the security
> >     concerns, which approach is better and functional?
> >      1.
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
> >         <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
> >
>
> Both should work, using the composable network is more secure since
> baremetal nodes does not have access to the control plane network.
>
> >  3. Will moving to upper openstack release version make this deployment
> >     possible?
> >      1. If Yes, which release should I go with as till wallaby the
> >         ironic-overcloud.yml file has no option of including
> >         "*DhcpAgentNotification: true*" by default
> >          1.
> https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
> >             <
> https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
> >
> >
> >
> > Looking forward for your valuable feedback/response.
> >
> > Regards
> > Anirudh Gupta
> >
> >
> > On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta <anyrude10 at gmail.com
> > <mailto:anyrude10 at gmail.com>> wrote:
> >
> >     Hi,
> >
> >     Surely I'll revert the status once it gets deployed.
> >     Bdw the suspicion is because of Train Release or it is something
> else?
> >
> >     Regards
> >     Anirudh Gupta
> >
> >     On Fri, 4 Feb, 2022, 20:29 Julia Kreger,
> >     <juliaashleykreger at gmail.com <mailto:juliaashleykreger at gmail.com>>
> >     wrote:
> >
> >
> >
> >         On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta
> >         <anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>> wrote:
> >
> >             Hi Julia
> >
> >             Thanks for your response.
> >
> >             Earlier I was passing both ironic.yaml and
> >             ironic-overcloud.yaml located at path
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/
> >
> >             My current understanding now says that since I am using OVN,
> >             not OVS so I should pass only ironic-overcloud.yaml in my
> >             deployment.
> >
> >             I am currently on Train Release and my default
> >             ironic-overcloud.yaml file has no such entry
> >             DhcpAgentNotification: true
> >
> >
> >         I suspect that should work. Let us know if it does.
> >
> >             I would add this there and re deploy the setup.
> >
> >             Would that be enough to make my deployment successful?
> >
> >             Regards
> >             Anirudh Gupta
> >
> >
> >             On Fri, 4 Feb, 2022, 18:40 Julia Kreger,
> >             <juliaashleykreger at gmail.com
> >             <mailto:juliaashleykreger at gmail.com>> wrote:
> >
> >                 It is not a matter of disabling OVN, but a matter of
> >                 enabling the dnsmasq service and notifications.
> >
> >
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
> >                 <
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
> >
> >                 may provide some insight.
> >
> >                 I suspect if you're using stable/wallaby based branches
> >                 and it is not working, there may need to be a patch
> >                 backported by the TripleO maintainers.
> >
> >                 On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta
> >                 <anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>>
> wrote:
> >
> >                     Hi Julia,
> >
> >                     Thanks for your response.
> >                     For the overcloud deployment, I am executing the
> >                     following command:
> >
> >                     openstack overcloud deploy --templates \
> >                          -n /home/stack/templates/network_data.yaml \
> >                          -r /home/stack/templates/roles_data.yaml \
> >                          -e /home/stack/templates/node-info.yaml \
> >                          -e /home/stack/templates/environment.yaml \
> >                          -e
> >
>  /home/stack/templates/environments/network-isolation.yaml
> >                     \
> >                          -e
> >
>  /home/stack/templates/environments/network-environment.yaml
> >                     \
> >                          -e
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
> >                     \
> >                          -e
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
> >                     \
> >                          -e
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
> >                     \
> >                          -e
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
> >                     \
> >                          -e /home/stack/templates/ironic-config.yaml \
> >                          -e
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
> >                     \
> >                          -e
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml
> >                     \
> >                          -e /home/stack/containers-prepare-parameter.yaml
> >
> >                     I can see some OVN related stuff in my roles_data
> >                     and environments/network-isolation.yaml
> >
> >                     [stack at undercloud ~]$ grep -inr "ovn"
> >                     roles_data.yaml:34: *OVNCMSOptions:
> >                     "enable-chassis-as-gw"*
> >                     roles_data.yaml:168:    -
> >                     *OS::TripleO::Services::OVNDBs*
> >                     roles_data.yaml:169:    -
> >                     *OS::TripleO::Services::OVNController*
> >                     roles_data.yaml:279:    -
> >                     *OS::TripleO::Services::OVNController*
> >                     roles_data.yaml:280:    -
> >                     *OS::TripleO::Services::OVNMetadataAgent*
> >                     environments/network-isolation.yaml:16:
> >                     *OS::TripleO::Network::Ports::OVNDBsVipPort:
> >                     ../network/ports/vip.yaml*
> >                     *
> >                     *
> >                     What is your recommendation and how to disable
> >                     OVN....should I remove it from roles_data.yaml and
> >                     then render so that it doesn't get generated
> >                     in environments/network-isolation.yaml
> >                     Please suggest some pointers.
> >
> >                     Regards
> >                     Anirudh Gupta
> >                     *
> >                     *
> >                     *
> >                     *
> >
> >
> >
> >
> >                     It seems OVN is getting installed in ironic
> >
> >
> >                     On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger
> >                     <juliaashleykreger at gmail.com
> >                     <mailto:juliaashleykreger at gmail.com>> wrote:
> >
> >                         My guess: You're running OVN. You need
> >                         neutron-dhcp-agent running as well. OVN disables
> >                         it by default and OVN's integrated DHCP service
> >                         does not support options for network booting.
> >
> >                         -Julia
> >
> >                         On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta
> >                         <anyrude10 at gmail.com
> >                         <mailto:anyrude10 at gmail.com>> wrote:
> >
> >                             Hi Team
> >
> >                             I am trying to Provision Bare Metal Node
> >                             from my tripleo Overcloud.
> >                             For this, while deploying the overcloud, I
> >                             have followed the *"default flat" *network
> >                             approach specified in the below link
> >
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
> >                             <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
> >
> >
> >                             Just to highlight the changes, I have
> >                             defined the
> >
> >                             *ironic-config.yaml*
> >
> >                             parameter_defaults:
> >                                  ...
> >                                  ...
> >                                  IronicIPXEEnabled: true
> >                                  IronicInspectorSubnets:
> >                                  - ip_range: *172.23.3.100,172.23.3.150*
> >                                  IronicInspectorInterface: 'br-baremetal'
> >
> >                             Also modified the file
> >                             *~/templates/network-environment.yaml*
> >
> >                             parameter_defaults:
> >                                NeutronBridgeMappings:
> >                             datacentre:br-ex,baremetal:br-baremetal
> >                                NeutronFlatNetworks: datacentre,baremetal
> >
> >                             With this I have Followed all the steps of
> >                             creating br-baremetal bridge on controller,
> >                             given in the link below:
> >
> >
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
> >                             <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
> >
> >
> >                                - type: ovs_bridge
> >                                   name: br-baremetal
> >                                   use_dhcp: false
> >                                   members:
> >                                   - type: interface
> >                                     name: nic3
> >
> >                             Post Deployment, I have also create a flat
> >                             network on "datacentre" physical network and
> >                             subnet having the range
> >                             *172.23.3.200,172.23.3.240 *(as suggested
> >                             subnet is same as of inspector and range is
> >                             different) and the router
> >
> >                             Also created a baremetal node and ran
> >                             *"openstack baremetal node manage bm1", *the
> >                             state of which was a success.
> >
> >                             Observation:
> >
> >                             On executing "openstack baremetal node
> >                             *provide* bm1", the machine gets power on
> >                             and ideally it should take an IP from ironic
> >                             inspector range and PXE Boot.
> >                             But nothing of this sort happens and we see
> >                             an IP from neutron range "*172.23.3.239*"
> >                             (attached the screenshot)
> >
> >                             image.png
> >
> >                             I have checked overcloud ironic inspector
> >                             podman logs alongwith the tcpdump.
> >                             In tcpdump, I can only see dhcp discover
> >                             request on br-baremetal and nothing happens
> >                             after that.
> >
> >                             I have tried to explain my issue in detail,
> >                             but I would be happy to share more details
> >                             in case still required.
> >                             Can someone please help in resolving my
> issue.
> >
> >                             Regards
> >                             Anirudh Gupta
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/88fba8e0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 138084 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/88fba8e0/attachment-0001.png>

From jcrawford at quadrivium.com  Wed Feb  9 15:20:14 2022
From: jcrawford at quadrivium.com (Joshua Crawford)
Date: Wed, 9 Feb 2022 15:20:14 +0000
Subject: [Update Process]
In-Reply-To: <CAOAKi8zkEaPSFWspFmOumNgH5_A8=LajT6_XWD4qW7KoFA-Y3w@mail.gmail.com>
References: <1d26f9142927f518c3de872e764803db2b9e3a7c.camel@quadrivium.com>
 <CAOAKi8zkEaPSFWspFmOumNgH5_A8=LajT6_XWD4qW7KoFA-Y3w@mail.gmail.com>
Message-ID: <b81efc9c0c53e550b239dfbc014f50c9ca75fadf.camel@quadrivium.com>

I talked to the engineer that originally set it up. He said that it was
installed manually using instructions he found on openstack's site. He
said that he had tried several "automatic" installers that failed. I
believe, by that, he means that he used apt to install the packages
individually. He did say that while the server is still on the same
version of ubuntu that we originally started with, he has updated
openstack and swift several times.

So, I guess the question is, will our version of openstack run on
ubuntu 18 or 20 so that we can upgrade the OS and then use apt to
update openstack?

Thank you,
joshua.


[cid:d105ac7d-e828-4289-8ff1-70d919cdb057.jpg]
[cid:Quadrivium-Logo_Horizontal-OneColor-CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg]
        Joshua Crawford | Senior Engineer
Quadrivium Inc. | 5537 Bleaux Ave.
Springdale, AR 72762
479.419.4600 | quadrivium.com<https://quadrivium.com>
[cid:cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg]


This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.

-----Original Message-----
From: Laurent Dumont <laurentfdumont at gmail.com>
To: Joshua Crawford <jcrawford at quadrivium.com>
Cc: openstack-discuss at lists.openstack.org <
openstack-discuss at lists.openstack.org>
Subject: Re: [Update Process]
Date: Tue, 08 Feb 2022 20:56:20 -0500

EXTERNAL EMAIL

That's a loaded question.
How was Openstack deployed?
How was the Swift component deployed?
Answering these two questions will impact what tooling you can use to
upgrade your packages. It will be split between the Openstack packages
and the regular distro packages.

On Tue, Feb 8, 2022 at 11:17 AM Joshua Crawford <
jcrawford at quadrivium.com> wrote:
> Hi,
>
> I have been given the task of updating our openstack/swift setup.
> Currently, we are on openstack 2.3.1 with python-swiftclient 3.0.0 on
> Ubuntu 16.04. My plan is to upgrade Ubuntu to 18.04 and then to
> 20.04.
> Then focus on updating openstack and swift.
>
> I do not have any previous experience with openstack or swift, but
> from
> what I have read so far, our current version is not supported on
> anything newer than Ubuntu 16.04. Should I revise my plan and look at
> updating openstack/swift first, or is my plan to update Ubuntu first
> a
> good path forward.
>
> Thank you,
> joshua.
>
>
> [cid:d105ac7d-e828-4289-8ff1-70d919cdb057.jpg]
> [cid:Quadrivium-Logo_Horizontal-OneColor-
> CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg]
>         Joshua Crawford | Senior Engineer
> Quadrivium Inc. | 5537 Bleaux Ave.
> Springdale, AR 72762
> 479.419.4600 | quadrivium.com<https://quadrivium.com>
> [cid:cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg]
>
>
> This message is confidential. It may also be privileged or otherwise
> protected by work product immunity or other legal rules. If you have
> received it by mistake, please let us know by e-mail reply and delete
> it from your system; you may not copy this message or disclose its
> contents to anyone. The integrity and security of this message cannot
> be guaranteed on the Internet.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Quadrivium-Logo_Horizontal-OneColor-CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg
Type: image/jpeg
Size: 13098 bytes
Desc: Quadrivium-Logo_Horizontal-OneColor-CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/30e88360/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg
Type: image/jpeg
Size: 17743 bytes
Desc: cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/30e88360/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Review_email_graphic_horizontal_77598f78-471b-42f6-9459-d48ed6e721d2.png
Type: image/png
Size: 12060 bytes
Desc: Review_email_graphic_horizontal_77598f78-471b-42f6-9459-d48ed6e721d2.png
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/30e88360/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d105ac7d-e828-4289-8ff1-70d919cdb057.jpg
Type: image/jpeg
Size: 4475 bytes
Desc: d105ac7d-e828-4289-8ff1-70d919cdb057.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/30e88360/attachment-0005.jpg>

From moreira.belmiro.email.lists at gmail.com  Wed Feb  9 16:34:43 2022
From: moreira.belmiro.email.lists at gmail.com (Belmiro Moreira)
Date: Wed, 9 Feb 2022 17:34:43 +0100
Subject: [election][tc] Non-candidacy
Message-ID: <CAPkQhneUECHGXvr8hsgO=kE=pOqwihtPUq9H+1RoYJePDVAB-A@mail.gmail.com>

Dear all,
I would like to let you know that I won't run for the Technical Committee
(TC).

After 2 years in this role I believe that it?s time for some rotation.
It was a pleasure to work with all of you. Thank you for this amazing
experience.

cheers,
Belmiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/240623a9/attachment.htm>

From laurentfdumont at gmail.com  Wed Feb  9 16:50:07 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Wed, 9 Feb 2022 11:50:07 -0500
Subject: [Update Process]
In-Reply-To: <b81efc9c0c53e550b239dfbc014f50c9ca75fadf.camel@quadrivium.com>
References: <1d26f9142927f518c3de872e764803db2b9e3a7c.camel@quadrivium.com>
 <CAOAKi8zkEaPSFWspFmOumNgH5_A8=LajT6_XWD4qW7KoFA-Y3w@mail.gmail.com>
 <b81efc9c0c53e550b239dfbc014f50c9ca75fadf.camel@quadrivium.com>
Message-ID: <CAOAKi8yyNrWuzJoaiB3_jxU4zvr8D1qrn5ReKsPYoy=XW139gw@mail.gmail.com>

I can't offer much help, but the versions you listed seem to be for the
openstack-client + openstack-client-swift. These two are used to talk to
the Openstack Swift.

You'll have to find your version of Swift running in Openstack and look at
the upgrade process. Like you mentioned, you might have to also upgrade
Ubuntu to 18.04

On Wed, Feb 9, 2022 at 10:20 AM Joshua Crawford <jcrawford at quadrivium.com>
wrote:

> I talked to the engineer that originally set it up. He said that it was
> installed manually using instructions he found on openstack's site. He
> said that he had tried several "automatic" installers that failed. I
> believe, by that, he means that he used apt to install the packages
> individually. He did say that while the server is still on the same
> version of ubuntu that we originally started with, he has updated
> openstack and swift several times.
>
> So, I guess the question is, will our version of openstack run on
> ubuntu 18 or 20 so that we can upgrade the OS and then use apt to
> update openstack?
>
> Thank you,
> joshua.
>
>
> [cid:d105ac7d-e828-4289-8ff1-70d919cdb057.jpg]
>
> [cid:Quadrivium-Logo_Horizontal-OneColor-CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg]
>         Joshua Crawford | Senior Engineer
> Quadrivium Inc. | 5537 Bleaux Ave.
> Springdale, AR 72762
> 479.419.4600 | quadrivium.com<https://quadrivium.com>
> [cid:cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg]
>
>
> This message is confidential. It may also be privileged or otherwise
> protected by work product immunity or other legal rules. If you have
> received it by mistake, please let us know by e-mail reply and delete it
> from your system; you may not copy this message or disclose its contents to
> anyone. The integrity and security of this message cannot be guaranteed on
> the Internet.
>
> -----Original Message-----
> From: Laurent Dumont <laurentfdumont at gmail.com>
> To: Joshua Crawford <jcrawford at quadrivium.com>
> Cc: openstack-discuss at lists.openstack.org <
> openstack-discuss at lists.openstack.org>
> Subject: Re: [Update Process]
> Date: Tue, 08 Feb 2022 20:56:20 -0500
>
> EXTERNAL EMAIL
>
> That's a loaded question.
> How was Openstack deployed?
> How was the Swift component deployed?
> Answering these two questions will impact what tooling you can use to
> upgrade your packages. It will be split between the Openstack packages
> and the regular distro packages.
>
> On Tue, Feb 8, 2022 at 11:17 AM Joshua Crawford <
> jcrawford at quadrivium.com> wrote:
> > Hi,
> >
> > I have been given the task of updating our openstack/swift setup.
> > Currently, we are on openstack 2.3.1 with python-swiftclient 3.0.0 on
> > Ubuntu 16.04. My plan is to upgrade Ubuntu to 18.04 and then to
> > 20.04.
> > Then focus on updating openstack and swift.
> >
> > I do not have any previous experience with openstack or swift, but
> > from
> > what I have read so far, our current version is not supported on
> > anything newer than Ubuntu 16.04. Should I revise my plan and look at
> > updating openstack/swift first, or is my plan to update Ubuntu first
> > a
> > good path forward.
> >
> > Thank you,
> > joshua.
> >
> >
> > [cid:d105ac7d-e828-4289-8ff1-70d919cdb057.jpg]
> > [cid:Quadrivium-Logo_Horizontal-OneColor-
> > CyberSecurityServices_456360a7-a556-4b83-b682-08dcceeef14a.jpg]
> >         Joshua Crawford | Senior Engineer
> > Quadrivium Inc. | 5537 Bleaux Ave.
> > Springdale, AR 72762
> > 479.419.4600 | quadrivium.com<https://quadrivium.com>
> > [cid:cyber-verify-2021-AAA_2ce098a9-58cb-442b-9293-b75ce40d6ff4.jpg]
> >
> >
> > This message is confidential. It may also be privileged or otherwise
> > protected by work product immunity or other legal rules. If you have
> > received it by mistake, please let us know by e-mail reply and delete
> > it from your system; you may not copy this message or disclose its
> > contents to anyone. The integrity and security of this message cannot
> > be guaranteed on the Internet.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/5792b0c5/attachment.htm>

From gmann at ghanshyammann.com  Wed Feb  9 17:20:13 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Feb 2022 11:20:13 -0600
Subject: [all][tc] Relmgt team position on release cadence
In-Reply-To: <fc5569d6-15e6-4d33-b0f4-2d619f90e732@www.fastmail.com>
References: <40f6f51b-6903-1afe-7318-0689b2af482d@openstack.org>
 <8301ef05-4011-43e9-beec-66f6aeeb00f9@www.fastmail.com>
 <20211129130957.3poysdeqsufkp3pg@yuggoth.org>
 <f2c4ab93-a1e1-475c-8b35-1b303b8fb96b@www.fastmail.com>
 <d28fc7ccfecd753561e1d395c672e987f95eb748.camel@redhat.com>
 <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com>
 <CAF7gwdiUF2wj7RqN-LzwvwH1FQ1A7j=F-CikHKS0ct8AKNAdJg@mail.gmail.com>
 <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org>
 <CAF7gwdhnS_101_Ljf++V=-jGwKZ_NUm6gn+Jzo_N-VDwDuvayw@mail.gmail.com>
 <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com>
 <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
 <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>
 <fc5569d6-15e6-4d33-b0f4-2d619f90e732@www.fastmail.com>
Message-ID: <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com>

 ---- On Wed, 02 Feb 2022 13:17:19 -0600 Jean-Philippe Evrard <openstack at a.spamming.party> wrote ----
 > On Tue, Feb 1, 2022, at 23:14, Ghanshyam Mann wrote:
 > > I might not be available this week, we will schedule this meeting next 
 > > week or so.
 > 
 > Ok, I hope I won't miss the next date then! :)
 > Thanks for organising this, Ghanshyam.

We will meet tomorrow right after the TC meeting.

Time: 10th Feb, 16:00 UTC
Location: Voice/Video call @ https://meetpad.opendev.org/OpenStackReleasecadence

-gmann

 > 
 > Regards,
 > JP
 > 
 > 


From gmann at ghanshyammann.com  Wed Feb  9 17:21:40 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Feb 2022 11:21:40 -0600
Subject: [election][tc] Non-candidacy
In-Reply-To: <CAPkQhneUECHGXvr8hsgO=kE=pOqwihtPUq9H+1RoYJePDVAB-A@mail.gmail.com>
References: <CAPkQhneUECHGXvr8hsgO=kE=pOqwihtPUq9H+1RoYJePDVAB-A@mail.gmail.com>
Message-ID: <17edf814d5f.b243e1c467675.9108929463991606989@ghanshyammann.com>

Thanks, Belmiro for all your contribution to TC and for always being helpful.

-gmann

 ---- On Wed, 09 Feb 2022 10:34:43 -0600 Belmiro Moreira <moreira.belmiro.email.lists at gmail.com> wrote ----
 > Dear all,
 > I would like to let you know that I won't run for the Technical Committee (TC).
 > 
 > After 2 years in this role I believe that it?s time for some rotation.
 > It was a pleasure to work with all of you. Thank you for this amazing experience.
 > 
 > cheers,
 > Belmiro
 > 


From juliaashleykreger at gmail.com  Wed Feb  9 17:40:29 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Wed, 9 Feb 2022 09:40:29 -0800
Subject: [ironic] kickstart/iso configuration
In-Reply-To: <CACkzpE64yFdNd3O7Qo1pf0uLRMv6Np9x+abr07LTKohyBCUX7A@mail.gmail.com>
References: <CACkzpE64yFdNd3O7Qo1pf0uLRMv6Np9x+abr07LTKohyBCUX7A@mail.gmail.com>
Message-ID: <CAF7gwdiN1R_bd3vKzAUO1=5zNzzcjBgL1XhZCmTH+YthWaZbFw@mail.gmail.com>

An ISO file? Could you provide updated insight into your instance_info
settings which are being passed?

I ask because direct ISO booting with the "anaconda" deploy interface
is not something which exists. ISO booting is reserved for virtual
media and the "ramdisk" deployment interface.

On Wed, Feb 9, 2022 at 8:11 AM Carol Bouchard <cbouchar at redhat.com> wrote:
>
> Ironic folks:
>
> I've set-up bifrost which is spawning two VMs to test with.  I'm using the xena branch
> for both bifrost and ironic.  Bifrost sets these VMs up as whole-disk-images.  I've
> undeployed one VM and trying to deploy the same VM by using the default kickstart
> file and a RHEL7 ISO file but I'm not having any success.  Could you suggest what
> configuration changes are expected in this case to get this to work? What would you expect
> deploy-interface and instance-info to look like?
>
> BTW And I've applied portions (changes to cache_ramdisk_kernel() only) of the patch for https://review.opendev.org/c/openstack/ironic/+/827924.
>
> Carol
>
>


From james at openstack.org  Wed Feb  9 18:04:30 2022
From: james at openstack.org (James Cole)
Date: Wed, 9 Feb 2022 12:04:30 -0600
Subject: [Skyline] Project mascot to review
In-Reply-To: <bd13db19-d939-3af2-336c-907778c166b0@gmail.com>
References: <54D2CC84-6134-4B62-801D-3C6CB93CBC79@openstack.org>
 <A7C3C22B-43C1-4CEC-8574-5537DFD02B58@openstack.org>
 <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org>
 <bd13db19-d939-3af2-336c-907778c166b0@gmail.com>
Message-ID: <4BC6F318-61F0-498F-A635-C42902C93238@openstack.org>

Hi again everyone, 

I wanted to share final files with you so you can begin using them. These are available in different formats and also have text added in the same style as all the other project logos. We are also working to get the files up on https://www.openstack.org/project-mascots/ <https://www.openstack.org/project-mascots/> but they aren?t there quite yet. 

Download: https://www.dropbox.com/sh/lr5axo1m84z8s57/AAC2V4CezqXLBE3GjCydcAKFa?dl=0

Thanks for all your feedback on this project!

-James 

> On Feb 1, 2022, at 4:05 PM, Jay Bryant <jungleboyj at gmail.com> wrote:
> 
> Along with others I think the non-overlapping one looks best.  A really nice mascot design!
> 
> Thanks!
> 
> Jay
> 
> 
> 
> On 1/31/2022 3:51 PM, James Cole wrote:
>> Hi everyone, 
>> 
>> Thank you for the additional feedback over the weekend. I wanted to show you the white option both with overlapping spots (option 1) and without overlapping spots (option 2). Is there a clear winner between these two? PDF attached and viewable via Dropbox here <https://www.dropbox.com/s/n6og0jb7lx1feri/20220131_Mascots%20Project-r2.pdf?dl=0>. 
>> 
>> Thanks! 
>> 
>> -James 
>> 
>> 
>> 
>> 
>>> On Jan 28, 2022, at 12:20 PM, James Cole <james at openstack.org <mailto:james at openstack.org>> wrote:
>>> 
>>> Hi again everyone, 
>>> 
>>> Thank you for all the feedback on this! The white background version has a definitive lead at the moment, but I will leave the discussion open over the weekend in case anyone else wants to chime in. 
>>> 
>>> @Sean Moony mentioned a preference for the triangle pattern on the yellow version since they aren?t overlapping. I?m curious if anyone else shares a preference for that triangle pattern button on the white background. 
>>> 
>>> Thank you again! 
>>> 
>>> -James 
>>> 
>>>> On Jan 26, 2022, at 3:44 PM, James Cole <james at openstack.org <mailto:james at openstack.org>> wrote:
>>>> 
>>>> Greetings everyone, 
>>>> 
>>>> I?m James, a designer with the OpenInfra Foundation. We have a been working on a new project mascot for Skyline and wanted to share a couple of options with you. 
>>>> 
>>>> The reference we were provided alluded to a nine-color-deer, so we created a deer illustration in the style of the other project mascots. The two options are essentially the same, but one is white with spots and the other is yellow with spots. Let me know if you like one or the other?or if we?re totally off on the theme?and we will add the text to the logo and finalize the assets.
>>>> 
>>>> There is a PDF attached to this message or you can view the document by visiting this link <https://www.dropbox.com/s/d2ikaphzhml7tqb/20220120%20Mascots%20Project.pdf?dl=0>. 
>>>> 
>>>> Thank you!
>>>> 
>>>> -James 
>>>> 
>>>> <20220120 Mascots Project.pdf>
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/6675333e/attachment-0001.htm>

From hjensas at redhat.com  Wed Feb  9 18:25:04 2022
From: hjensas at redhat.com (Harald Jensas)
Date: Wed, 9 Feb 2022 19:25:04 +0100
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
 <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
Message-ID: <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>

On 2/9/22 15:58, Lokendra Rathour wrote:
> Hi Harald,
> Responding on behalf of Anirudh's email:
> Thanks for the response and we now do understand that we are getting IP 
> from the expected DHCP server.
> 
> We tried the scenario and here are our findings, Our admin and internal 
> endpoints are on subnet: 30.30.30.x
> public : 10.0.1.x
> 
> (overcloud) [stack at undercloud ~]$ *OpenStack endpoint list | grep ironic*
> | 04c163251e5546769446a4fa4fa20484 | regionOne | ironic ? ? ? ? ? | 
> baremetal ? ? ? ? ? ? ? | True ? ?| admin ? ? | http://30.30.30.213:6385 
> <http://30.30.30.213:6385> ? ? ? ? ? ? ? ? ? ? ? |
> | 5c8557ae639a4898bdc6121f6e873724 | regionOne | ironic ? ? ? ? ? | 
> baremetal ? ? ? ? ? ? ? | True ? ?| internal ?| http://30.30.30.213:6385 
> <http://30.30.30.213:6385> ? ? ? ? ? ? ? ? ? ? ? |
> | 62e07a3b2f3f4158bb27d8603a8f5138 | regionOne | ironic-inspector | 
> baremetal-introspection | True ? ?| public ? ?| http://10.0.1.88:5050 
> <http://10.0.1.88:5050> ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | af29bd64513546409f44cc5d56ea1082 | regionOne | ironic-inspector | 
> baremetal-introspection | True ? ?| internal ?| http://30.30.30.213:5050 
> <http://30.30.30.213:5050> ? ? ? ? ? ? ? ? ? ? ? |
> | b76cdb5e77c54fc6b10cbfeada0e8bf5 | regionOne | ironic-inspector | 
> baremetal-introspection | True ? ?| admin ? ? | http://30.30.30.213:5050 
> <http://30.30.30.213:5050> ? ? ? ? ? ? ? ? ? ? ? |
> | bd2954f41e49419f85669990eb59f51a | regionOne | ironic ? ? ? ? ? | 
> baremetal ? ? ? ? ? ? ? | True ? ?| public ? ?| http://10.0.1.88:6385 
> <http://10.0.1.88:6385> ? ? ? ? ? ? ? ? ? ? ? ? ?|
> (overcloud) [stack at undercloud ~]$
> 
> 
> we are following the flat default n/w approach for ironic provisioning, 
> for which we are creating a flat network on baremetal physnet. we are 
> still getting IP from neutron range (172.23.3.220 - 172.23.3.240)? - 
> 172.23.3.240.
> 
> Further, we found that once IP (172.23.3.240) is allocated to baremetal 
> node, it looks for 30.30.30.220( IP of one of the three?controllers) for 
> pxe booting.
> Checking the same controllers logs we found that
> 
> *`/var/lib/ironic/tftpboot/pxelinux.cfg/` directory exists,* but then 
> there is *no file matching the mac *address of the baremetal node.
> 
> Also checking the *extra_dhcp_opts* we found this:
> (overcloud) [stack at undercloud ~]$ *openstack port show 
> d7e573bf-1028-437a-8118-a2074c7573b2 | grep "extra_dhcp_opts"*
> 
>     | extra_dhcp_opts ? ? ? ? | ip_version='4', opt_name='tag:ipxe,67',
>     opt_value='http://30.30.30.220:8088/boot.ipxe
>     <http://30.30.30.220:8088/boot.ipxe>' 
> 
> 
> image.png
> *Few points as observations:*
> 
>  1. Although the baremetal network (172.23.3.x) is routable to the admin
>     network (30.30.30.x), but it gets timeout at this?window.

It should be able to download the file over a routed network.

>  2. in TCPDump we are only getting read requests.

If you have access check the switches and routers if you can see the 
traffic being dropped/blocked somewhere on the path?


I'm not 100% sure what parameters you used when deploying, but did you 
try to change the ServiceNetMap for IronicApiNetwork, IronicNetwork?

If you set that to the name of the baremetal network (172.23.3.x)?

ServiceNetMap:
    IronicApiNetwork: baremetal_network
    IronicNetwork: baremetal_network

The result will be that the http server will listen on 172.23.3.x, and 
the extra_dhcp_opts should point to 172.23.3.x as well.


>  3. `openstack baremetal node list
>      1. (overcloud) [stack at undercloud ~]$ openstack baremetal node list
>         +--------------------------------------+------+---------------+-------------+--------------------+-------------+
>         | UUID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name | Instance UUID |
>         Power State | Provisioning State | Maintenance |
>         +--------------------------------------+------+---------------+-------------+--------------------+-------------+
>         | 7066fbe1-9c29-4702-9cd4-2b55daf19630 | bm1 ?| None ? ? ? ? ?|
>         power on ? ?| clean wait ? ? ? ? | False ? ? ? |
>         +--------------------------------------+------+---------------+-------------+--------------------+-------------+
>  4.  ?`openstack baremetal node show <node-uuid>`
>      1.
> 
>         (overcloud) [stack at undercloud ~]$ openstack baremetal node show bm1
>         +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>         | Field ? ? ? ? ? ? ? ? ?| Value                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>         | allocation_uuid ? ? ? ?| None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | automated_clean ? ? ? ?| None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | bios_interface ? ? ? ? | no-bios                              
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | boot_interface ? ? ? ? | ipxe                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | chassis_uuid ? ? ? ? ? | None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | clean_step ? ? ? ? ? ? | {}                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | conductor ? ? ? ? ? ? ?| overcloud-controller-0.localdomain  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | conductor_group ? ? ? ?|                                      
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | console_enabled ? ? ? ?| False                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | console_interface ? ? ?| ipmitool-socat                      
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | created_at ? ? ? ? ? ? | 2022-02-09T14:21:24+00:00            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | deploy_interface ? ? ? | iscsi                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | deploy_step ? ? ? ? ? ?| {}                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | description ? ? ? ? ? ?| None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | driver ? ? ? ? ? ? ? ? | ipmi                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | driver_info ? ? ? ? ? ?| {'ipmi_address': '10.0.1.183',
>         'ipmi_username': 'hsc', 'ipmi_password': '******',
>         'ipmi_terminal_port': 623, 'deploy_kernel':
>         '9e1365b6-261a-42a2-abfe-40158945de57', 'deploy_ramdisk':
>         'fe608dd2-ce86-4faf-b4b8-cc5cb143eb56'} ? ? ? ? ? ? ? ? ? ? ? ?|
>         | driver_internal_info ? | {'agent_erase_devices_iterations': 1,
>         'agent_erase_devices_zeroize': True,
>         'agent_continue_if_ata_erase_failed': False,
>         'agent_enable_ata_secure_erase': True,
>         'disk_erasure_concurrency': 1, 'last_power_state_change':
>         '2022-02-09T14:23:39.525629'} |
>         | extra ? ? ? ? ? ? ? ? ?| {}                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | fault ? ? ? ? ? ? ? ? ?| None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | inspect_interface ? ? ?| inspector                            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | inspection_finished_at | None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | inspection_started_at ?| None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | instance_info ? ? ? ? ?| {}                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | instance_uuid ? ? ? ? ?| None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | last_error ? ? ? ? ? ? | None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | maintenance ? ? ? ? ? ?| False                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | maintenance_reason ? ? | None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | management_interface ? | ipmitool                            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | name ? ? ? ? ? ? ? ? ? | bm1                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | network_interface ? ? ?| flat                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | owner ? ? ? ? ? ? ? ? ?| None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | power_interface ? ? ? ?| ipmitool                            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | power_state ? ? ? ? ? ?| power on                            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | properties ? ? ? ? ? ? | {'cpus': 20, 'cpu_arch': 'x86_64',
>         'capabilities': 'boot_option:local,boot_mode:uefi', 'memory_mb':
>         63700, 'local_gb': 470, 'vendor': 'hewlett-packard'}            
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | protected ? ? ? ? ? ? ?| False                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | protected_reason ? ? ? | None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | provision_state ? ? ? ?| clean wait                          
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | provision_updated_at ? | 2022-02-09T14:24:05+00:00            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | raid_config ? ? ? ? ? ?| {}                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | raid_interface ? ? ? ? | no-raid                              
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | rescue_interface ? ? ? | agent                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | reservation ? ? ? ? ? ?| None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | resource_class ? ? ? ? | bm1                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | storage_interface ? ? ?| noop                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | target_power_state ? ? | None                                
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | target_provision_state | available                            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | target_raid_config ? ? | {}                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | traits ? ? ? ? ? ? ? ? | []                                  
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | updated_at ? ? ? ? ? ? | 2022-02-09T14:24:05+00:00            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ?|
>         | uuid ? ? ? ? ? ? ? ? ? | 7066fbe1-9c29-4702-9cd4-2b55daf19630
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         | vendor_interface ? ? ? | ipmitool                            
>                                                                         
>                                                                         
>                                                                         
>          ? ? ? ? ? ? ? ? ? |
>         +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
>         (overcloud) [stack at undercloud ~]$
> 
> 
> 
> *Queries:*
> 
>   * What are the settings we can do for successfully pxe-boot of the
>     baremetal node and provisioning our node successfully ?
> 
> 
> 
> 
> 
> On Tue, Feb 8, 2022 at 6:27 PM Harald Jensas <hjensas at redhat.com 
> <mailto:hjensas at redhat.com>> wrote:
> 
>     On 2/7/22 13:47, Anirudh Gupta wrote:
>      > Hi?Julia,
>      >
>      > Thanks a lot for your responses and support.
>      > To Update on the ongoing issue, I tried deploying the overcloud with
>      > your valuable suggestions i.e by passing "*DhcpAgentNotification:
>     true*"
>      > in ironic-overcloud.yaml
>      > The setup came up successfully, but with this configuration the IP
>      > allocated on the system is one which is being configured while
>     creating
>      > the subnet in openstack.
>      >
>      > image.png
>      >
>      > The system is still getting the IP (172.23.3.212) from neutron. The
>      > subnet range was configured as *172.23.3.210-172.23.3.240 *while
>      > creating the provisioning subnet.
> 
> 
>     The node is supposed to get an IP address from the neutron subnet on
>     the
>     provisioning network when:
>     a) provisioning node
>     b) cleaning node.
> 
>     When you do "baremetal node provide" cleaning is most likely
>     automatically initiated. (Since cleaning is enabled by default for
>     Ironic in overcloud AFIK.)
> 
>     The only time you will get an address from the IronicInspectorSubnets
>     (ip_range: 172.23.3.100,172.23.3.150 in your case) is when you start
>     ironic node introspection.
> 
>      > The system gets stuck here and no action is performed after this.
>      >
> 
>     It seems the system is getting an address from the expected DHCP
>     server,
>     but it does not boot. I would start looking into the pxe properties in
>     the DHCP Reply.
> 
>     What is the status of the node in ironic at this stage?
>      ? `openstack baremetal node list`
>      ? `openstack baremetal node show <node-uuid>`
> 
>     Check the `extra_dhcp_opts` on the neutron port, it should set the
>     nextserver and bootfile parameters. Does the bootfile exist in
>     /var/lib/ironic/tftpboot? Inspect the
>     `/var/lib/ironic/tftpboot/pxelinux.cfg/` directory, you should see a
>     file matching the MAC address of your system. Does the content make
>     sense?
> 
>     Can you capture DHCP and TFTP traffic on the provisioning network?
> 
>      > Is there any way to resolve this and make successful 
>     provisioning the
>      > baremetal?node in *TripleO Train Release* (Since RHOSP 16 was on
>     Train,
>      > so I thought to go with that version for better stability)
>      >
>     https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
>     <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index>
> 
>      >
>     <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
>     <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index>>
>      >
>      > I have some queries:
>      >
>      >? 1. Is passing "*DhcpAgentNotification: true" *enough or do we
>     have to
>      >? ? ?make some other changes as well?
> 
>     I belive in train "DhcpAgentNotification" defaults to True.
>     The change to default to false was added more recently, and it was not
>     backported.
>     (https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761
>     <https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761>)
> 
>     NOTE, the environment for enabling ironi for the overcloud
>     'environments/services/ironic-overcloud.yaml' overrides this to 'true'
>     in later releases.
> 
>      >? 2. Although there are some security concerns specified in the
>     document,
>      >? ? ?but Currently I am focusing on the default flat bare
>     metal?approach
>      >? ? ?which has dedicated?interface for bare metal?Provisioning.
>     There is
>      >? ? ?one composable method approach as well. Keeping aside the
>     security
>      >? ? ?concerns, which approach is better and functional?
>      >? ? ? 1.
>     https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
>     <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning>
>      >       
>      ?<https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning>>
> 
>     Both should work, using the composable network is more secure since
>     baremetal nodes does not have access to the control plane network.
> 
>      >? 3. Will moving to upper openstack release version make this
>     deployment
>      >? ? ?possible?
>      >? ? ? 1. If Yes, which release should I go with as till wallaby the
>      >? ? ? ? ?ironic-overcloud.yml file has no option of including
>      >? ? ? ? ?"*DhcpAgentNotification: true*" by default
>      >? ? ? ? ? 1.
>     https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
>     <https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml>
>      >           
>      ?<https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml <https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml>>
>      >
>      >
>      > Looking forward for your valuable feedback/response.
>      >
>      > Regards
>      > Anirudh Gupta
>      >
>      >
>      > On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta <anyrude10 at gmail.com
>     <mailto:anyrude10 at gmail.com>
>      > <mailto:anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>>> wrote:
>      >
>      >? ? ?Hi,
>      >
>      >? ? ?Surely I'll revert the status once it gets deployed.
>      >? ? ?Bdw the suspicion is because of Train Release or it is
>     something else?
>      >
>      >? ? ?Regards
>      >? ? ?Anirudh Gupta
>      >
>      >? ? ?On Fri, 4 Feb, 2022, 20:29 Julia Kreger,
>      >? ? ?<juliaashleykreger at gmail.com
>     <mailto:juliaashleykreger at gmail.com>
>     <mailto:juliaashleykreger at gmail.com
>     <mailto:juliaashleykreger at gmail.com>>>
>      >? ? ?wrote:
>      >
>      >
>      >
>      >? ? ? ? ?On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta
>      >? ? ? ? ?<anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>
>     <mailto:anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>>> wrote:
>      >
>      >? ? ? ? ? ? ?Hi Julia
>      >
>      >? ? ? ? ? ? ?Thanks for your response.
>      >
>      >? ? ? ? ? ? ?Earlier I was passing both ironic.yaml and
>      >? ? ? ? ? ? ?ironic-overcloud.yaml located at path
>      >           
>      ?/usr/share/openstack-tripleo-heat-templates/environments/services/
>      >
>      >? ? ? ? ? ? ?My current understanding now says that since I am
>     using OVN,
>      >? ? ? ? ? ? ?not OVS so I should pass only ironic-overcloud.yaml in my
>      >? ? ? ? ? ? ?deployment.
>      >
>      >? ? ? ? ? ? ?I am currently on Train Release and my default
>      >? ? ? ? ? ? ?ironic-overcloud.yaml file has no such entry
>      >? ? ? ? ? ? ?DhcpAgentNotification: true
>      >
>      >
>      >? ? ? ? ?I suspect that should work. Let us know if it does.
>      >
>      >? ? ? ? ? ? ?I would add this there and re deploy the setup.
>      >
>      >? ? ? ? ? ? ?Would that be enough to make my deployment successful?
>      >
>      >? ? ? ? ? ? ?Regards
>      >? ? ? ? ? ? ?Anirudh Gupta
>      >
>      >
>      >? ? ? ? ? ? ?On Fri, 4 Feb, 2022, 18:40 Julia Kreger,
>      >? ? ? ? ? ? ?<juliaashleykreger at gmail.com
>     <mailto:juliaashleykreger at gmail.com>
>      >? ? ? ? ? ? ?<mailto:juliaashleykreger at gmail.com
>     <mailto:juliaashleykreger at gmail.com>>> wrote:
>      >
>      >? ? ? ? ? ? ? ? ?It is not a matter of disabling OVN, but a matter of
>      >? ? ? ? ? ? ? ? ?enabling the dnsmasq service and notifications.
>      >
>      >
>     https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
>     <https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml>
>      >               
>      ?<https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml <https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml>>
>      >? ? ? ? ? ? ? ? ?may provide some insight.
>      >
>      >? ? ? ? ? ? ? ? ?I suspect if you're using stable/wallaby based
>     branches
>      >? ? ? ? ? ? ? ? ?and it is not working, there may need to be a patch
>      >? ? ? ? ? ? ? ? ?backported by the TripleO maintainers.
>      >
>      >? ? ? ? ? ? ? ? ?On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta
>      >? ? ? ? ? ? ? ? ?<anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>
>     <mailto:anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>>> wrote:
>      >
>      >? ? ? ? ? ? ? ? ? ? ?Hi?Julia,
>      >
>      >? ? ? ? ? ? ? ? ? ? ?Thanks for your response.
>      >? ? ? ? ? ? ? ? ? ? ?For the overcloud deployment, I am executing the
>      >? ? ? ? ? ? ? ? ? ? ?following command:
>      >
>      >? ? ? ? ? ? ? ? ? ? ?openstack overcloud deploy --templates \
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -n /home/stack/templates/network_data.yaml \
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -r /home/stack/templates/roles_data.yaml \
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e /home/stack/templates/node-info.yaml \
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e /home/stack/templates/environment.yaml \
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>      >                   
>      ?/home/stack/templates/environments/network-isolation.yaml
>      >? ? ? ? ? ? ? ? ? ? ?\
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>      >                   
>      ?/home/stack/templates/environments/network-environment.yaml
>      >? ? ? ? ? ? ? ? ? ? ?\
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>      >                   
>      ?/usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
>      >? ? ? ? ? ? ? ? ? ? ?\
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>      >                   
>      ?/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>      >? ? ? ? ? ? ? ? ? ? ?\
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>      >                   
>      ?/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>      >? ? ? ? ? ? ? ? ? ? ?\
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>      >                   
>      ?/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>      >? ? ? ? ? ? ? ? ? ? ?\
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>     /home/stack/templates/ironic-config.yaml \
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>      >                   
>      ?/usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
>      >? ? ? ? ? ? ? ? ? ? ?\
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>      >                   
>      ?/usr/share/openstack-tripleo-heat-templates/environments/podman.yaml
>      >? ? ? ? ? ? ? ? ? ? ?\
>      >? ? ? ? ? ? ? ? ? ? ? ? ? -e
>     /home/stack/containers-prepare-parameter.yaml
>      >
>      >? ? ? ? ? ? ? ? ? ? ?I can see some OVN related stuff in my roles_data
>      >? ? ? ? ? ? ? ? ? ? ?and environments/network-isolation.yaml
>      >
>      >? ? ? ? ? ? ? ? ? ? ?[stack at undercloud ~]$ grep -inr "ovn"
>      >? ? ? ? ? ? ? ? ? ? ?roles_data.yaml:34: *OVNCMSOptions:
>      >? ? ? ? ? ? ? ? ? ? ?"enable-chassis-as-gw"*
>      >? ? ? ? ? ? ? ? ? ? ?roles_data.yaml:168: ? ?-
>      >? ? ? ? ? ? ? ? ? ? ?*OS::TripleO::Services::OVNDBs*
>      >? ? ? ? ? ? ? ? ? ? ?roles_data.yaml:169: ? ?-
>      >? ? ? ? ? ? ? ? ? ? ?*OS::TripleO::Services::OVNController*
>      >? ? ? ? ? ? ? ? ? ? ?roles_data.yaml:279: ? ?-
>      >? ? ? ? ? ? ? ? ? ? ?*OS::TripleO::Services::OVNController*
>      >? ? ? ? ? ? ? ? ? ? ?roles_data.yaml:280: ? ?-
>      >? ? ? ? ? ? ? ? ? ? ?*OS::TripleO::Services::OVNMetadataAgent*
>      >? ? ? ? ? ? ? ? ? ? ?environments/network-isolation.yaml:16:
>      >? ? ? ? ? ? ? ? ? ? ?*OS::TripleO::Network::Ports::OVNDBsVipPort:
>      >? ? ? ? ? ? ? ? ? ? ?../network/ports/vip.yaml*
>      >? ? ? ? ? ? ? ? ? ? ?*
>      >? ? ? ? ? ? ? ? ? ? ?*
>      >? ? ? ? ? ? ? ? ? ? ?What is your recommendation and how to disable
>      >? ? ? ? ? ? ? ? ? ? ?OVN....should I remove it from
>     roles_data.yaml and
>      >? ? ? ? ? ? ? ? ? ? ?then render so that it doesn't get generated
>      >? ? ? ? ? ? ? ? ? ? ?in?environments/network-isolation.yaml
>      >? ? ? ? ? ? ? ? ? ? ?Please suggest some pointers.
>      >
>      >? ? ? ? ? ? ? ? ? ? ?Regards
>      >? ? ? ? ? ? ? ? ? ? ?Anirudh Gupta
>      >? ? ? ? ? ? ? ? ? ? ?*
>      >? ? ? ? ? ? ? ? ? ? ?*
>      >? ? ? ? ? ? ? ? ? ? ?*
>      >? ? ? ? ? ? ? ? ? ? ?*
>      >
>      >
>      >
>      >
>      >? ? ? ? ? ? ? ? ? ? ?It seems OVN is getting installed in ironic
>      >
>      >
>      >? ? ? ? ? ? ? ? ? ? ?On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger
>      >? ? ? ? ? ? ? ? ? ? ?<juliaashleykreger at gmail.com
>     <mailto:juliaashleykreger at gmail.com>
>      >? ? ? ? ? ? ? ? ? ? ?<mailto:juliaashleykreger at gmail.com
>     <mailto:juliaashleykreger at gmail.com>>> wrote:
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ?My guess: You're running OVN. You need
>      >? ? ? ? ? ? ? ? ? ? ? ? ?neutron-dhcp-agent running as well. OVN
>     disables
>      >? ? ? ? ? ? ? ? ? ? ? ? ?it by default and OVN's?integrated DHCP
>     service
>      >? ? ? ? ? ? ? ? ? ? ? ? ?does not support options for network booting.
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ?-Julia
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ?On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta
>      >? ? ? ? ? ? ? ? ? ? ? ? ?<anyrude10 at gmail.com
>     <mailto:anyrude10 at gmail.com>
>      >? ? ? ? ? ? ? ? ? ? ? ? ?<mailto:anyrude10 at gmail.com
>     <mailto:anyrude10 at gmail.com>>> wrote:
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Hi Team
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?I am trying to Provision Bare Metal Node
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?from my tripleo Overcloud.
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?For this, while deploying the
>     overcloud, I
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?have followed the *"default flat"
>     *network
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?approach specified in the below link
>      >
>     https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
>     <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning>
>      >                           
>      ?<https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning>>
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Just to highlight the changes, I have
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?defined the
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*ironic-config.yaml*
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?parameter_defaults:
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ...
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ...
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? IronicIPXEEnabled: true
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? IronicInspectorSubnets:
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? - ip_range:
>     *172.23.3.100,172.23.3.150*
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? IronicInspectorInterface:
>     'br-baremetal'
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Also modified the file
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*~/templates/network-environment.yaml*
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?parameter_defaults:
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? NeutronBridgeMappings:
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?datacentre:br-ex,baremetal:br-baremetal
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? NeutronFlatNetworks:
>     datacentre,baremetal
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?With this I have Followed all the
>     steps of
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?creating br-baremetal bridge on
>     controller,
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?given in the link below:
>      >
>      >
>     https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
>     <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy>
>      >                           
>      ?<https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy>>
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? - type: ovs_bridge
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?name: br-baremetal
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?use_dhcp: false
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?members:
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?- type: interface
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?name: nic3
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Post Deployment, I have also?create a
>     flat
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?network on "datacentre"
>     physical?network and
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?subnet having the range
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*172.23.3.200,172.23.3.240 *(as suggested
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?subnet is same as of inspector and
>     range is
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?different) and the router
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Also created a baremetal?node and ran
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*"openstack baremetal node manage
>     bm1", *the
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?state of which was a success.
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Observation:
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?On executing "openstack baremetal node
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*provide* bm1", the machine gets power on
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and ideally it should take an IP from
>     ironic
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?inspector range and PXE Boot.
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?But nothing of this sort happens and
>     we see
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?an IP from neutron range "*172.23.3.239*"
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(attached the screenshot)
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?image.png
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?I have checked overcloud ironic inspector
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?podman logs alongwith the tcpdump.
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?In tcpdump, I can only see dhcp discover
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?request on br-baremetal and nothing
>     happens
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?after that.
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?I have tried to explain my issue in
>     detail,
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?but I would be happy to share more
>     details
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?in case still required.
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Can someone please help in resolving
>     my issue.
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Regards
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Anirudh Gupta
>      >
> 
> 
> 
> 



From jungleboyj at gmail.com  Wed Feb  9 19:00:11 2022
From: jungleboyj at gmail.com (Jay Bryant)
Date: Wed, 9 Feb 2022 13:00:11 -0600
Subject: [election][tc] Non-candidacy
In-Reply-To: <CAPkQhneUECHGXvr8hsgO=kE=pOqwihtPUq9H+1RoYJePDVAB-A@mail.gmail.com>
References: <CAPkQhneUECHGXvr8hsgO=kE=pOqwihtPUq9H+1RoYJePDVAB-A@mail.gmail.com>
Message-ID: <23f31830-3e65-2ed1-7db4-2474838e9139@gmail.com>

Belmiro,

It has been great to work with you on the TC.? Thank you for all you 
have done for the group!

Jay

On 2/9/2022 10:34 AM, Belmiro Moreira wrote:
> Dear all,
> I would like to let you know that I won't run for the Technical 
> Committee (TC).
>
> After 2 years in this role I believe that it?s time for some rotation.
> It was a pleasure to work with all of you. Thank you for this amazing 
> experience.
>
> cheers,
> Belmiro


From artem.goncharov at gmail.com  Wed Feb  9 19:32:47 2022
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Wed, 9 Feb 2022 20:32:47 +0100
Subject: [openstacksdk] create object (eg. snapshot) on behalf of user as
 admin
In-Reply-To: <67a46fab-a685-d591-1122-05296d2ecd79@cirrax.com>
References: <67a46fab-a685-d591-1122-05296d2ecd79@cirrax.com>
Message-ID: <CAMdUkEanHSfc8S4ZrsZvAMhspR3Lw211ud=iGVLPRUJmxCgfqQ@mail.gmail.com>

Please provide details whether you mean overall OpenStack admin user or
your domain admin user. I assume it would be necessary to connect as
destination project, but here exactly it is necessary to do this carefully.
You may also share you clouds.yaml (of course without passwords), this will
help to eventually notice the problem.

Also important to know whether you initially connect as admin in the same
domain or user project belongs to other domain.

Artem

----
typed from mobile, auto-correct typos assumed
----

On Wed, Feb 9, 2022, 15:49 Benedikt Trefzer <benedikt.trefzer at cirrax.com>
wrote:

>
> Hi list
>
> I like to connect as an amin user to an openstack cloud and create a
> snapshot of a volume in the same project as the volume exists.
>
> I use the openstacksdk to achive this in python.
> So far I can connect as admin and create the snapshot but the
> snapshot is in the admins project, not in the project of the volume.
>
> Code so far:
>
> from openstack import connect
> import openstack.config
>
> conn=connect()
>
> conn.volume.create_snapshot(name='test', description='testing',
> volume='volumeIDinANYproject')
>
> I tried to use
> conn.connect_as_project('ProjectID')
>
> but was not successfull.
>
> Please direct me in the correct direction to achive this ! Any help
> appreciated.
>
> Greeting
>
> Benedikt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/6226dfc4/attachment.htm>

From benedikt.trefzer at cirrax.com  Wed Feb  9 21:30:34 2022
From: benedikt.trefzer at cirrax.com (Benedikt Trefzer)
Date: Wed, 9 Feb 2022 22:30:34 +0100
Subject: [openstacksdk] create object (eg. snapshot) on behalf of user as
 admin
In-Reply-To: <CAMdUkEanHSfc8S4ZrsZvAMhspR3Lw211ud=iGVLPRUJmxCgfqQ@mail.gmail.com>
References: <67a46fab-a685-d591-1122-05296d2ecd79@cirrax.com>
 <CAMdUkEanHSfc8S4ZrsZvAMhspR3Lw211ud=iGVLPRUJmxCgfqQ@mail.gmail.com>
Message-ID: <0a9c47bc-ffa3-82f0-d650-3e301d9b28c7@cirrax.com>

I still have only the default domain so admin is in same domain as the 
project. The admin user is the main admin (it has the admin role). The 
configuration is loaded through environment variables, so no cloud.yaml 
file.

Yes I think I have to somehow connect to the destination project but 
with the credentials of the admin (which is only member of another 
project).
I assumed connect_as_project is the solution, but this is not working as 
expected (actually I do not understand what it is for ! or what 
configuration it expects to work (does it expect to have a member role 
in the destination project ?).

I just tried to get a token as admin and use it for authorization in the 
customers project. But no success yet.

Another approach I did not yet try is use a trust (but, if I understand 
correctly, I have to establish the trust as user of destination project 
first)

Well and the last thing would be to add the admin user as project member 
and remove it after work is done. But I like to avoid that solution.

Benedikt



On 09.02.22 20:32, Artem Goncharov wrote:
> Please provide details whether you mean overall OpenStack admin user or 
> your domain admin user. I assume it would be necessary to connect as 
> destination project, but here exactly it is necessary to do this 
> carefully. You may also share you clouds.yaml (of course without 
> passwords), this will help to eventually notice the problem.
> 
> Also important to know whether you initially connect as admin in the 
> same domain or user project belongs to other domain.
> 
> Artem
> 
> ----
> typed from mobile, auto-correct typos assumed
> ----
> 
> On Wed, Feb 9, 2022, 15:49 Benedikt Trefzer <benedikt.trefzer at cirrax.com 
> <mailto:benedikt.trefzer at cirrax.com>> wrote:
> 
> 
>     Hi list
> 
>     I like to connect as an amin user to an openstack cloud and create a
>     snapshot of a volume in the same project as the volume exists.
> 
>     I use the openstacksdk to achive this in python.
>     So far I can connect as admin and create the snapshot but the
>     snapshot is in the admins project, not in the project of the volume.
> 
>     Code so far:
> 
>     from openstack import connect
>     import openstack.config
> 
>     conn=connect()
> 
>     conn.volume.create_snapshot(name='test', description='testing',
>     volume='volumeIDinANYproject')
> 
>     I tried to use
>     conn.connect_as_project('ProjectID')
> 
>     but was not successfull.
> 
>     Please direct me in the correct direction to achive this ! Any help
>     appreciated.
> 
>     Greeting
> 
>     Benedikt
> 


From amy at demarco.com  Wed Feb  9 22:37:31 2022
From: amy at demarco.com (Amy Marrich)
Date: Wed, 9 Feb 2022 16:37:31 -0600
Subject: [election][tc] Non-candidacy
In-Reply-To: <CAPkQhneUECHGXvr8hsgO=kE=pOqwihtPUq9H+1RoYJePDVAB-A@mail.gmail.com>
References: <CAPkQhneUECHGXvr8hsgO=kE=pOqwihtPUq9H+1RoYJePDVAB-A@mail.gmail.com>
Message-ID: <CAFs83QrNnVaWka=fc6+F2Uwqu4B7FH_SgfWNpxMv+47iUoc1eQ@mail.gmail.com>

Belmiro,

Thanks for all your hard work on the TC and the UC before that!

Amy (spotz)

On Wed, Feb 9, 2022 at 10:38 AM Belmiro Moreira <
moreira.belmiro.email.lists at gmail.com> wrote:

> Dear all,
> I would like to let you know that I won't run for the Technical Committee
> (TC).
>
> After 2 years in this role I believe that it?s time for some rotation.
> It was a pleasure to work with all of you. Thank you for this amazing
> experience.
>
> cheers,
> Belmiro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220209/18dd4f0d/attachment.htm>

From mkopec at redhat.com  Wed Feb  9 23:46:31 2022
From: mkopec at redhat.com (Martin Kopec)
Date: Thu, 10 Feb 2022 00:46:31 +0100
Subject: [qa][devstack] Proposing Dan Smith to devstack core
Message-ID: <CAKZGdE0aw9AGu6eB1d8To9QcTse01nGv8W-JMH7zUbEu9RtVvw@mail.gmail.com>

Hi all,

we would like to propose Dan Smith (IRC: dansmith) to devstack core.

Dan is an experienced contributor who has been contributing to several
openstack projects. We are glad Dan volunteered to help us in the Devstack
project as well.

You can vote/feedback in this email thread. If no objection by 17th of
February, we will add Dan
to the core list.

Thanks,
-- 
Martin Kopec
Senior Software Quality Engineer
Red Hat EMEA
IM: kopecmartin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/1944ba81/attachment.htm>

From gmann at ghanshyammann.com  Thu Feb 10 00:57:23 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Feb 2022 18:57:23 -0600
Subject: [qa][devstack] Proposing Dan Smith to devstack core
In-Reply-To: <CAKZGdE0aw9AGu6eB1d8To9QcTse01nGv8W-JMH7zUbEu9RtVvw@mail.gmail.com>
References: <CAKZGdE0aw9AGu6eB1d8To9QcTse01nGv8W-JMH7zUbEu9RtVvw@mail.gmail.com>
Message-ID: <17ee122855b.ca10488e79864.8737427503451386666@ghanshyammann.com>

 ---- On Wed, 09 Feb 2022 17:46:31 -0600 Martin Kopec <mkopec at redhat.com> wrote ----
 > Hi all,
 > we would like to propose Dan Smith (IRC: dansmith) to devstack core.
 > 
 > Dan is an experienced contributor who has been contributing to several openstack projects. We are glad Dan volunteered to help us in the Devstack project as well.
 > You can vote/feedback in this email thread. If no objection by 17th of February, we will add Dan
 > to the core list.

+1, Dan addition to the core will be helpful for sure.

-gmann

 > Thanks,
 > -- 
 > Martin Kopec
 > Senior Software Quality Engineer
 > Red Hat EMEAIM: kopecmartin
 > 
 >                               


From satish.txt at gmail.com  Thu Feb 10 01:07:52 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 9 Feb 2022 20:07:52 -0500
Subject: nova rabbitmq strange bug
Message-ID: <CAPgF-fqsVbOT0Rdpd725-DKL+LMPmMQZ2fe4RbDkGzOXu6_uyA@mail.gmail.com>

Folks,

I am running wallaby and Today i had rabbitMQ issue and i rebuild
RabbitMQ. but now my all compute node throwing following error. not
sure what is going on up they are not trying to come up and keep
crashing with following error


2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
[req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b - - - - -] Error starting
thread.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting
for a reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
Traceback (most recent call last):

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
line 433, in get

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
return self._queues[msg_id].get(block=True, timeout=timeout)

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
line 322, in get

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
return waiter.wait()

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
line 141, in wait

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
return get_hub().switch()

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/hubs/hub.py",
line 313, in switch

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
return self.greenlet.switch()

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
_queue.Empty

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service During
handling of the above exception, another exception occurred:

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
Traceback (most recent call last):

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_service/service.py",
line 807, in run_service

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
service.start()

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/service.py",
line 159, in start

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
self.manager.init_host()

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/compute/manager.py",
line 1413, in init_host

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
self.driver.init_host(host=self.host)

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
line 792, in init_host

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
self._register_instance_machine_type()

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
line 811, in _register_instance_machine_type

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service     for
instance in objects.InstanceList.get_by_host(context, hostname):

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_versionedobjects/base.py",
line 175, in wrapper

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
result = cls.indirection_api.object_class_action_versions(

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/conductor/rpcapi.py",
line 240, in object_class_action_versions

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
return cctxt.call(context, 'object_class_action_versions',

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/rpc/client.py",
line 175, in call

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
self.transport._send(self.target, msg_ctxt, msg,

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/transport.py",
line 123, in _send

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
return self._driver.send(target, ctxt, message,

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
line 680, in send

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
return self._send(target, ctxt, message, wait_for_reply, timeout,

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
line 669, in _send

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
result = self._waiter.wait(msg_id, timeout,

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
line 559, in wait

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
message = self.waiters.get(msg_id, timeout=timeout)

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
"/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
line 435, in get

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
raise oslo_messaging.MessagingTimeout(

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a
reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8

   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service


From gmann at ghanshyammann.com  Thu Feb 10 01:34:25 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Feb 2022 19:34:25 -0600
Subject: [all][tc] Technical Committee next weekly meeting on Feb 10th
 at 1500 UTC
In-Reply-To: <17ed6460183.11c21ffe984234.3082030242553298999@ghanshyammann.com>
References: <17ed6460183.11c21ffe984234.3082030242553298999@ghanshyammann.com>
Message-ID: <17ee1447096.11ff1456480133.8899857554657931234@ghanshyammann.com>

Hello Everyone,

Below is the agenda for Tomorrow's TC IRC meeting schedule at 1500 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

== Agenda for tomorrow's TC meeting ==

* Roll call

* Follow up on past action items

* Gate health check
** Fixing Zuul config error in OpenStack
*** https://etherpad.opendev.org/p/zuul-config-error-openstack

* Z Release Cycle Name
** Election results: https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f
** Next step, the foundation has started the trademark checks.

* Z cycle Technical Elections
** Nominations currently running.
** https://review.opendev.org/c/openstack/election/+/825017

*Dropping tags framework - next steps (yoctozepto)

* Open Reviews
** https://review.opendev.org/q/projects:openstack/governance+is:open


-gmann

 ---- On Mon, 07 Feb 2022 16:20:19 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Hello Everyone,
 > 
 > Technical Committee's next weekly meeting is scheduled for Feb 10th at 1500 UTC.
 > 
 > If you would like to add topics for discussion, please add them to the below wiki page by
 > Wednesday, Feb 9th, at 2100 UTC.
 > 
 > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
 > 
 > -gmann
 > 
 > 
 > 


From hanguangyu2 at gmail.com  Thu Feb 10 01:50:03 2022
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Thu, 10 Feb 2022 09:50:03 +0800
Subject: [Ironic] No suitable device was found for deployment
Message-ID: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>

Dear all,

I have a OpenStack Victoria environment, and tried to use ironic
manage bare metal. But I got "- root device hints were not provided
and all found block devices are smaller than 4294967296B." in deploy
stage.

2022-02-09 17:57:56.492 3908982 ERROR
ironic.drivers.modules.agent_base [-] Agent returned error for deploy
step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
No suitable device was found for deployment - root device hints were
not provided and all found block devices are smaller than
4294967296B..

I used "openstack server create --flavor my-baremetal-flavor --nic
net-id=$net_id --image $image testing" to deploy bare metal node.  I
download deploy images(ipa-centos8-master.kernel and
ipa-centos8-master.initramfs) in
https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.

The baremetal node info and flavor info as following:
https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
Ironic configure file as following:
https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
The log of ironic-python-agent in bare metal node:
https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/

I see some old discussion about this, such as:
https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
discussions took place a long time ago, not version V, and no solution
was seen.

Does anyone know how to solve this problem? I would appreciate any
kind of guidance or help.

Thank you,
Han Guangyu


From gouthampravi at gmail.com  Thu Feb 10 03:47:22 2022
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Wed, 9 Feb 2022 19:47:22 -0800
Subject: [manila][cinder][glance][nova][devstack][qa] Add fmount to
 devstack-plugin-ceph core
Message-ID: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>

Hello,

As you're aware, we're looking to adopt cephadm within
devstack-plugin-ceph to align with the ceph community's
recommendations on day0-day2 handling of ceph [1] in devstack.

Francesco Pantano has worked a ton on the integration of ceph with
tripleo. He has been our go-to person for deploying and using the new
nfs daemon with manila. In light of this, to make reviews more
productive, I would like to propose fpantano at redhat.com (fmount on
launchpad and oftc) to the devstack-plugin-ceph-core group [2]. He's
aware of our review policies, and will take care not to break existing
testing. Any objections?

Thank you,
Goutham Pacha Ravi


[1]  http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026778.html
[2] https://review.opendev.org/admin/groups/8e51d8f39e33d932a40f03060b861db57a3d25d4,members


From radoslaw.piliszek at gmail.com  Thu Feb 10 07:00:54 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Thu, 10 Feb 2022 08:00:54 +0100
Subject: [qa][devstack] Proposing Dan Smith to devstack core
In-Reply-To: <17ee122855b.ca10488e79864.8737427503451386666@ghanshyammann.com>
References: <CAKZGdE0aw9AGu6eB1d8To9QcTse01nGv8W-JMH7zUbEu9RtVvw@mail.gmail.com>
 <17ee122855b.ca10488e79864.8737427503451386666@ghanshyammann.com>
Message-ID: <CAKZ_x78FXEFLZqeR7==az-hJzJgTf=ed_wHU==+EmBCCHkAoaw@mail.gmail.com>

+1

On Thu, Feb 10, 2022, 01:58 Ghanshyam Mann <gmann at ghanshyammann.com> wrote:

>  ---- On Wed, 09 Feb 2022 17:46:31 -0600 Martin Kopec <mkopec at redhat.com>
> wrote ----
>  > Hi all,
>  > we would like to propose Dan Smith (IRC: dansmith) to devstack core.
>  >
>  > Dan is an experienced contributor who has been contributing to several
> openstack projects. We are glad Dan volunteered to help us in the Devstack
> project as well.
>  > You can vote/feedback in this email thread. If no objection by 17th of
> February, we will add Dan
>  > to the core list.
>
> +1, Dan addition to the core will be helpful for sure.
>
> -gmann
>
>  > Thanks,
>  > --
>  > Martin Kopec
>  > Senior Software Quality Engineer
>  > Red Hat EMEAIM: kopecmartin
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/5786b7a6/attachment.htm>

From arne.wiebalck at cern.ch  Thu Feb 10 07:51:10 2022
From: arne.wiebalck at cern.ch (Arne Wiebalck)
Date: Thu, 10 Feb 2022 08:51:10 +0100
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
Message-ID: <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>

Hi Guangyu,

The error indicates that Ironic was not able to find
a device where it could deploy the image to.

To find a device, Ironic will use 'root device'
hints [1], usually set by the admin on a node. If that
does not yield anything, Ironic will loop over all
block devices and pick the smallest which is larger
than 4GB (and order them alphabetically).

If you have disks in your server which are larger than
4GB, one potential explanation is that Ironic cannot see them,
e.g. since the corresponding drivers in the IPA image are missing.
The logs you posted seem to confirm something along those
lines.

Check the content of the 'lsblk' file in the deploy logs which
you can find in the tar archive in /var/log/ironic/deploy/
on the controller for your deployment attempt to see what
devices Ironic has access to.

Cheers,
  Arne


[1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints

On 10.02.22 02:50, ??? wrote:
> Dear all,
>
> I have a OpenStack Victoria environment, and tried to use ironic
> manage bare metal. But I got "- root device hints were not provided
> and all found block devices are smaller than 4294967296B." in deploy
> stage.
>
> 2022-02-09 17:57:56.492 3908982 ERROR
> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
> No suitable device was found for deployment - root device hints were
> not provided and all found block devices are smaller than
> 4294967296B..
>
> I used "openstack server create --flavor my-baremetal-flavor --nic
> net-id=$net_id --image $image testing" to deploy bare metal node.  I
> download deploy images(ipa-centos8-master.kernel and
> ipa-centos8-master.initramfs) in
> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
>
> The baremetal node info and flavor info as following:
> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
> Ironic configure file as following:
> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
> The log of ironic-python-agent in bare metal node:
> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
>
> I see some old discussion about this, such as:
> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
> discussions took place a long time ago, not version V, and no solution
> was seen.
>
> Does anyone know how to solve this problem? I would appreciate any
> kind of guidance or help.
>
> Thank you,
> Han Guangyu
>


From hanguangyu2 at gmail.com  Thu Feb 10 10:15:37 2022
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Thu, 10 Feb 2022 18:15:37 +0800
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
Message-ID: <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>

Hi Arne,

Thank you very much for your response. Love you. You take away a lot
of my confusion.

You are right, I didn't set 'root device'. And Ironic also can not see
disk, the content of the 'lsblk' file in the deploy los is emply.
I tried to set 'root device', but because ironic can't find any disk,
the deploy still filed.

Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
inaccessible, /dev/disk/by-path/* version of block device name is
unavailable Cause: [Errno 2] No such file or directory:
'/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
directory: '/dev/disk/by-path'
Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
matches the root device hints {'wwn': '0x50014EE2691D724C'}:
StopIteration

Sorry to bother you, I'm a newcomer of Ironic and I didn't find
information about it on google.

The bare metal node have three same disk(Western Digital DC HA210 2TB
SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
this disk?

And If Ironic cannot find disk since the corresponding drivers in the
IPA image are missing, do you know how to resolve it? I have used the
latest deploy images in
https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
.  Do I need to find and manually add driver in the source code or
ramdisk(That was difficult tome)?

Love you.

Cheers,
Guangyu

Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
>
> Hi Guangyu,
>
> The error indicates that Ironic was not able to find
> a device where it could deploy the image to.
>
> To find a device, Ironic will use 'root device'
> hints [1], usually set by the admin on a node. If that
> does not yield anything, Ironic will loop over all
> block devices and pick the smallest which is larger
> than 4GB (and order them alphabetically).
>
> If you have disks in your server which are larger than
> 4GB, one potential explanation is that Ironic cannot see them,
> e.g. since the corresponding drivers in the IPA image are missing.
> The logs you posted seem to confirm something along those
> lines.
>
> Check the content of the 'lsblk' file in the deploy logs which
> you can find in the tar archive in /var/log/ironic/deploy/
> on the controller for your deployment attempt to see what
> devices Ironic has access to.
>
> Cheers,
>   Arne
>
>
> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
>
> On 10.02.22 02:50, ??? wrote:
> > Dear all,
> >
> > I have a OpenStack Victoria environment, and tried to use ironic
> > manage bare metal. But I got "- root device hints were not provided
> > and all found block devices are smaller than 4294967296B." in deploy
> > stage.
> >
> > 2022-02-09 17:57:56.492 3908982 ERROR
> > ironic.drivers.modules.agent_base [-] Agent returned error for deploy
> > step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
> > 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
> > No suitable device was found for deployment - root device hints were
> > not provided and all found block devices are smaller than
> > 4294967296B..
> >
> > I used "openstack server create --flavor my-baremetal-flavor --nic
> > net-id=$net_id --image $image testing" to deploy bare metal node.  I
> > download deploy images(ipa-centos8-master.kernel and
> > ipa-centos8-master.initramfs) in
> > https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
> >
> > The baremetal node info and flavor info as following:
> > https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
> > Ironic configure file as following:
> > https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
> > Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
> > The log of ironic-python-agent in bare metal node:
> > https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
> >
> > I see some old discussion about this, such as:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
> > discussions took place a long time ago, not version V, and no solution
> > was seen.
> >
> > Does anyone know how to solve this problem? I would appreciate any
> > kind of guidance or help.
> >
> > Thank you,
> > Han Guangyu
> >


From tpb at dyncloud.net  Thu Feb 10 10:16:32 2022
From: tpb at dyncloud.net (Tom Barron)
Date: Thu, 10 Feb 2022 05:16:32 -0500
Subject: [manila][cinder][glance][nova][devstack][qa] Add fmount to
 devstack-plugin-ceph core
In-Reply-To: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>
References: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>
Message-ID: <20220210101632.a4427w6x4gq3jq5l@barron.net>

On 09/02/22 19:47 -0800, Goutham Pacha Ravi wrote:
>Hello,
>
>As you're aware, we're looking to adopt cephadm within
>devstack-plugin-ceph to align with the ceph community's
>recommendations on day0-day2 handling of ceph [1] in devstack.
>
>Francesco Pantano has worked a ton on the integration of ceph with
>tripleo. He has been our go-to person for deploying and using the new
>nfs daemon with manila. In light of this, to make reviews more
>productive, I would like to propose fpantano at redhat.com (fmount on
>launchpad and oftc) to the devstack-plugin-ceph-core group [2]. He's
>aware of our review policies, and will take care not to break existing
>testing. Any objections?
>
>Thank you,
>Goutham Pacha Ravi
>
>
>[1]  http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026778.html
>[2] https://review.opendev.org/admin/groups/8e51d8f39e33d932a40f03060b861db57a3d25d4,members
>

What a great idea!  +1000 from me.

-- Tom



From arne.wiebalck at cern.ch  Thu Feb 10 11:13:11 2022
From: arne.wiebalck at cern.ch (Arne Wiebalck)
Date: Thu, 10 Feb 2022 12:13:11 +0100
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
Message-ID: <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>

Hi Guangyu,

No worries about asking questions, this is what the mailing
list is for :)

Just to clarify, you do not have to set root device hints,
it also works without (with the algorithm I mentioned).
However, hints help to define the exact device and/or make
deployment more predictable/repeatable.

If it is really a driver problem, it is an issue with the
operating system of the image you use, i.e. CentOS8. Some
drivers were removed from 7 to 8, and we have seen issues
with specific drive models as well.

You can try to build your own IPA images as described in
[1], e.g. to add your ssh key to be able to log into the
IPA to debug further, and to eventually include drivers
(if you can identify them and they are available for CentOS8).

Another option may be to add another (newer) disk model to
the server, just to confirm it is the disk model/driver which
is the cause.

You could also try to boot the node into a CentOS7 (and then
a CentOS8) live image to confirm it can see the disks at all.

Hope this helps!
  Arne

[1] 
https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html


On 10.02.22 11:15, ??? wrote:
> Hi Arne,
> 
> Thank you very much for your response. Love you. You take away a lot
> of my confusion.
> 
> You are right, I didn't set 'root device'. And Ironic also can not see
> disk, the content of the 'lsblk' file in the deploy los is emply.
> I tried to set 'root device', but because ironic can't find any disk,
> the deploy still filed.
> 
> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
> inaccessible, /dev/disk/by-path/* version of block device name is
> unavailable Cause: [Errno 2] No such file or directory:
> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> directory: '/dev/disk/by-path'
> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
> matches the root device hints {'wwn': '0x50014EE2691D724C'}:
> StopIteration
> 
> Sorry to bother you, I'm a newcomer of Ironic and I didn't find
> information about it on google.
> 
> The bare metal node have three same disk(Western Digital DC HA210 2TB
> SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
> this disk?
> 
> And If Ironic cannot find disk since the corresponding drivers in the
> IPA image are missing, do you know how to resolve it? I have used the
> latest deploy images in
> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
> .  Do I need to find and manually add driver in the source code or
> ramdisk(That was difficult tome)?
> 
> Love you.
> 
> Cheers,
> Guangyu
> 
> Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
>>
>> Hi Guangyu,
>>
>> The error indicates that Ironic was not able to find
>> a device where it could deploy the image to.
>>
>> To find a device, Ironic will use 'root device'
>> hints [1], usually set by the admin on a node. If that
>> does not yield anything, Ironic will loop over all
>> block devices and pick the smallest which is larger
>> than 4GB (and order them alphabetically).
>>
>> If you have disks in your server which are larger than
>> 4GB, one potential explanation is that Ironic cannot see them,
>> e.g. since the corresponding drivers in the IPA image are missing.
>> The logs you posted seem to confirm something along those
>> lines.
>>
>> Check the content of the 'lsblk' file in the deploy logs which
>> you can find in the tar archive in /var/log/ironic/deploy/
>> on the controller for your deployment attempt to see what
>> devices Ironic has access to.
>>
>> Cheers,
>>    Arne
>>
>>
>> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
>>
>> On 10.02.22 02:50, ??? wrote:
>>> Dear all,
>>>
>>> I have a OpenStack Victoria environment, and tried to use ironic
>>> manage bare metal. But I got "- root device hints were not provided
>>> and all found block devices are smaller than 4294967296B." in deploy
>>> stage.
>>>
>>> 2022-02-09 17:57:56.492 3908982 ERROR
>>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
>>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
>>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
>>> No suitable device was found for deployment - root device hints were
>>> not provided and all found block devices are smaller than
>>> 4294967296B..
>>>
>>> I used "openstack server create --flavor my-baremetal-flavor --nic
>>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
>>> download deploy images(ipa-centos8-master.kernel and
>>> ipa-centos8-master.initramfs) in
>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
>>>
>>> The baremetal node info and flavor info as following:
>>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
>>> Ironic configure file as following:
>>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
>>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
>>> The log of ironic-python-agent in bare metal node:
>>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
>>>
>>> I see some old discussion about this, such as:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
>>> discussions took place a long time ago, not version V, and no solution
>>> was seen.
>>>
>>> Does anyone know how to solve this problem? I would appreciate any
>>> kind of guidance or help.
>>>
>>> Thank you,
>>> Han Guangyu
>>>


From rosmaita.fossdev at gmail.com  Thu Feb 10 13:40:42 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 10 Feb 2022 08:40:42 -0500
Subject: [manila][cinder][glance][nova][devstack][qa] Add fmount to
 devstack-plugin-ceph core
In-Reply-To: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>
References: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>
Message-ID: <39364541-3684-1302-3ef3-10ffac2e886a@gmail.com>

On 2/9/22 10:47 PM, Goutham Pacha Ravi wrote:
> Hello,
> 
> As you're aware, we're looking to adopt cephadm within
> devstack-plugin-ceph to align with the ceph community's
> recommendations on day0-day2 handling of ceph [1] in devstack.
> 
> Francesco Pantano has worked a ton on the integration of ceph with
> tripleo. He has been our go-to person for deploying and using the new
> nfs daemon with manila. In light of this, to make reviews more
> productive, I would like to propose fpantano at redhat.com (fmount on
> launchpad and oftc) to the devstack-plugin-ceph-core group [2]. He's
> aware of our review policies, and will take care not to break existing
> testing. Any objections?

No objections from me.  Adding Francesco is a good idea.

> Thank you,
> Goutham Pacha Ravi
> 
> 
> [1]  http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026778.html
> [2] https://review.opendev.org/admin/groups/8e51d8f39e33d932a40f03060b861db57a3d25d4,members
> 



From jfrancoa at redhat.com  Thu Feb 10 14:35:20 2022
From: jfrancoa at redhat.com (Jose Luis Franco Arza)
Date: Thu, 10 Feb 2022 15:35:20 +0100
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
Message-ID: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>

Hello folks,

I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer on
the TripleO repositories related to the upgrades workflow
(openstack/tripleo-heat-templates, openstack/tripleo-ansible,
openstack/python-tripleoclient, openstack/tripleo-ci,
openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii
has been working in OpenStack for the last 10 years, he is already
core-reviewer of the tripleo-upgrade
<https://github.com/openstack/tripleo-upgrade>repository in which he is
providing with very valuable feedback, as well as helping getting relevant
patches merged.

His deep knowledge of the different OpenStack projects, as well as his
involvement in the upgrades/updates workflows for the last 9 OpenStack
releases makes him a great code reviewer, being able to catch several
issues during the code review process.

I will monitor the thread for a week and if no objections are exposed I
will add him to the tripleo-core group.

PD: Here comes the +1 from my side.

Thanks.

Cheers,
Jos? Luis

[1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
[2]:
https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
[3]: Position #25 in the most active TripleO contributors list
<https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/0662f14a/attachment.htm>

From ces.eduardo98 at gmail.com  Thu Feb 10 14:41:02 2022
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Thu, 10 Feb 2022 11:41:02 -0300
Subject: [manila][cinder][glance][nova][devstack][qa] Add fmount to
 devstack-plugin-ceph core
In-Reply-To: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>
References: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>
Message-ID: <CAE51gQJK=hixMRhKUpgUd5j+ty3P3=gHKOZa95pXpi0arWz5Pg@mail.gmail.com>

+1 from me! :)

Em qui., 10 de fev. de 2022 ?s 00:51, Goutham Pacha Ravi <
gouthampravi at gmail.com> escreveu:

> Hello,
>
> As you're aware, we're looking to adopt cephadm within
> devstack-plugin-ceph to align with the ceph community's
> recommendations on day0-day2 handling of ceph [1] in devstack.
>
> Francesco Pantano has worked a ton on the integration of ceph with
> tripleo. He has been our go-to person for deploying and using the new
> nfs daemon with manila. In light of this, to make reviews more
> productive, I would like to propose fpantano at redhat.com (fmount on
> launchpad and oftc) to the devstack-plugin-ceph-core group [2]. He's
> aware of our review policies, and will take care not to break existing
> testing. Any objections?
>
> Thank you,
> Goutham Pacha Ravi
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026778.html
> [2]
> https://review.opendev.org/admin/groups/8e51d8f39e33d932a40f03060b861db57a3d25d4,members
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/f6bcf305/attachment.htm>

From akekane at redhat.com  Thu Feb 10 14:50:10 2022
From: akekane at redhat.com (Abhishek Kekane)
Date: Thu, 10 Feb 2022 20:20:10 +0530
Subject: [manila][cinder][glance][nova][devstack][qa] Add fmount to
 devstack-plugin-ceph core
In-Reply-To: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>
References: <CAKSuTPbtiYzTu5iG1vOFitzjSenJacTsOb6R2xg9zfG+M6BumA@mail.gmail.com>
Message-ID: <CALOt+SQdnw=oAB7NLcwUdAW8tvEAeK=1utRp=Sny41+NgOpYWQ@mail.gmail.com>

No objection from Glance as well.

Thanks & Best Regards,

Abhishek Kekane


On Thu, Feb 10, 2022 at 9:21 AM Goutham Pacha Ravi <gouthampravi at gmail.com>
wrote:

> Hello,
>
> As you're aware, we're looking to adopt cephadm within
> devstack-plugin-ceph to align with the ceph community's
> recommendations on day0-day2 handling of ceph [1] in devstack.
>
> Francesco Pantano has worked a ton on the integration of ceph with
> tripleo. He has been our go-to person for deploying and using the new
> nfs daemon with manila. In light of this, to make reviews more
> productive, I would like to propose fpantano at redhat.com (fmount on
> launchpad and oftc) to the devstack-plugin-ceph-core group [2]. He's
> aware of our review policies, and will take care not to break existing
> testing. Any objections?
>
> Thank you,
> Goutham Pacha Ravi
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026778.html
> [2]
> https://review.opendev.org/admin/groups/8e51d8f39e33d932a40f03060b861db57a3d25d4,members
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/2d7fd5bb/attachment.htm>

From hjensas at redhat.com  Thu Feb 10 14:54:27 2022
From: hjensas at redhat.com (Harald Jensas)
Date: Thu, 10 Feb 2022 15:54:27 +0100
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAJm6b-4+z67on3D94k02m5yN79Yr91TdFyN=vntKmSQNBBK+pQ@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
 <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
 <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>
 <CAJm6b-4+z67on3D94k02m5yN79Yr91TdFyN=vntKmSQNBBK+pQ@mail.gmail.com>
Message-ID: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com>

On 2/10/22 14:49, Lokendra Rathour wrote:
> Hi Harald,
> Thanks once again for your support, we tried activating the parameters:
> ServiceNetMap:
>  ? ? IronicApiNetwork: provisioning
>  ? ? IronicNetwork: provisioning
> at environments/network-environments.yaml
> image.png
> After changing?these values the?updated or even the fresh deployments 
> are failing.
> 

How did deployment fail?

> The command that we are using to deploy the OpenStack overcloud:
> /openstack overcloud deploy --templates \
>  ? ? -n /home/stack/templates/network_data.yaml \
>  ? ? -r /home/stack/templates/roles_data.yaml \
>  ? ? -e /home/stack/templates/node-info.yaml \
>  ? ? -e /home/stack/templates/environment.yaml \
>  ? ? -e /home/stack/templates/environments/network-isolation.yaml \
>  ? ? -e /home/stack/templates/environments/network-environment.yaml \

What modifications did you do to network-isolation.yaml and 
network-environment.yaml?

I typically use:
-e 
/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
-e 
/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml
-e /home/stack/templates/environments/network-overrides.yaml

The network-isolation.yaml and network-environment.yaml are Jinja2 
rendered based on the -n input, so too keep in sync with change in the 
`-n` file reference the file in 
/usr/share/opentack-tripleo-heat-templates. Then add overrides in 
network-overrides.yaml as neede.

>  ? ? -e 
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml 
> \
>  ? ? -e 
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml 
> \
>  ? ? -e 
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml 
> \
>  ? ? -e /home/stack/templates/ironic-config.yaml \
>  ? ? -e 
> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>  ? ? -e 
> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>  ? ? -e /home/stack/containers-prepare-parameter.yaml/
> 
> **/home/stack/templates/ironic-config.yaml :
> (overcloud) [stack at undercloud ~]$ cat 
> /home/stack/templates/ironic-config.yaml
> parameter_defaults:
>  ? ? IronicEnabledHardwareTypes:
>  ? ? ? ? - ipmi
>  ? ? ? ? - redfish
>  ? ? IronicEnabledPowerInterfaces:
>  ? ? ? ? - ipmitool
>  ? ? ? ? - redfish
>  ? ? IronicEnabledManagementInterfaces:
>  ? ? ? ? - ipmitool
>  ? ? ? ? - redfish
>  ? ? IronicCleaningDiskErase: metadata
>  ? ? IronicIPXEEnabled: true
>  ? ? IronicInspectorSubnets:
>  ? ? - ip_range: 172.23.3.100,172.23.3.150
>  ? ? IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel 
> <http://30.30.30.1:8088/agent.kernel>", 
> "http://30.30.30.1:8088/agent.ramdisk 
> <http://30.30.30.1:8088/agent.ramdisk>"] >  ? ? IronicInspectorInterface: 'br-baremetal'
> 
> Also the baremetal network(provisioning)(172.23.3.x)? is? routed with 
> ctlplane/admin network (30.30.30.x)
> 

Unless the network you created in the overcloud is named `provisioning`, 
these parameters may be relevant.

IronicCleaningNetwork:
   default: 'provisioning'
   description: Name or UUID of the *overcloud* network used for cleaning
                bare metal nodes. The default value of "provisioning" can be
                left during the initial deployment (when no networks are
                created yet) and should be changed to an actual UUID in
                a post-deployment stack update.
   type: string

IronicProvisioningNetwork:
   default: 'provisioning'
   description: Name or UUID of the *overcloud* network used for 
provisioning
                of bare metal nodes, if IronicDefaultNetworkInterface is
                set to "neutron". The default value of "provisioning" can be
                left during the initial deployment (when no networks are
                created yet) and should be changed to an actual UUID in
                a post-deployment stack update.
   type: string

IronicRescuingNetwork:
   default: 'provisioning'
   description: Name or UUID of the *overcloud* network used for resucing
                of bare metal nodes, if IronicDefaultRescueInterface is not
                set to "no-rescue". The default value of "provisioning" 
can be
                left during the initial deployment (when no networks are
                created yet) and should be changed to an actual UUID in
                a post-deployment stack update.
   type: string

> *Query:*
> 
>  1. any other location/way where we should add these so that they are
>     included without error.
> 
>         *ServiceNetMap:*
> 
>         *? ? IronicApiNetwork: provisioning*
> 
>         *? ? IronicNetwork: provisioning*
> 

`provisioning` network is defined in -n 
/home/stack/templates/network_data.yaml right? And an entry in 
'networks' for the controller role in /home/stack/templates/roles_data.yaml?


>      ?2. Also are these commands(mentioned above) configure Baremetal
>     services are fine.
> 

Yes, what you are doing makes sense.

I'm actually not sure why it did'nt work with your previous 
configuration, it got the information about NBP file and obviously 
attempted to download it from 30.30.30.220. With routing in place, that 
should work.

Changeing the ServiceNetMap to move IronicNetwork services to the 
172.23.3 would avoid the routing.


What is NeutronBridgeMappings?
  br-baremetal maps to the physical network of the overcloud 
`provisioning` neutron network?


--
Harald



From johfulto at redhat.com  Thu Feb 10 15:05:32 2022
From: johfulto at redhat.com (John Fulton)
Date: Thu, 10 Feb 2022 10:05:32 -0500
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
Message-ID: <CAE66OMAQo9BnOmQLQXh5QoHoDeQH6k93DN+et=mTxFUS3WU+=w@mail.gmail.com>

On Thu, Feb 10, 2022 at 9:37 AM Jose Luis Franco Arza
<jfrancoa at redhat.com> wrote:
>
> Hello folks,
>
> I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer on the TripleO repositories related to the upgrades workflow (openstack/tripleo-heat-templates, openstack/tripleo-ansible, openstack/python-tripleoclient, openstack/tripleo-ci, openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii has been working in OpenStack for the last 10 years, he is already core-reviewer of the tripleo-upgrade repository in which he is providing with very valuable feedback, as well as helping getting relevant patches merged.
>
> His deep knowledge of the different OpenStack projects, as well as his involvement in the upgrades/updates workflows for the last 9 OpenStack releases makes him a great code reviewer, being able to catch several issues during the code review process.
>
> I will monitor the thread for a week and if no objections are exposed I will add him to the tripleo-core group.
>
> PD: Here comes the +1 from my side.

+1

>
> Thanks.
>
> Cheers,
> Jos? Luis
>
> [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> [2]: https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> [3]: Position #25 in the most active TripleO contributors list



From juliaashleykreger at gmail.com  Thu Feb 10 15:10:53 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Thu, 10 Feb 2022 07:10:53 -0800
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
 <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
Message-ID: <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>

If the disk controllers *are* enumerated in the kernel log, which is
something to also look for, then the disks themselves may be in some
weird state like security locked. Generally this shows up as the
operating system kind of sees the disk and the SATA port connected but
can't really access it. This is also an exceptionally rare state to
find one's self in.

More common, especially in enterprise grade hardware: If the disk
controller is actually a raid controller, and there are no raid
volumes configured, then the operating system likely cannot see the
underlying disks and turn that into a usable block device. I've seen a
couple drivers over the years which expose hints of disks in the
kernel log and without raid configuration in the cards, the drivers
can't present usable block devices to the operating system system.

-Julia

On Thu, Feb 10, 2022 at 3:17 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
>
> Hi Guangyu,
>
> No worries about asking questions, this is what the mailing
> list is for :)
>
> Just to clarify, you do not have to set root device hints,
> it also works without (with the algorithm I mentioned).
> However, hints help to define the exact device and/or make
> deployment more predictable/repeatable.
>
> If it is really a driver problem, it is an issue with the
> operating system of the image you use, i.e. CentOS8. Some
> drivers were removed from 7 to 8, and we have seen issues
> with specific drive models as well.
>
> You can try to build your own IPA images as described in
> [1], e.g. to add your ssh key to be able to log into the
> IPA to debug further, and to eventually include drivers
> (if you can identify them and they are available for CentOS8).
>
> Another option may be to add another (newer) disk model to
> the server, just to confirm it is the disk model/driver which
> is the cause.
>
> You could also try to boot the node into a CentOS7 (and then
> a CentOS8) live image to confirm it can see the disks at all.
>
> Hope this helps!
>   Arne
>
> [1]
> https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html
>
>
> On 10.02.22 11:15, ??? wrote:
> > Hi Arne,
> >
> > Thank you very much for your response. Love you. You take away a lot
> > of my confusion.
> >
> > You are right, I didn't set 'root device'. And Ironic also can not see
> > disk, the content of the 'lsblk' file in the deploy los is emply.
> > I tried to set 'root device', but because ironic can't find any disk,
> > the deploy still filed.
> >
> > Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
> > inaccessible, /dev/disk/by-path/* version of block device name is
> > unavailable Cause: [Errno 2] No such file or directory:
> > '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> > directory: '/dev/disk/by-path'
> > Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
> > matches the root device hints {'wwn': '0x50014EE2691D724C'}:
> > StopIteration
> >
> > Sorry to bother you, I'm a newcomer of Ironic and I didn't find
> > information about it on google.
> >
> > The bare metal node have three same disk(Western Digital DC HA210 2TB
> > SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
> > this disk?
> >
> > And If Ironic cannot find disk since the corresponding drivers in the
> > IPA image are missing, do you know how to resolve it? I have used the
> > latest deploy images in
> > https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
> > .  Do I need to find and manually add driver in the source code or
> > ramdisk(That was difficult tome)?
> >
> > Love you.
> >
> > Cheers,
> > Guangyu
> >
> > Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
> >>
> >> Hi Guangyu,
> >>
> >> The error indicates that Ironic was not able to find
> >> a device where it could deploy the image to.
> >>
> >> To find a device, Ironic will use 'root device'
> >> hints [1], usually set by the admin on a node. If that
> >> does not yield anything, Ironic will loop over all
> >> block devices and pick the smallest which is larger
> >> than 4GB (and order them alphabetically).
> >>
> >> If you have disks in your server which are larger than
> >> 4GB, one potential explanation is that Ironic cannot see them,
> >> e.g. since the corresponding drivers in the IPA image are missing.
> >> The logs you posted seem to confirm something along those
> >> lines.
> >>
> >> Check the content of the 'lsblk' file in the deploy logs which
> >> you can find in the tar archive in /var/log/ironic/deploy/
> >> on the controller for your deployment attempt to see what
> >> devices Ironic has access to.
> >>
> >> Cheers,
> >>    Arne
> >>
> >>
> >> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
> >>
> >> On 10.02.22 02:50, ??? wrote:
> >>> Dear all,
> >>>
> >>> I have a OpenStack Victoria environment, and tried to use ironic
> >>> manage bare metal. But I got "- root device hints were not provided
> >>> and all found block devices are smaller than 4294967296B." in deploy
> >>> stage.
> >>>
> >>> 2022-02-09 17:57:56.492 3908982 ERROR
> >>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
> >>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
> >>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
> >>> No suitable device was found for deployment - root device hints were
> >>> not provided and all found block devices are smaller than
> >>> 4294967296B..
> >>>
> >>> I used "openstack server create --flavor my-baremetal-flavor --nic
> >>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
> >>> download deploy images(ipa-centos8-master.kernel and
> >>> ipa-centos8-master.initramfs) in
> >>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
> >>>
> >>> The baremetal node info and flavor info as following:
> >>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
> >>> Ironic configure file as following:
> >>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
> >>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
> >>> The log of ironic-python-agent in bare metal node:
> >>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
> >>>
> >>> I see some old discussion about this, such as:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
> >>> discussions took place a long time ago, not version V, and no solution
> >>> was seen.
> >>>
> >>> Does anyone know how to solve this problem? I would appreciate any
> >>> kind of guidance or help.
> >>>
> >>> Thank you,
> >>> Han Guangyu
> >>>
>


From jbadiapa at redhat.com  Thu Feb 10 15:13:46 2022
From: jbadiapa at redhat.com (Juan Badia Payno)
Date: Thu, 10 Feb 2022 16:13:46 +0100
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CAE66OMAQo9BnOmQLQXh5QoHoDeQH6k93DN+et=mTxFUS3WU+=w@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
 <CAE66OMAQo9BnOmQLQXh5QoHoDeQH6k93DN+et=mTxFUS3WU+=w@mail.gmail.com>
Message-ID: <CAKnAgae0jiuKNCWDhaH59PyQzkv8SDhgr+WFOM1WW7PB=7L77g@mail.gmail.com>

+1

On Thu, Feb 10, 2022 at 4:12 PM John Fulton <johfulto at redhat.com> wrote:

> On Thu, Feb 10, 2022 at 9:37 AM Jose Luis Franco Arza
> <jfrancoa at redhat.com> wrote:
> >
> > Hello folks,
> >
> > I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer
> on the TripleO repositories related to the upgrades workflow
> (openstack/tripleo-heat-templates, openstack/tripleo-ansible,
> openstack/python-tripleoclient, openstack/tripleo-ci,
> openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii
> has been working in OpenStack for the last 10 years, he is already
> core-reviewer of the tripleo-upgrade repository in which he is providing
> with very valuable feedback, as well as helping getting relevant patches
> merged.
> >
> > His deep knowledge of the different OpenStack projects, as well as his
> involvement in the upgrades/updates workflows for the last 9 OpenStack
> releases makes him a great code reviewer, being able to catch several
> issues during the code review process.
> >
> > I will monitor the thread for a week and if no objections are exposed I
> will add him to the tripleo-core group.
> >
> > PD: Here comes the +1 from my side.
>
> +1
>
> >
> > Thanks.
> >
> > Cheers,
> > Jos? Luis
> >
> > [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> > [2]:
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> > [3]: Position #25 in the most active TripleO contributors list
>
>
>

-- 

Juan Badia Payno

Senior Software Engineer

Red Hat EMEA ENG Openstack Infrastructure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/0c8bde5d/attachment.htm>

From dvd at redhat.com  Thu Feb 10 15:14:46 2022
From: dvd at redhat.com (David Vallee Delisle)
Date: Thu, 10 Feb 2022 10:14:46 -0500
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CAE66OMAQo9BnOmQLQXh5QoHoDeQH6k93DN+et=mTxFUS3WU+=w@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
 <CAE66OMAQo9BnOmQLQXh5QoHoDeQH6k93DN+et=mTxFUS3WU+=w@mail.gmail.com>
Message-ID: <CA+K-fVhWrh7Zt5PrtDcz-hSKpA_h_wPqBFLTee110hG5YnD+ZQ@mail.gmail.com>

+1 as well

DVD


On Thu, Feb 10, 2022 at 10:09 AM John Fulton <johfulto at redhat.com> wrote:

> On Thu, Feb 10, 2022 at 9:37 AM Jose Luis Franco Arza
> <jfrancoa at redhat.com> wrote:
> >
> > Hello folks,
> >
> > I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer
> on the TripleO repositories related to the upgrades workflow
> (openstack/tripleo-heat-templates, openstack/tripleo-ansible,
> openstack/python-tripleoclient, openstack/tripleo-ci,
> openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii
> has been working in OpenStack for the last 10 years, he is already
> core-reviewer of the tripleo-upgrade repository in which he is providing
> with very valuable feedback, as well as helping getting relevant patches
> merged.
> >
> > His deep knowledge of the different OpenStack projects, as well as his
> involvement in the upgrades/updates workflows for the last 9 OpenStack
> releases makes him a great code reviewer, being able to catch several
> issues during the code review process.
> >
> > I will monitor the thread for a week and if no objections are exposed I
> will add him to the tripleo-core group.
> >
> > PD: Here comes the +1 from my side.
>
> +1
>
> >
> > Thanks.
> >
> > Cheers,
> > Jos? Luis
> >
> > [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> > [2]:
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> > [3]: Position #25 in the most active TripleO contributors list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/531c26d7/attachment-0001.htm>

From sshnaidm at redhat.com  Thu Feb 10 15:45:04 2022
From: sshnaidm at redhat.com (Sagi Shnaidman)
Date: Thu, 10 Feb 2022 17:45:04 +0200
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
Message-ID: <CAGHQP9wJ0L3dqz1zCyP6RR4NriVifDB6OCasg9-=QtTqOBN1RQ@mail.gmail.com>

+1

On Thu, Feb 10, 2022 at 4:44 PM Jose Luis Franco Arza <jfrancoa at redhat.com>
wrote:

> Hello folks,
>
> I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer on
> the TripleO repositories related to the upgrades workflow
> (openstack/tripleo-heat-templates, openstack/tripleo-ansible,
> openstack/python-tripleoclient, openstack/tripleo-ci,
> openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii
> has been working in OpenStack for the last 10 years, he is already
> core-reviewer of the tripleo-upgrade
> <https://github.com/openstack/tripleo-upgrade>repository in which he is
> providing with very valuable feedback, as well as helping getting relevant
> patches merged.
>
> His deep knowledge of the different OpenStack projects, as well as his
> involvement in the upgrades/updates workflows for the last 9 OpenStack
> releases makes him a great code reviewer, being able to catch several
> issues during the code review process.
>
> I will monitor the thread for a week and if no objections are exposed I
> will add him to the tripleo-core group.
>
> PD: Here comes the +1 from my side.
>
> Thanks.
>
> Cheers,
> Jos? Luis
>
> [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> [2]:
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> [3]: Position #25 in the most active TripleO contributors list
> <https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180>
>


-- 
Best regards
Sagi Shnaidman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/1c07067e/attachment.htm>

From gmann at ghanshyammann.com  Thu Feb 10 16:03:44 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 10 Feb 2022 10:03:44 -0600
Subject: [all][tc] Relmgt team position on release cadence
In-Reply-To: <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com>
References: <40f6f51b-6903-1afe-7318-0689b2af482d@openstack.org>
 <8301ef05-4011-43e9-beec-66f6aeeb00f9@www.fastmail.com>
 <20211129130957.3poysdeqsufkp3pg@yuggoth.org>
 <f2c4ab93-a1e1-475c-8b35-1b303b8fb96b@www.fastmail.com>
 <d28fc7ccfecd753561e1d395c672e987f95eb748.camel@redhat.com>
 <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com>
 <CAF7gwdiUF2wj7RqN-LzwvwH1FQ1A7j=F-CikHKS0ct8AKNAdJg@mail.gmail.com>
 <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org>
 <CAF7gwdhnS_101_Ljf++V=-jGwKZ_NUm6gn+Jzo_N-VDwDuvayw@mail.gmail.com>
 <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com>
 <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
 <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>
 <fc5569d6-15e6-4d33-b0f4-2d619f90e732@www.fastmail.com>
 <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com>
Message-ID: <17ee46051c6.12bb64653143256.163506775198229925@ghanshyammann.com>

 ---- On Wed, 09 Feb 2022 11:20:13 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  ---- On Wed, 02 Feb 2022 13:17:19 -0600 Jean-Philippe Evrard <openstack at a.spamming.party> wrote ----
 >  > On Tue, Feb 1, 2022, at 23:14, Ghanshyam Mann wrote:
 >  > > I might not be available this week, we will schedule this meeting next 
 >  > > week or so.
 >  > 
 >  > Ok, I hope I won't miss the next date then! :)
 >  > Thanks for organising this, Ghanshyam.
 > 
 > We will meet tomorrow right after the TC meeting.
 > 
 > Time: 10th Feb, 16:00 UTC
 > Location: Voice/Video call @ https://meetpad.opendev.org/OpenStackReleasecadence

We are about to start the discussion, please join if you are interested.

-gmann

 > 
 > -gmann
 > 
 >  > 
 >  > Regards,
 >  > JP
 >  > 
 >  > 
 > 
 > 


From bdobreli at redhat.com  Thu Feb 10 16:06:22 2022
From: bdobreli at redhat.com (Bogdan Dobrelya)
Date: Thu, 10 Feb 2022 17:06:22 +0100
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CAGHQP9wJ0L3dqz1zCyP6RR4NriVifDB6OCasg9-=QtTqOBN1RQ@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
 <CAGHQP9wJ0L3dqz1zCyP6RR4NriVifDB6OCasg9-=QtTqOBN1RQ@mail.gmail.com>
Message-ID: <76d16ee9-8dfc-246f-134f-162b20652c1f@redhat.com>

+1

On 2/10/22 16:45, Sagi Shnaidman wrote:
> +1
> 
> On Thu, Feb 10, 2022 at 4:44 PM Jose Luis Franco Arza 
> <jfrancoa at redhat.com <mailto:jfrancoa at redhat.com>> wrote:
> 
>     Hello folks,
> 
>     I would like to propose Sergii Golovatiuk [1][2][3] as a core
>     reviewer on the TripleO repositories related to the upgrades
>     workflow (openstack/tripleo-heat-templates,
>     openstack/tripleo-ansible, openstack/python-tripleoclient,
>     openstack/tripleo-ci, openstack/tripleo-quickstart,
>     openstack/tripleo-quickstart-extras). Sergii has been working in
>     OpenStack for the last 10 years, he is already core-reviewer of
>     thetripleo-upgrade
>     <https://github.com/openstack/tripleo-upgrade>repository in which he
>     is providing with very valuable feedback, as well as helping getting
>     relevant patches merged.
> 
>     His deep knowledge of the different OpenStack projects, as well as
>     his involvement in the upgrades/updates workflows for the last 9
>     OpenStack releases makes him a great code reviewer, being able to
>     catch several issues during the code review process.
> 
>     I will monitor the thread for a week and if no objections are
>     exposed I will add him to the tripleo-core group.
> 
>     PD: Here comes the +1 from my side.
> 
>     Thanks.
> 
>     Cheers,
>     Jos? Luis
> 
>     [1]:https://review.opendev.org/q/owner:sgolovat%2540redhat.com
>     <https://review.opendev.org/q/owner:sgolovat%2540redhat.com>
>     [2]:
>     https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
>     <https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all>
>     [3]: Position #25 in the most active TripleO contributors list
>     <https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180>
> 
> 
> 
> -- 
> Best regards
> Sagi Shnaidman


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



From derekokeeffe85 at yahoo.ie  Thu Feb 10 16:12:45 2022
From: derekokeeffe85 at yahoo.ie (Derek O keeffe)
Date: Thu, 10 Feb 2022 16:12:45 +0000 (UTC)
Subject: Masquerading VM works 99%
References: <46615849.557895.1644509565653.ref@mail.yahoo.com>
Message-ID: <46615849.557895.1644509565653@mail.yahoo.com>

Hi all,
We have an openstack cluster with one controller and 4 computes (Victoria) we have set it up using vlan provider networks with linuxbridge agent, distributed routing & ml2 (I am only partly on the networking so there could be more to that which I can find out if needed)
So I was tasked with creating two Instances, one (lets call it the external vm) with an external interface 10.55.9.67 and internal interface 192.168.1.2. A second instance (lets call it the internal vm) would then be placed on the 192.168.1.0 network.
I configured masquerading on the "external vm" and tried to ping the outside world from the "internal" vm as per something like this?https://kifarunix.com/configure-ubuntu-20-04-as-linux-router/?unapproved=49571&moderation-hash=b5168c04420557dcdc088994ffa4bdbb#comment-49571

Both VM's were instantiated on the same compute host (I've tried it with them on separate hosts as well).
I can see the ping leave using tcpdumps along the way and it makes it all the way back to the internal interface on the external machine. It just fails on the last hop to the internal machine. I've tried everything in my power to find why this won't work so I would be grateful for any advice at all. I have added the below to show how I followed the ping manually and where it went and when it failed. Thank you in advance.
Following the ping from source to destination and back:Generated on the private VMsent to the internal interface on the external vmsent to the external interface on the external vmsent to the tap interface on the computesent to the physical nic on the computesent to the nic on the network device out to the internet
received on nic on the network devicefrom the internet?received on physical nic on the computereceived on tap interface on compute?received on external interface on the external vmreceived on the internal interface on the external vmNEVER gets to last step on the internal vm?
Regards,Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/c60e36ac/attachment.htm>

From mahendra.paipuri at cnrs.fr  Thu Feb 10 16:57:22 2022
From: mahendra.paipuri at cnrs.fr (Mahendra Paipuri)
Date: Thu, 10 Feb 2022 17:57:22 +0100
Subject: [kolla][ceilometer][gnocchi] Error in ceilometer_central service
Message-ID: <ea6a6811-f689-62fe-ccbc-64195abac2b3@cnrs.fr>

Hello,

I am playing around Openstack using kolla-ansible deployment on a single 
node. I am facing the same issue as here -> 
https://bugs.launchpad.net/kolla-ansible/+bug/1920095. I see that there 
is an PR here -> 
https://review.opendev.org/c/openstack/kolla-ansible/+/781595 but has 
not been merged.

Is it still a bug or am I missing something in kolla configuration?

Cheers

Mahendra



From mahendra.paipuri at cnrs.fr  Thu Feb 10 17:11:58 2022
From: mahendra.paipuri at cnrs.fr (Mahendra Paipuri)
Date: Thu, 10 Feb 2022 18:11:58 +0100
Subject: [kolla][ceilometer][gnocchi] Error in ceilometer_central service
In-Reply-To: <ea6a6811-f689-62fe-ccbc-64195abac2b3@cnrs.fr>
References: <ea6a6811-f689-62fe-ccbc-64195abac2b3@cnrs.fr>
Message-ID: <a5f6f68b-211d-f8bf-8cc4-fb96f89f0b02@cnrs.fr>

I forgot to mention. I am using Xena release.

On 10/02/2022 17:57, Mahendra Paipuri wrote:
> Hello,
>
> I am playing around Openstack using kolla-ansible deployment on a 
> single node. I am facing the same issue as here -> 
> https://bugs.launchpad.net/kolla-ansible/+bug/1920095. I see that 
> there is an PR here -> 
> https://review.opendev.org/c/openstack/kolla-ansible/+/781595 but has 
> not been merged.
>
> Is it still a bug or am I missing something in kolla configuration?
>
> Cheers
>
> Mahendra
>
>


From h819284594 at live.com  Thu Feb 10 03:44:00 2022
From: h819284594 at live.com (=?utf-8?B?6buEIOS4gOW/gw==?=)
Date: Thu, 10 Feb 2022 03:44:00 +0000
Subject: [TaskFlow]
Message-ID: <OS0P286MB0225C5E00F08E25BBB992F5CFD2F9@OS0P286MB0225.JPNP286.PROD.OUTLOOK.COM>



????iPhone

From h819284594 at live.com  Thu Feb 10 06:10:14 2022
From: h819284594 at live.com (=?gb2312?B?u8Yg0rvQxA==?=)
Date: Thu, 10 Feb 2022 06:10:14 +0000
Subject: [TaskFlow]
Message-ID: <OS0P286MB022545DD17ADF66580C48F33FD2F9@OS0P286MB0225.JPNP286.PROD.OUTLOOK.COM>

Hi,
In our project, the taskflow is used to back up and restore data. After the task is submitted or started to run, the task may be suspended. However, the program process still exists. It seems that the thread for executing the task is missing. After the program process is restarted, the task can be resumed. Can you give us some advice.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/af3316e7/attachment-0001.htm>

From lokendrarathour at gmail.com  Thu Feb 10 13:49:31 2022
From: lokendrarathour at gmail.com (Lokendra Rathour)
Date: Thu, 10 Feb 2022 19:19:31 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
 <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
 <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>
Message-ID: <CAJm6b-4+z67on3D94k02m5yN79Yr91TdFyN=vntKmSQNBBK+pQ@mail.gmail.com>

Hi Harald,
Thanks once again for your support, we tried activating the parameters:
ServiceNetMap:
    IronicApiNetwork: provisioning
    IronicNetwork: provisioning
at environments/network-environments.yaml
[image: image.png]
After changing these values the updated or even the fresh deployments are
failing.

The command that we are using to deploy the OpenStack overcloud:













*openstack overcloud deploy --templates \    -n
/home/stack/templates/network_data.yaml \    -r
/home/stack/templates/roles_data.yaml \    -e
/home/stack/templates/node-info.yaml \    -e
/home/stack/templates/environment.yaml \    -e
/home/stack/templates/environments/network-isolation.yaml \    -e
/home/stack/templates/environments/network-environment.yaml \    -e
/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
\    -e
/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
\    -e
/usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
\    -e /home/stack/templates/ironic-config.yaml \    -e
/usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml
\    -e /home/stack/containers-prepare-parameter.yaml*

**/home/stack/templates/ironic-config.yaml :
(overcloud) [stack at undercloud ~]$ cat
/home/stack/templates/ironic-config.yaml
parameter_defaults:
    IronicEnabledHardwareTypes:
        - ipmi
        - redfish
    IronicEnabledPowerInterfaces:
        - ipmitool
        - redfish
    IronicEnabledManagementInterfaces:
        - ipmitool
        - redfish
    IronicCleaningDiskErase: metadata
    IronicIPXEEnabled: true
    IronicInspectorSubnets:
    - ip_range: 172.23.3.100,172.23.3.150
    IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel", "
http://30.30.30.1:8088/agent.ramdisk"]'
    IronicInspectorInterface: 'br-baremetal'

Also the baremetal network(provisioning)(172.23.3.x)  is  routed with
ctlplane/admin network (30.30.30.x)

*Query:*

   1. any other location/way where we should add these so that they are
   included without error.

*ServiceNetMap:*

*    IronicApiNetwork: provisioning*

*    IronicNetwork: provisioning*

 2. Also are these commands(mentioned above) configure Baremetal services
are fine.


Best Regards,
Lokendra


On Wed, Feb 9, 2022 at 11:55 PM Harald Jensas <hjensas at redhat.com> wrote:

> On 2/9/22 15:58, Lokendra Rathour wrote:
> > Hi Harald,
> > Responding on behalf of Anirudh's email:
> > Thanks for the response and we now do understand that we are getting IP
> > from the expected DHCP server.
> >
> > We tried the scenario and here are our findings, Our admin and internal
> > endpoints are on subnet: 30.30.30.x
> > public : 10.0.1.x
> >
> > (overcloud) [stack at undercloud ~]$ *OpenStack endpoint list | grep
> ironic*
> > | 04c163251e5546769446a4fa4fa20484 | regionOne | ironic           |
> > baremetal               | True    | admin     | http://30.30.30.213:6385
> > <http://30.30.30.213:6385>                       |
> > | 5c8557ae639a4898bdc6121f6e873724 | regionOne | ironic           |
> > baremetal               | True    | internal  | http://30.30.30.213:6385
> > <http://30.30.30.213:6385>                       |
> > | 62e07a3b2f3f4158bb27d8603a8f5138 | regionOne | ironic-inspector |
> > baremetal-introspection | True    | public    | http://10.0.1.88:5050
> > <http://10.0.1.88:5050>                          |
> > | af29bd64513546409f44cc5d56ea1082 | regionOne | ironic-inspector |
> > baremetal-introspection | True    | internal  | http://30.30.30.213:5050
> > <http://30.30.30.213:5050>                       |
> > | b76cdb5e77c54fc6b10cbfeada0e8bf5 | regionOne | ironic-inspector |
> > baremetal-introspection | True    | admin     | http://30.30.30.213:5050
> > <http://30.30.30.213:5050>                       |
> > | bd2954f41e49419f85669990eb59f51a | regionOne | ironic           |
> > baremetal               | True    | public    | http://10.0.1.88:6385
> > <http://10.0.1.88:6385>                          |
> > (overcloud) [stack at undercloud ~]$
> >
> >
> > we are following the flat default n/w approach for ironic provisioning,
> > for which we are creating a flat network on baremetal physnet. we are
> > still getting IP from neutron range (172.23.3.220 - 172.23.3.240)  -
> > 172.23.3.240.
> >
> > Further, we found that once IP (172.23.3.240) is allocated to baremetal
> > node, it looks for 30.30.30.220( IP of one of the three controllers) for
> > pxe booting.
> > Checking the same controllers logs we found that
> >
> > *`/var/lib/ironic/tftpboot/pxelinux.cfg/` directory exists,* but then
> > there is *no file matching the mac *address of the baremetal node.
> >
> > Also checking the *extra_dhcp_opts* we found this:
> > (overcloud) [stack at undercloud ~]$ *openstack port show
> > d7e573bf-1028-437a-8118-a2074c7573b2 | grep "extra_dhcp_opts"*
> >
> >     | extra_dhcp_opts         | ip_version='4', opt_name='tag:ipxe,67',
> >     opt_value='http://30.30.30.220:8088/boot.ipxe
> >     <http://30.30.30.220:8088/boot.ipxe>'
> >
> >
> > image.png
> > *Few points as observations:*
> >
> >  1. Although the baremetal network (172.23.3.x) is routable to the admin
> >     network (30.30.30.x), but it gets timeout at this window.
>
> It should be able to download the file over a routed network.
>
> >  2. in TCPDump we are only getting read requests.
>
> If you have access check the switches and routers if you can see the
> traffic being dropped/blocked somewhere on the path?
>
>
> I'm not 100% sure what parameters you used when deploying, but did you
> try to change the ServiceNetMap for IronicApiNetwork, IronicNetwork?
>
> If you set that to the name of the baremetal network (172.23.3.x)?
>
> ServiceNetMap:
>     IronicApiNetwork: baremetal_network
>     IronicNetwork: baremetal_network
>
> The result will be that the http server will listen on 172.23.3.x, and
> the extra_dhcp_opts should point to 172.23.3.x as well.
>
>
> >  3. `openstack baremetal node list
> >      1. (overcloud) [stack at undercloud ~]$ openstack baremetal node list
> >
>  +--------------------------------------+------+---------------+-------------+--------------------+-------------+
> >         | UUID                                 | Name | Instance UUID |
> >         Power State | Provisioning State | Maintenance |
> >
>  +--------------------------------------+------+---------------+-------------+--------------------+-------------+
> >         | 7066fbe1-9c29-4702-9cd4-2b55daf19630 | bm1  | None          |
> >         power on    | clean wait         | False       |
> >
>  +--------------------------------------+------+---------------+-------------+--------------------+-------------+
> >  4.   `openstack baremetal node show <node-uuid>`
> >      1.
> >
> >         (overcloud) [stack at undercloud ~]$ openstack baremetal node show
> bm1
> >
>  +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> >         | Field                  | Value
> >
> >
> >
> >                           |
> >
>  +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> >         | allocation_uuid        | None
> >
> >
> >
> >                            |
> >         | automated_clean        | None
> >
> >
> >
> >                            |
> >         | bios_interface         | no-bios
> >
> >
> >
> >                           |
> >         | boot_interface         | ipxe
> >
> >
> >
> >                            |
> >         | chassis_uuid           | None
> >
> >
> >
> >                            |
> >         | clean_step             | {}
> >
> >
> >
> >                            |
> >         | conductor              | overcloud-controller-0.localdomain
> >
> >
> >
> >                            |
> >         | conductor_group        |
> >
> >
> >
> >                           |
> >         | console_enabled        | False
> >
> >
> >
> >                           |
> >         | console_interface      | ipmitool-socat
> >
> >
> >
> >                            |
> >         | created_at             | 2022-02-09T14:21:24+00:00
> >
> >
> >
> >                           |
> >         | deploy_interface       | iscsi
> >
> >
> >
> >                           |
> >         | deploy_step            | {}
> >
> >
> >
> >                            |
> >         | description            | None
> >
> >
> >
> >                            |
> >         | driver                 | ipmi
> >
> >
> >
> >                            |
> >         | driver_info            | {'ipmi_address': '10.0.1.183',
> >         'ipmi_username': 'hsc', 'ipmi_password': '******',
> >         'ipmi_terminal_port': 623, 'deploy_kernel':
> >         '9e1365b6-261a-42a2-abfe-40158945de57', 'deploy_ramdisk':
> >         'fe608dd2-ce86-4faf-b4b8-cc5cb143eb56'}                        |
> >         | driver_internal_info   | {'agent_erase_devices_iterations': 1,
> >         'agent_erase_devices_zeroize': True,
> >         'agent_continue_if_ata_erase_failed': False,
> >         'agent_enable_ata_secure_erase': True,
> >         'disk_erasure_concurrency': 1, 'last_power_state_change':
> >         '2022-02-09T14:23:39.525629'} |
> >         | extra                  | {}
> >
> >
> >
> >                            |
> >         | fault                  | None
> >
> >
> >
> >                            |
> >         | inspect_interface      | inspector
> >
> >
> >
> >                           |
> >         | inspection_finished_at | None
> >
> >
> >
> >                            |
> >         | inspection_started_at  | None
> >
> >
> >
> >                            |
> >         | instance_info          | {}
> >
> >
> >
> >                            |
> >         | instance_uuid          | None
> >
> >
> >
> >                            |
> >         | last_error             | None
> >
> >
> >
> >                            |
> >         | maintenance            | False
> >
> >
> >
> >                           |
> >         | maintenance_reason     | None
> >
> >
> >
> >                            |
> >         | management_interface   | ipmitool
> >
> >
> >
> >                            |
> >         | name                   | bm1
> >
> >
> >
> >                           |
> >         | network_interface      | flat
> >
> >
> >
> >                            |
> >         | owner                  | None
> >
> >
> >
> >                            |
> >         | power_interface        | ipmitool
> >
> >
> >
> >                            |
> >         | power_state            | power on
> >
> >
> >
> >                            |
> >         | properties             | {'cpus': 20, 'cpu_arch': 'x86_64',
> >         'capabilities': 'boot_option:local,boot_mode:uefi', 'memory_mb':
> >         63700, 'local_gb': 470, 'vendor': 'hewlett-packard'}
> >
> >                            |
> >         | protected              | False
> >
> >
> >
> >                           |
> >         | protected_reason       | None
> >
> >
> >
> >                            |
> >         | provision_state        | clean wait
> >
> >
> >
> >                            |
> >         | provision_updated_at   | 2022-02-09T14:24:05+00:00
> >
> >
> >
> >                           |
> >         | raid_config            | {}
> >
> >
> >
> >                            |
> >         | raid_interface         | no-raid
> >
> >
> >
> >                           |
> >         | rescue_interface       | agent
> >
> >
> >
> >                           |
> >         | reservation            | None
> >
> >
> >
> >                            |
> >         | resource_class         | bm1
> >
> >
> >
> >                           |
> >         | storage_interface      | noop
> >
> >
> >
> >                            |
> >         | target_power_state     | None
> >
> >
> >
> >                            |
> >         | target_provision_state | available
> >
> >
> >
> >                           |
> >         | target_raid_config     | {}
> >
> >
> >
> >                            |
> >         | traits                 | []
> >
> >
> >
> >                            |
> >         | updated_at             | 2022-02-09T14:24:05+00:00
> >
> >
> >
> >                           |
> >         | uuid                   | 7066fbe1-9c29-4702-9cd4-2b55daf19630
> >
> >
> >
> >                            |
> >         | vendor_interface       | ipmitool
> >
> >
> >
> >                            |
> >
>  +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> >         (overcloud) [stack at undercloud ~]$
> >
> >
> >
> > *Queries:*
> >
> >   * What are the settings we can do for successfully pxe-boot of the
> >     baremetal node and provisioning our node successfully ?
> >
> >
> >
> >
> >
> > On Tue, Feb 8, 2022 at 6:27 PM Harald Jensas <hjensas at redhat.com
> > <mailto:hjensas at redhat.com>> wrote:
> >
> >     On 2/7/22 13:47, Anirudh Gupta wrote:
> >      > Hi Julia,
> >      >
> >      > Thanks a lot for your responses and support.
> >      > To Update on the ongoing issue, I tried deploying the overcloud
> with
> >      > your valuable suggestions i.e by passing "*DhcpAgentNotification:
> >     true*"
> >      > in ironic-overcloud.yaml
> >      > The setup came up successfully, but with this configuration the IP
> >      > allocated on the system is one which is being configured while
> >     creating
> >      > the subnet in openstack.
> >      >
> >      > image.png
> >      >
> >      > The system is still getting the IP (172.23.3.212) from neutron.
> The
> >      > subnet range was configured as *172.23.3.210-172.23.3.240 *while
> >      > creating the provisioning subnet.
> >
> >
> >     The node is supposed to get an IP address from the neutron subnet on
> >     the
> >     provisioning network when:
> >     a) provisioning node
> >     b) cleaning node.
> >
> >     When you do "baremetal node provide" cleaning is most likely
> >     automatically initiated. (Since cleaning is enabled by default for
> >     Ironic in overcloud AFIK.)
> >
> >     The only time you will get an address from the IronicInspectorSubnets
> >     (ip_range: 172.23.3.100,172.23.3.150 in your case) is when you start
> >     ironic node introspection.
> >
> >      > The system gets stuck here and no action is performed after this.
> >      >
> >
> >     It seems the system is getting an address from the expected DHCP
> >     server,
> >     but it does not boot. I would start looking into the pxe properties
> in
> >     the DHCP Reply.
> >
> >     What is the status of the node in ironic at this stage?
> >        `openstack baremetal node list`
> >        `openstack baremetal node show <node-uuid>`
> >
> >     Check the `extra_dhcp_opts` on the neutron port, it should set the
> >     nextserver and bootfile parameters. Does the bootfile exist in
> >     /var/lib/ironic/tftpboot? Inspect the
> >     `/var/lib/ironic/tftpboot/pxelinux.cfg/` directory, you should see a
> >     file matching the MAC address of your system. Does the content make
> >     sense?
> >
> >     Can you capture DHCP and TFTP traffic on the provisioning network?
> >
> >      > Is there any way to resolve this and make successful
> >     provisioning the
> >      > baremetal node in *TripleO Train Release* (Since RHOSP 16 was on
> >     Train,
> >      > so I thought to go with that version for better stability)
> >      >
> >
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
> >     <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
> >
> >
> >      >
> >     <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
> >     <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index
> >>
> >      >
> >      > I have some queries:
> >      >
> >      >  1. Is passing "*DhcpAgentNotification: true" *enough or do we
> >     have to
> >      >     make some other changes as well?
> >
> >     I belive in train "DhcpAgentNotification" defaults to True.
> >     The change to default to false was added more recently, and it was
> not
> >     backported.
> >     (
> https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761
> >     <
> https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761>)
> >
> >     NOTE, the environment for enabling ironi for the overcloud
> >     'environments/services/ironic-overcloud.yaml' overrides this to
> 'true'
> >     in later releases.
> >
> >      >  2. Although there are some security concerns specified in the
> >     document,
> >      >     but Currently I am focusing on the default flat bare
> >     metal approach
> >      >     which has dedicated interface for bare metal Provisioning.
> >     There is
> >      >     one composable method approach as well. Keeping aside the
> >     security
> >      >     concerns, which approach is better and functional?
> >      >      1.
> >
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
> >     <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
> >
> >      >
> >       <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
> <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning
> >>
> >
> >     Both should work, using the composable network is more secure since
> >     baremetal nodes does not have access to the control plane network.
> >
> >      >  3. Will moving to upper openstack release version make this
> >     deployment
> >      >     possible?
> >      >      1. If Yes, which release should I go with as till wallaby the
> >      >         ironic-overcloud.yml file has no option of including
> >      >         "*DhcpAgentNotification: true*" by default
> >      >          1.
> >
> https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
> >     <
> https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
> >
> >      >
> >       <
> https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
> <
> https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml
> >>
> >      >
> >      >
> >      > Looking forward for your valuable feedback/response.
> >      >
> >      > Regards
> >      > Anirudh Gupta
> >      >
> >      >
> >      > On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta <anyrude10 at gmail.com
> >     <mailto:anyrude10 at gmail.com>
> >      > <mailto:anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>>> wrote:
> >      >
> >      >     Hi,
> >      >
> >      >     Surely I'll revert the status once it gets deployed.
> >      >     Bdw the suspicion is because of Train Release or it is
> >     something else?
> >      >
> >      >     Regards
> >      >     Anirudh Gupta
> >      >
> >      >     On Fri, 4 Feb, 2022, 20:29 Julia Kreger,
> >      >     <juliaashleykreger at gmail.com
> >     <mailto:juliaashleykreger at gmail.com>
> >     <mailto:juliaashleykreger at gmail.com
> >     <mailto:juliaashleykreger at gmail.com>>>
> >      >     wrote:
> >      >
> >      >
> >      >
> >      >         On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta
> >      >         <anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>
> >     <mailto:anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>>> wrote:
> >      >
> >      >             Hi Julia
> >      >
> >      >             Thanks for your response.
> >      >
> >      >             Earlier I was passing both ironic.yaml and
> >      >             ironic-overcloud.yaml located at path
> >      >
> >       /usr/share/openstack-tripleo-heat-templates/environments/services/
> >      >
> >      >             My current understanding now says that since I am
> >     using OVN,
> >      >             not OVS so I should pass only ironic-overcloud.yaml
> in my
> >      >             deployment.
> >      >
> >      >             I am currently on Train Release and my default
> >      >             ironic-overcloud.yaml file has no such entry
> >      >             DhcpAgentNotification: true
> >      >
> >      >
> >      >         I suspect that should work. Let us know if it does.
> >      >
> >      >             I would add this there and re deploy the setup.
> >      >
> >      >             Would that be enough to make my deployment successful?
> >      >
> >      >             Regards
> >      >             Anirudh Gupta
> >      >
> >      >
> >      >             On Fri, 4 Feb, 2022, 18:40 Julia Kreger,
> >      >             <juliaashleykreger at gmail.com
> >     <mailto:juliaashleykreger at gmail.com>
> >      >             <mailto:juliaashleykreger at gmail.com
> >     <mailto:juliaashleykreger at gmail.com>>> wrote:
> >      >
> >      >                 It is not a matter of disabling OVN, but a matter
> of
> >      >                 enabling the dnsmasq service and notifications.
> >      >
> >      >
> >
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
> >     <
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
> >
> >      >
> >       <
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
> <
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml
> >>
> >      >                 may provide some insight.
> >      >
> >      >                 I suspect if you're using stable/wallaby based
> >     branches
> >      >                 and it is not working, there may need to be a
> patch
> >      >                 backported by the TripleO maintainers.
> >      >
> >      >                 On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta
> >      >                 <anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>
> >     <mailto:anyrude10 at gmail.com <mailto:anyrude10 at gmail.com>>> wrote:
> >      >
> >      >                     Hi Julia,
> >      >
> >      >                     Thanks for your response.
> >      >                     For the overcloud deployment, I am executing
> the
> >      >                     following command:
> >      >
> >      >                     openstack overcloud deploy --templates \
> >      >                          -n
> /home/stack/templates/network_data.yaml \
> >      >                          -r /home/stack/templates/roles_data.yaml
> \
> >      >                          -e /home/stack/templates/node-info.yaml \
> >      >                          -e
> /home/stack/templates/environment.yaml \
> >      >                          -e
> >      >
> >       /home/stack/templates/environments/network-isolation.yaml
> >      >                     \
> >      >                          -e
> >      >
> >       /home/stack/templates/environments/network-environment.yaml
> >      >                     \
> >      >                          -e
> >      >
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml
> >      >                     \
> >      >                          -e
> >      >
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
> >      >                     \
> >      >                          -e
> >      >
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
> >      >                     \
> >      >                          -e
> >      >
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
> >      >                     \
> >      >                          -e
> >     /home/stack/templates/ironic-config.yaml \
> >      >                          -e
> >      >
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
> >      >                     \
> >      >                          -e
> >      >
> >
>  /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml
> >      >                     \
> >      >                          -e
> >     /home/stack/containers-prepare-parameter.yaml
> >      >
> >      >                     I can see some OVN related stuff in my
> roles_data
> >      >                     and environments/network-isolation.yaml
> >      >
> >      >                     [stack at undercloud ~]$ grep -inr "ovn"
> >      >                     roles_data.yaml:34: *OVNCMSOptions:
> >      >                     "enable-chassis-as-gw"*
> >      >                     roles_data.yaml:168:    -
> >      >                     *OS::TripleO::Services::OVNDBs*
> >      >                     roles_data.yaml:169:    -
> >      >                     *OS::TripleO::Services::OVNController*
> >      >                     roles_data.yaml:279:    -
> >      >                     *OS::TripleO::Services::OVNController*
> >      >                     roles_data.yaml:280:    -
> >      >                     *OS::TripleO::Services::OVNMetadataAgent*
> >      >                     environments/network-isolation.yaml:16:
> >      >                     *OS::TripleO::Network::Ports::OVNDBsVipPort:
> >      >                     ../network/ports/vip.yaml*
> >      >                     *
> >      >                     *
> >      >                     What is your recommendation and how to disable
> >      >                     OVN....should I remove it from
> >     roles_data.yaml and
> >      >                     then render so that it doesn't get generated
> >      >                     in environments/network-isolation.yaml
> >      >                     Please suggest some pointers.
> >      >
> >      >                     Regards
> >      >                     Anirudh Gupta
> >      >                     *
> >      >                     *
> >      >                     *
> >      >                     *
> >      >
> >      >
> >      >
> >      >
> >      >                     It seems OVN is getting installed in ironic
> >      >
> >      >
> >      >                     On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger
> >      >                     <juliaashleykreger at gmail.com
> >     <mailto:juliaashleykreger at gmail.com>
> >      >                     <mailto:juliaashleykreger at gmail.com
> >     <mailto:juliaashleykreger at gmail.com>>> wrote:
> >      >
> >      >                         My guess: You're running OVN. You need
> >      >                         neutron-dhcp-agent running as well. OVN
> >     disables
> >      >                         it by default and OVN's integrated DHCP
> >     service
> >      >                         does not support options for network
> booting.
> >      >
> >      >                         -Julia
> >      >
> >      >                         On Thu, Feb 3, 2022 at 9:06 AM Anirudh
> Gupta
> >      >                         <anyrude10 at gmail.com
> >     <mailto:anyrude10 at gmail.com>
> >      >                         <mailto:anyrude10 at gmail.com
> >     <mailto:anyrude10 at gmail.com>>> wrote:
> >      >
> >      >                             Hi Team
> >      >
> >      >                             I am trying to Provision Bare Metal
> Node
> >      >                             from my tripleo Overcloud.
> >      >                             For this, while deploying the
> >     overcloud, I
> >      >                             have followed the *"default flat"
> >     *network
> >      >                             approach specified in the below link
> >      >
> >
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
> >     <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
> >
> >      >
> >       <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
> <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning
> >>
> >      >
> >      >                             Just to highlight the changes, I have
> >      >                             defined the
> >      >
> >      >                             *ironic-config.yaml*
> >      >
> >      >                             parameter_defaults:
> >      >                                  ...
> >      >                                  ...
> >      >                                  IronicIPXEEnabled: true
> >      >                                  IronicInspectorSubnets:
> >      >                                  - ip_range:
> >     *172.23.3.100,172.23.3.150*
> >      >                                  IronicInspectorInterface:
> >     'br-baremetal'
> >      >
> >      >                             Also modified the file
> >      >                             *~/templates/network-environment.yaml*
> >      >
> >      >                             parameter_defaults:
> >      >                                NeutronBridgeMappings:
> >      >
>  datacentre:br-ex,baremetal:br-baremetal
> >      >                                NeutronFlatNetworks:
> >     datacentre,baremetal
> >      >
> >      >                             With this I have Followed all the
> >     steps of
> >      >                             creating br-baremetal bridge on
> >     controller,
> >      >                             given in the link below:
> >      >
> >      >
> >
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
> >     <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
> >
> >      >
> >       <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
> <
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy
> >>
> >      >
> >      >                                - type: ovs_bridge
> >      >                                   name: br-baremetal
> >      >                                   use_dhcp: false
> >      >                                   members:
> >      >                                   - type: interface
> >      >                                     name: nic3
> >      >
> >      >                             Post Deployment, I have also create a
> >     flat
> >      >                             network on "datacentre"
> >     physical network and
> >      >                             subnet having the range
> >      >                             *172.23.3.200,172.23.3.240 *(as
> suggested
> >      >                             subnet is same as of inspector and
> >     range is
> >      >                             different) and the router
> >      >
> >      >                             Also created a baremetal node and ran
> >      >                             *"openstack baremetal node manage
> >     bm1", *the
> >      >                             state of which was a success.
> >      >
> >      >                             Observation:
> >      >
> >      >                             On executing "openstack baremetal node
> >      >                             *provide* bm1", the machine gets
> power on
> >      >                             and ideally it should take an IP from
> >     ironic
> >      >                             inspector range and PXE Boot.
> >      >                             But nothing of this sort happens and
> >     we see
> >      >                             an IP from neutron range
> "*172.23.3.239*"
> >      >                             (attached the screenshot)
> >      >
> >      >                             image.png
> >      >
> >      >                             I have checked overcloud ironic
> inspector
> >      >                             podman logs alongwith the tcpdump.
> >      >                             In tcpdump, I can only see dhcp
> discover
> >      >                             request on br-baremetal and nothing
> >     happens
> >      >                             after that.
> >      >
> >      >                             I have tried to explain my issue in
> >     detail,
> >      >                             but I would be happy to share more
> >     details
> >      >                             in case still required.
> >      >                             Can someone please help in resolving
> >     my issue.
> >      >
> >      >                             Regards
> >      >                             Anirudh Gupta
> >      >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/ff27859d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 265303 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/ff27859d/attachment-0001.png>

From lokendrarathour at gmail.com  Thu Feb 10 16:39:18 2022
From: lokendrarathour at gmail.com (Lokendra Rathour)
Date: Thu, 10 Feb 2022 22:09:18 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
 <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
 <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>
 <CAJm6b-4+z67on3D94k02m5yN79Yr91TdFyN=vntKmSQNBBK+pQ@mail.gmail.com>
 <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com>
Message-ID: <CAJm6b-6PYvKPW4AVd19uTmRk=j2Uw-Gh6fjNjDhBOvB0zyMGpg@mail.gmail.com>

Hi Harald,
Thanks for the response, please find my response inline:


On Thu, Feb 10, 2022 at 8:24 PM Harald Jensas <hjensas at redhat.com> wrote:

> On 2/10/22 14:49, Lokendra Rathour wrote:
> > Hi Harald,
> > Thanks once again for your support, we tried activating the parameters:
> > ServiceNetMap:
> >      IronicApiNetwork: provisioning
> >      IronicNetwork: provisioning
> > at environments/network-environments.yaml
> > image.png
> > After changing these values the updated or even the fresh deployments
> > are failing.
> >
>
> How did deployment fail?
>

[Loke] : it failed immediately after when the IP for ctlplane network is
assigned, and ssh is established and stack creation is completed, I think
at the start of ansible execution.

Error:
"enabling ssh admin - COMPLETE.
Host 10.0.1.94 not found in /home/stack/.ssh/known_hosts"
Although this message is even seen when the deployment is successful. so I
do not think this is the culprit.




> > The command that we are using to deploy the OpenStack overcloud:
> > /openstack overcloud deploy --templates \
> >      -n /home/stack/templates/network_data.yaml \
> >      -r /home/stack/templates/roles_data.yaml \
> >      -e /home/stack/templates/node-info.yaml \
> >      -e /home/stack/templates/environment.yaml \
> >      -e /home/stack/templates/environments/network-isolation.yaml \
> >      -e /home/stack/templates/environments/network-environment.yaml \
>
> What modifications did you do to network-isolation.yaml and

[Loke]:
*Network-isolation.yaml:*

# Enable the creation of Neutron networks for isolated Overcloud
# traffic and configure each role to assign ports (related
# to that role) on these networks.
resource_registry:
  # networks as defined in network_data.yaml
  OS::TripleO::Network::J3Mgmt: ../network/j3mgmt.yaml
  OS::TripleO::Network::Tenant: ../network/tenant.yaml
  OS::TripleO::Network::InternalApi: ../network/internal_api.yaml
  OS::TripleO::Network::External: ../network/external.yaml


  # Port assignments for the VIPs
  OS::TripleO::Network::Ports::J3MgmtVipPort: ../network/ports/j3mgmt.yaml


  OS::TripleO::Network::Ports::InternalApiVipPort:
../network/ports/internal_api.yaml
  OS::TripleO::Network::Ports::ExternalVipPort:
../network/ports/external.yaml


  OS::TripleO::Network::Ports::RedisVipPort: ../network/ports/vip.yaml
  OS::TripleO::Network::Ports::OVNDBsVipPort: ../network/ports/vip.yaml



  # Port assignments by role, edit role definition to assign networks to
roles.
  # Port assignments for the Controller
  OS::TripleO::Controller::Ports::J3MgmtPort: ../network/ports/j3mgmt.yaml
  OS::TripleO::Controller::Ports::TenantPort: ../network/ports/tenant.yaml
  OS::TripleO::Controller::Ports::InternalApiPort:
../network/ports/internal_api.yaml
  OS::TripleO::Controller::Ports::ExternalPort:
../network/ports/external.yaml
  # Port assignments for the Compute
  OS::TripleO::Compute::Ports::J3MgmtPort: ../network/ports/j3mgmt.yaml
  OS::TripleO::Compute::Ports::TenantPort: ../network/ports/tenant.yaml
  OS::TripleO::Compute::Ports::InternalApiPort:
../network/ports/internal_api.yaml

~


>
> network-environment.yaml?
>

resource_registry:
  # Network Interface templates to use (these files must exist). You can
  # override these by including one of the net-*.yaml environment files,
  # such as net-bond-with-vlans.yaml, or modifying the list here.
  # Port assignments for the Controller
  OS::TripleO::Controller::Net::SoftwareConfig:
    ../network/config/bond-with-vlans/controller.yaml
  # Port assignments for the Compute
  OS::TripleO::Compute::Net::SoftwareConfig:
    ../network/config/bond-with-vlans/compute.yaml
parameter_defaults:

  J3MgmtNetCidr: '80.0.1.0/24'
  J3MgmtAllocationPools: [{'start': '80.0.1.4', 'end': '80.0.1.250'}]
  J3MgmtNetworkVlanID: 400

  TenantNetCidr: '172.16.0.0/24'
  TenantAllocationPools: [{'start': '172.16.0.4', 'end': '172.16.0.250'}]
  TenantNetworkVlanID: 416
  TenantNetPhysnetMtu: 1500

  InternalApiNetCidr: '172.16.2.0/24'
  InternalApiAllocationPools: [{'start': '172.16.2.4', 'end':
'172.16.2.250'}]
  InternalApiNetworkVlanID: 418

  ExternalNetCidr: '10.0.1.0/24'
  ExternalAllocationPools: [{'start': '10.0.1.85', 'end': '10.0.1.98'}]
  ExternalNetworkVlanID: 408

  DnsServers: []
  NeutronNetworkType: 'geneve,vlan'
  NeutronNetworkVLANRanges: 'datacentre:1:1000'
  BondInterfaceOvsOptions: "bond_mode=active-backup"


>
> I typically use:
> -e
>
> /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
> -e
>
> /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml
> -e /home/stack/templates/environments/network-overrides.yaml
>
> The network-isolation.yaml and network-environment.yaml are Jinja2
> rendered based on the -n input, so too keep in sync with change in the
> `-n` file reference the file in
> /usr/share/opentack-tripleo-heat-templates. Then add overrides in
> network-overrides.yaml as neede.
>

[Loke] : we are using this as like only, I do not know what you pass in
network-overrides.yaml but I pass other files as per commands as below:

[stack at undercloud templates]$ cat environment.yaml
parameter_defaults:
  ControllerCount: 3
  TimeZone: 'Asia/Kolkata'
  NtpServer: ['30.30.30.3']
  NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
  NeutronFlatNetworks: datacentre,baremetal
[stack at undercloud templates]$ cat ironic-config.yaml
parameter_defaults:
    IronicEnabledHardwareTypes:
        - ipmi
        - redfish
    IronicEnabledPowerInterfaces:
        - ipmitool
        - redfish
    IronicEnabledManagementInterfaces:
        - ipmitool
        - redfish
    IronicCleaningDiskErase: metadata
    IronicIPXEEnabled: true
    IronicInspectorSubnets:
    - ip_range: 172.23.3.100,172.23.3.150
    IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel", "
http://30.30.30.1:8088/agent.ramdisk"]'
    IronicInspectorInterface: 'br-baremetal'
[stack at undercloud templates]$
[stack at undercloud templates]$ cat node-info.yaml
parameter_defaults:
  OvercloudControllerFlavor: control
  OvercloudComputeFlavor: compute
  ControllerCount: 3
  ComputeCount: 1
[stack at undercloud templates]$



>
> >      -e
> >
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>
> > \
> >      -e
> >
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>
> > \
> >      -e
> >
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>
> > \
> >      -e /home/stack/templates/ironic-config.yaml \
> >      -e
> > /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
> >      -e
> > /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
> >      -e /home/stack/containers-prepare-parameter.yaml/
> >
> > **/home/stack/templates/ironic-config.yaml :
> > (overcloud) [stack at undercloud ~]$ cat
> > /home/stack/templates/ironic-config.yaml
> > parameter_defaults:
> >      IronicEnabledHardwareTypes:
> >          - ipmi
> >          - redfish
> >      IronicEnabledPowerInterfaces:
> >          - ipmitool
> >          - redfish
> >      IronicEnabledManagementInterfaces:
> >          - ipmitool
> >          - redfish
> >      IronicCleaningDiskErase: metadata
> >      IronicIPXEEnabled: true
> >      IronicInspectorSubnets:
> >      - ip_range: 172.23.3.100,172.23.3.150
> >      IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel
> > <http://30.30.30.1:8088/agent.kernel>",
> > "http://30.30.30.1:8088/agent.ramdisk
> > <http://30.30.30.1:8088/agent.ramdisk>"] >
> IronicInspectorInterface: 'br-baremetal'
> >
> > Also the baremetal network(provisioning)(172.23.3.x)  is  routed with
> > ctlplane/admin network (30.30.30.x)
> >
>
> Unless the network you created in the overcloud is named `provisioning`,
> these parameters may be relevant.
>
> IronicCleaningNetwork:
>    default: 'provisioning'
>    description: Name or UUID of the *overcloud* network used for cleaning
>                 bare metal nodes. The default value of "provisioning" can
> be
>                 left during the initial deployment (when no networks are
>                 created yet) and should be changed to an actual UUID in
>                 a post-deployment stack update.
>    type: string
>
> IronicProvisioningNetwork:
>    default: 'provisioning'
>    description: Name or UUID of the *overcloud* network used for
> provisioning
>                 of bare metal nodes, if IronicDefaultNetworkInterface is
>                 set to "neutron". The default value of "provisioning" can
> be
>                 left during the initial deployment (when no networks are
>                 created yet) and should be changed to an actual UUID in
>                 a post-deployment stack update.
>    type: string
>
> IronicRescuingNetwork:
>    default: 'provisioning'
>    description: Name or UUID of the *overcloud* network used for resucing
>                 of bare metal nodes, if IronicDefaultRescueInterface is not
>                 set to "no-rescue". The default value of "provisioning"
> can be
>                 left during the initial deployment (when no networks are
>                 created yet) and should be changed to an actual UUID in
>                 a post-deployment stack update.
>    type: string
>
> > *Query:*
> >
> >  1. any other location/way where we should add these so that they are
> >     included without error.
> >
> >         *ServiceNetMap:*
> >
> >         *    IronicApiNetwork: provisioning*
> >
> >         *    IronicNetwork: provisioning*
> >
>
> `provisioning` network is defined in -n
> /home/stack/templates/network_data.yaml right?

[Loke]: No it does not have any entry for provisioning in this file, it is
network entry for J3Mgmt,Tenant,InternalApi, and External. These n/w's are
added as vlan based under the br-ext bridge.
provisioning network I am creating after the overcloud is deployed and
before the baremetal node is provisioned.
in the provisioning network, we are giving the range of the ironic network.
(172.23.3.x)




> And an entry in
> 'networks' for the controller role in
> /home/stack/templates/roles_data.yaml?
>
[Loke]: we also did not added a similar entry in the roles_data.yaml as
well.

Just to add with these two files we have rendered the remaining templates.




>
>
> >       2. Also are these commands(mentioned above) configure Baremetal
> >     services are fine.
> >
>
> Yes, what you are doing makes sense.
>
> I'm actually not sure why it did'nt work with your previous
> configuration, it got the information about NBP file and obviously
> attempted to download it from 30.30.30.220. With routing in place, that
> should work.
>
> Changeing the ServiceNetMap to move IronicNetwork services to the
> 172.23.3 would avoid the routing.
>
[Loke] : we can try this but are somehow not able to do so because of some
weird reasons.

>
>
> What is NeutronBridgeMappings?
>   br-baremetal maps to the physical network of the overcloud
> `provisioning` neutron network?
>


> [Loke] : yes , we create br-barmetal and then we create provisioning
> network mapping it to br-baremetal.
>
> Also attaching the complete rendered template folder along with custom
yaml files that I am using, maybe referring that you might have a more
clear picture of our problem.
Any clue would help.
Our problem,
we are not able to provision the baremetal node after the overcloud is
deployed.
Do we have any straight-forward documents using which we can test the
baremetal provision, please provide that.

Thanks once again for reading all these.




> --
> Harald
>
>

-
skype: lokendrarathour
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/130d13d4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: overcloud_baremetal.zip
Type: application/x-zip-compressed
Size: 128512 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/130d13d4/attachment-0001.bin>

From katonalala at gmail.com  Thu Feb 10 20:34:11 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 10 Feb 2022 21:34:11 +0100
Subject: [neutron] Drivers meeting - Friday 11.2.2022 - cancelled
Message-ID: <CALg0jKmKbXTBjhb1HsjzHo2nT2uMaPApk5ofa7djF=8p8U8Dhg@mail.gmail.com>

Hi Neutron Drivers!

Due to the lack of agenda, let's cancel tomorrow's drivers meeting.
See You on the meeting next week.

Lajos Katona (lajoskatona)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/ba8c9f70/attachment.htm>

From rlandy at redhat.com  Thu Feb 10 22:51:42 2022
From: rlandy at redhat.com (Ronelle Landy)
Date: Thu, 10 Feb 2022 17:51:42 -0500
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <76d16ee9-8dfc-246f-134f-162b20652c1f@redhat.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
 <CAGHQP9wJ0L3dqz1zCyP6RR4NriVifDB6OCasg9-=QtTqOBN1RQ@mail.gmail.com>
 <76d16ee9-8dfc-246f-134f-162b20652c1f@redhat.com>
Message-ID: <CANnyimN-C5nDbKNXOo4BJe4796h1KgkWWw4ojwzEgYpsNRj3wQ@mail.gmail.com>

+1

On Thu, Feb 10, 2022 at 11:11 AM Bogdan Dobrelya <bdobreli at redhat.com>
wrote:

> +1
>
> On 2/10/22 16:45, Sagi Shnaidman wrote:
> > +1
> >
> > On Thu, Feb 10, 2022 at 4:44 PM Jose Luis Franco Arza
> > <jfrancoa at redhat.com <mailto:jfrancoa at redhat.com>> wrote:
> >
> >     Hello folks,
> >
> >     I would like to propose Sergii Golovatiuk [1][2][3] as a core
> >     reviewer on the TripleO repositories related to the upgrades
> >     workflow (openstack/tripleo-heat-templates,
> >     openstack/tripleo-ansible, openstack/python-tripleoclient,
> >     openstack/tripleo-ci, openstack/tripleo-quickstart,
> >     openstack/tripleo-quickstart-extras). Sergii has been working in
> >     OpenStack for the last 10 years, he is already core-reviewer of
> >     thetripleo-upgrade
> >     <https://github.com/openstack/tripleo-upgrade>repository in which he
> >     is providing with very valuable feedback, as well as helping getting
> >     relevant patches merged.
> >
> >     His deep knowledge of the different OpenStack projects, as well as
> >     his involvement in the upgrades/updates workflows for the last 9
> >     OpenStack releases makes him a great code reviewer, being able to
> >     catch several issues during the code review process.
> >
> >     I will monitor the thread for a week and if no objections are
> >     exposed I will add him to the tripleo-core group.
> >
> >     PD: Here comes the +1 from my side.
> >
> >     Thanks.
> >
> >     Cheers,
> >     Jos? Luis
> >
> >     [1]:https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> >     <https://review.opendev.org/q/owner:sgolovat%2540redhat.com>
> >     [2]:
> >
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> >     <
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> >
> >     [3]: Position #25 in the most active TripleO contributors list
> >     <
> https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180
> >
> >
> >
> >
> > --
> > Best regards
> > Sagi Shnaidman
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220210/1a7a9582/attachment.htm>

From ramishra at redhat.com  Fri Feb 11 03:58:58 2022
From: ramishra at redhat.com (Rabi Mishra)
Date: Fri, 11 Feb 2022 09:28:58 +0530
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
Message-ID: <CABJHmF4_yWPfK4CuV-hTCgPv_EGSWeQGcKY2rjArJHdkbytJZg@mail.gmail.com>

+1

On Thu, Feb 10, 2022, 20:07 Jose Luis Franco Arza <jfrancoa at redhat.com>
wrote:

> Hello folks,
>
> I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer on
> the TripleO repositories related to the upgrades workflow
> (openstack/tripleo-heat-templates, openstack/tripleo-ansible,
> openstack/python-tripleoclient, openstack/tripleo-ci,
> openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii
> has been working in OpenStack for the last 10 years, he is already
> core-reviewer of the tripleo-upgrade
> <https://github.com/openstack/tripleo-upgrade>repository in which he is
> providing with very valuable feedback, as well as helping getting relevant
> patches merged.
>
> His deep knowledge of the different OpenStack projects, as well as his
> involvement in the upgrades/updates workflows for the last 9 OpenStack
> releases makes him a great code reviewer, being able to catch several
> issues during the code review process.
>
> I will monitor the thread for a week and if no objections are exposed I
> will add him to the tripleo-core group.
>
> PD: Here comes the +1 from my side.
>
> Thanks.
>
> Cheers,
> Jos? Luis
>
> [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> [2]:
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> [3]: Position #25 in the most active TripleO contributors list
> <https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/5ed6f1a1/attachment.htm>

From marios at redhat.com  Fri Feb 11 06:25:00 2022
From: marios at redhat.com (Marios Andreou)
Date: Fri, 11 Feb 2022 08:25:00 +0200
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
Message-ID: <CAM51kHU6YBo8Vs7w2R1A9Fq7Wcwpw_nhxtwNrLj8NOb3qBeBZg@mail.gmail.com>

+1


On Thu, Feb 10, 2022 at 4:40 PM Jose Luis Franco Arza
<jfrancoa at redhat.com> wrote:
>
> Hello folks,
>
> I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer on the TripleO repositories related to the upgrades workflow (openstack/tripleo-heat-templates, openstack/tripleo-ansible, openstack/python-tripleoclient, openstack/tripleo-ci, openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii has been working in OpenStack for the last 10 years, he is already core-reviewer of the tripleo-upgrade repository in which he is providing with very valuable feedback, as well as helping getting relevant patches merged.
>
> His deep knowledge of the different OpenStack projects, as well as his involvement in the upgrades/updates workflows for the last 9 OpenStack releases makes him a great code reviewer, being able to catch several issues during the code review process.
>
> I will monitor the thread for a week and if no objections are exposed I will add him to the tripleo-core group.
>
> PD: Here comes the +1 from my side.
>
> Thanks.
>
> Cheers,
> Jos? Luis
>
> [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> [2]: https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> [3]: Position #25 in the most active TripleO contributors list



From eblock at nde.ag  Fri Feb 11 10:35:32 2022
From: eblock at nde.ag (Eugen Block)
Date: Fri, 11 Feb 2022 10:35:32 +0000
Subject: nova rabbitmq strange bug
In-Reply-To: <CAPgF-fqsVbOT0Rdpd725-DKL+LMPmMQZ2fe4RbDkGzOXu6_uyA@mail.gmail.com>
Message-ID: <20220211103532.Horde.-qNZf0SqwPEuQdODYH3QSFn@webmail.nde.ag>

What do the rabbit logs reveal?


Zitat von Satish Patel <satish.txt at gmail.com>:

> Folks,
>
> I am running wallaby and Today i had rabbitMQ issue and i rebuild
> RabbitMQ. but now my all compute node throwing following error. not
> sure what is going on up they are not trying to come up and keep
> crashing with following error
>
>
> 2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> [req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b - - - - -] Error starting
> thread.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting
> for a reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> Traceback (most recent call last):
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 433, in get
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> return self._queues[msg_id].get(block=True, timeout=timeout)
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
> line 322, in get
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> return waiter.wait()
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
> line 141, in wait
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> return get_hub().switch()
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/hubs/hub.py",
> line 313, in switch
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> return self.greenlet.switch()
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> _queue.Empty
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service During
> handling of the above exception, another exception occurred:
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> Traceback (most recent call last):
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_service/service.py",
> line 807, in run_service
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> service.start()
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/service.py",
> line 159, in start
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> self.manager.init_host()
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/compute/manager.py",
> line 1413, in init_host
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> self.driver.init_host(host=self.host)
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
> line 792, in init_host
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> self._register_instance_machine_type()
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
> line 811, in _register_instance_machine_type
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service     for
> instance in objects.InstanceList.get_by_host(context, hostname):
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_versionedobjects/base.py",
> line 175, in wrapper
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> result = cls.indirection_api.object_class_action_versions(
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/conductor/rpcapi.py",
> line 240, in object_class_action_versions
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> return cctxt.call(context, 'object_class_action_versions',
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/rpc/client.py",
> line 175, in call
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> self.transport._send(self.target, msg_ctxt, msg,
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/transport.py",
> line 123, in _send
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> return self._driver.send(target, ctxt, message,
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 680, in send
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> return self._send(target, ctxt, message, wait_for_reply, timeout,
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 669, in _send
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> result = self._waiter.wait(msg_id, timeout,
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 559, in wait
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> message = self.waiters.get(msg_id, timeout=timeout)
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 435, in get
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> raise oslo_messaging.MessagingTimeout(
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a
> reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>
>    2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service





From fpantano at redhat.com  Fri Feb 11 10:43:19 2022
From: fpantano at redhat.com (Francesco Pantano)
Date: Fri, 11 Feb 2022 11:43:19 +0100
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
Message-ID: <CAJy1LSF8NvzYo+9bD7wcyUT5h_t_jqDK6hi3DyTn7d63d1prgw@mail.gmail.com>

+1

On Thu, Feb 10, 2022 at 3:43 PM Jose Luis Franco Arza <jfrancoa at redhat.com>
wrote:

> Hello folks,
>
> I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer on
> the TripleO repositories related to the upgrades workflow
> (openstack/tripleo-heat-templates, openstack/tripleo-ansible,
> openstack/python-tripleoclient, openstack/tripleo-ci,
> openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii
> has been working in OpenStack for the last 10 years, he is already
> core-reviewer of the tripleo-upgrade
> <https://github.com/openstack/tripleo-upgrade>repository in which he is
> providing with very valuable feedback, as well as helping getting relevant
> patches merged.
>
> His deep knowledge of the different OpenStack projects, as well as his
> involvement in the upgrades/updates workflows for the last 9 OpenStack
> releases makes him a great code reviewer, being able to catch several
> issues during the code review process.
>
> I will monitor the thread for a week and if no objections are exposed I
> will add him to the tripleo-core group.
>
> PD: Here comes the +1 from my side.
>
> Thanks.
>
> Cheers,
> Jos? Luis
>
> [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> [2]:
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> [3]: Position #25 in the most active TripleO contributors list
> <https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180>
>


-- 
Francesco Pantano
GPG KEY: F41BD75C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/027f3665/attachment.htm>

From anlin.kong at gmail.com  Fri Feb 11 11:16:14 2022
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Sat, 12 Feb 2022 00:16:14 +1300
Subject: [election][trove][ptl] PTL non-candidacy
Message-ID: <CALjNAZ1ddnPVhuFtoeRwQyqYE6iStSj29XpuqTN9a4D=1QSv5w@mail.gmail.com>

Hi all,

I'm writing this email to let you know that I'm not going to run for Trove
PTL for Z dev cycle.

I've been serving Trove PTL since Train, trying the best to revive the
project back to production ready, lots of changes have been made since
then, and also helped my former employer successfully deploy Trove in
production and pass the security review conducted by the 3rd party security
company.

However, I changed my job recently and shifted the focus, can't
guarantee the contribution for this open source project, hopefully someone
could pick that up and drive the project. I'm willing to provide help if
needed.

---
Lingxian Kong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220212/7f6ec696/attachment.htm>

From satish.txt at gmail.com  Fri Feb 11 12:58:45 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Fri, 11 Feb 2022 07:58:45 -0500
Subject: nova rabbitmq strange bug
In-Reply-To: <20220211103532.Horde.-qNZf0SqwPEuQdODYH3QSFn@webmail.nde.ag>
References: <20220211103532.Horde.-qNZf0SqwPEuQdODYH3QSFn@webmail.nde.ag>
Message-ID: <DAA2EF14-5C32-4572-AD4F-C5F2BFF025B2@gmail.com>

RabbitMQ logs are very clean and all info logging. It?s feel like something is broken between conductor and nova-compute. Compute is saying waiting for message ID. 

May be I rebuild rabbit during that time nova-conductor was keep trying to connect or doing something and when rabbit back then some message stuck in queue half way. I don?t know the flow so just making up some theory. 

All computes showing same logs but waiting for different message ID. Is nova-compute talk to conductor and wait for ack reply or not?  

Sent from my iPhone

> On Feb 11, 2022, at 5:39 AM, Eugen Block <eblock at nde.ag> wrote:
> 
> ?What do the rabbit logs reveal?
> 
> 
> Zitat von Satish Patel <satish.txt at gmail.com>:
> 
>> Folks,
>> 
>> I am running wallaby and Today i had rabbitMQ issue and i rebuild
>> RabbitMQ. but now my all compute node throwing following error. not
>> sure what is going on up they are not trying to come up and keep
>> crashing with following error
>> 
>> 
>> 2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> [req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b - - - - -] Error starting
>> thread.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting
>> for a reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> Traceback (most recent call last):
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 433, in get
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> return self._queues[msg_id].get(block=True, timeout=timeout)
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
>> line 322, in get
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> return waiter.wait()
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
>> line 141, in wait
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> return get_hub().switch()
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/hubs/hub.py",
>> line 313, in switch
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> return self.greenlet.switch()
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> _queue.Empty
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service During
>> handling of the above exception, another exception occurred:
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> Traceback (most recent call last):
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_service/service.py",
>> line 807, in run_service
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> service.start()
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/service.py",
>> line 159, in start
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> self.manager.init_host()
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/compute/manager.py",
>> line 1413, in init_host
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> self.driver.init_host(host=self.host)
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
>> line 792, in init_host
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> self._register_instance_machine_type()
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
>> line 811, in _register_instance_machine_type
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service     for
>> instance in objects.InstanceList.get_by_host(context, hostname):
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_versionedobjects/base.py",
>> line 175, in wrapper
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> result = cls.indirection_api.object_class_action_versions(
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/conductor/rpcapi.py",
>> line 240, in object_class_action_versions
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> return cctxt.call(context, 'object_class_action_versions',
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/rpc/client.py",
>> line 175, in call
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> self.transport._send(self.target, msg_ctxt, msg,
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/transport.py",
>> line 123, in _send
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> return self._driver.send(target, ctxt, message,
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 680, in send
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> return self._send(target, ctxt, message, wait_for_reply, timeout,
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 669, in _send
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> result = self._waiter.wait(msg_id, timeout,
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 559, in wait
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> message = self.waiters.get(msg_id, timeout=timeout)
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 435, in get
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> raise oslo_messaging.MessagingTimeout(
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>> oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a
>> reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>> 
>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
> 
> 
> 
> 


From rosmaita.fossdev at gmail.com  Fri Feb 11 13:14:40 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Fri, 11 Feb 2022 08:14:40 -0500
Subject: [cinder][nova][ironic][glance][downstream distro] raising
 requirements minima in yoga os-brick
Message-ID: <ecc700e1-5271-813b-350b-93bdef253afc@gmail.com>

Hello os-brick consumers,

I have a patch up raising the minima in {test-}requirements.txt for the 
yoga os-brick release.  I seem to remember that when I did this without 
warning last cycle, it caused a few issues (I think mostly a cascade of 
updates at an inconvenient time for people still maintaining 
lower-constraints.txt; probably nothing more serious because we're all 
testing in the gates with the latest versions allowed by 
upper-constraints anyway).

The commit message on the patch explains what changes are made (and some 
that aren't):
   https://review.opendev.org/c/openstack/os-brick/+/828802

Please respond before 18:00 UTC on Monday 14 Feb if you see any issues. 
(Sorry this email is a bit late, but that's how I roll.)


cheers,
brian


From eblock at nde.ag  Fri Feb 11 14:11:45 2022
From: eblock at nde.ag (Eugen Block)
Date: Fri, 11 Feb 2022 14:11:45 +0000
Subject: nova rabbitmq strange bug
In-Reply-To: <DAA2EF14-5C32-4572-AD4F-C5F2BFF025B2@gmail.com>
References: <20220211103532.Horde.-qNZf0SqwPEuQdODYH3QSFn@webmail.nde.ag>
 <DAA2EF14-5C32-4572-AD4F-C5F2BFF025B2@gmail.com>
Message-ID: <20220211141145.Horde.IKvAmCrL6OKIsbZyAjRGa8C@webmail.nde.ag>

So 'rabbitmqctl cluster_status' show the expected output? Can you  
trace back the request ID (req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b)  
and see if it was completed? Usually I see nova recovering after a  
rabbit outage, this would be unexpected. One more thing, you wrote  
you're seeing these messages today but you pasted messages from  
yesterday. Is nova still logging those messages?

Zitat von Satish Patel <satish.txt at gmail.com>:

> RabbitMQ logs are very clean and all info logging. It?s feel like  
> something is broken between conductor and nova-compute. Compute is  
> saying waiting for message ID.
>
> May be I rebuild rabbit during that time nova-conductor was keep  
> trying to connect or doing something and when rabbit back then some  
> message stuck in queue half way. I don?t know the flow so just  
> making up some theory.
>
> All computes showing same logs but waiting for different message ID.  
> Is nova-compute talk to conductor and wait for ack reply or not?
>
> Sent from my iPhone
>
>> On Feb 11, 2022, at 5:39 AM, Eugen Block <eblock at nde.ag> wrote:
>>
>> ?What do the rabbit logs reveal?
>>
>>
>> Zitat von Satish Patel <satish.txt at gmail.com>:
>>
>>> Folks,
>>>
>>> I am running wallaby and Today i had rabbitMQ issue and i rebuild
>>> RabbitMQ. but now my all compute node throwing following error. not
>>> sure what is going on up they are not trying to come up and keep
>>> crashing with following error
>>>
>>>
>>> 2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> [req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b - - - - -] Error starting
>>> thread.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting
>>> for a reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> Traceback (most recent call last):
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>> line 433, in get
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> return self._queues[msg_id].get(block=True, timeout=timeout)
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
>>> line 322, in get
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> return waiter.wait()
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
>>> line 141, in wait
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> return get_hub().switch()
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/hubs/hub.py",
>>> line 313, in switch
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> return self.greenlet.switch()
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> _queue.Empty
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service During
>>> handling of the above exception, another exception occurred:
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> Traceback (most recent call last):
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_service/service.py",
>>> line 807, in run_service
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> service.start()
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/service.py",
>>> line 159, in start
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> self.manager.init_host()
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/compute/manager.py",
>>> line 1413, in init_host
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> self.driver.init_host(host=self.host)
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
>>> line 792, in init_host
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> self._register_instance_machine_type()
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
>>> line 811, in _register_instance_machine_type
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service     for
>>> instance in objects.InstanceList.get_by_host(context, hostname):
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_versionedobjects/base.py",
>>> line 175, in wrapper
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> result = cls.indirection_api.object_class_action_versions(
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/conductor/rpcapi.py",
>>> line 240, in object_class_action_versions
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> return cctxt.call(context, 'object_class_action_versions',
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/rpc/client.py",
>>> line 175, in call
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> self.transport._send(self.target, msg_ctxt, msg,
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/transport.py",
>>> line 123, in _send
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> return self._driver.send(target, ctxt, message,
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>> line 680, in send
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> return self._send(target, ctxt, message, wait_for_reply, timeout,
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>> line 669, in _send
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> result = self._waiter.wait(msg_id, timeout,
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>> line 559, in wait
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> message = self.waiters.get(msg_id, timeout=timeout)
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>> line 435, in get
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> raise oslo_messaging.MessagingTimeout(
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a
>>> reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>>>
>>>   2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>
>>
>>
>>





From lokendrarathour at gmail.com  Fri Feb 11 13:59:06 2022
From: lokendrarathour at gmail.com (Lokendra Rathour)
Date: Fri, 11 Feb 2022 19:29:06 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAJm6b-6PYvKPW4AVd19uTmRk=j2Uw-Gh6fjNjDhBOvB0zyMGpg@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
 <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
 <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>
 <CAJm6b-4+z67on3D94k02m5yN79Yr91TdFyN=vntKmSQNBBK+pQ@mail.gmail.com>
 <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com>
 <CAJm6b-6PYvKPW4AVd19uTmRk=j2Uw-Gh6fjNjDhBOvB0zyMGpg@mail.gmail.com>
Message-ID: <CAJm6b-5+6=sWB2yXf8-mToBKdA53paSxRiP0WQ9Bqi+Dfnn84w@mail.gmail.com>

Hi Harald/ Openstack Team,
Thank you again for your support.

we have successfully provisioned the baremetal node as per the inputs
shared by you. The only change that we did was to add an entry for the
ServiceNetmap.

Further, we were trying to launch the baremetal node instance  in which we
are facing ISSUE as mentioned below:

[image: image.png]

*"2022-02-11 18:13:45.840 7 ERROR nova.compute.manager
[req-aafdea4d-815f-4504-b7d7-4fd95d1e083e - - - - -] Error updating
resources for node 9560bc2d-5f94-4ba0-9711-340cb8ad7d8a.:
nova.exception.NoResourceClass: Resource class not found for Ironic node
9560bc2d-5f94-4ba0-9711-340cb8ad7d8a.*

*2022-02-11 18:13:45.840 7 ERROR nova.compute.manager Traceback (most
recent call last):2022-02-11 18:13:45.840 7 ERROR nova.compute.manager
File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 8894,
in _update_available_resource_for_node*
"
for your reference please refer following details:
(overcloud) [stack at undercloud v4]$ openstack baremetal node show
baremetal-node --fit-width
+------------------------+-------------------------------------------------------------------------------------------------------------------+
| Field                  | Value
                                                                  |
+------------------------+-------------------------------------------------------------------------------------------------------------------+
| allocation_uuid        | None
                                                                 |
| automated_clean        | None
                                                                 |
| bios_interface         | no-bios
                                                                  |
| boot_interface         | ipxe
                                                                 |
| chassis_uuid           | None
                                                                 |
| clean_step             | {}
                                                                 |
| conductor              | overcloud-controller-0.localdomain
                                                                 |
| conductor_group        |
                                                                  |
| console_enabled        | False
                                                                  |
| console_interface      | ipmitool-socat
                                                                 |
| created_at             | 2022-02-11T13:02:40+00:00
                                                                  |
| deploy_interface       | iscsi
                                                                  |
| deploy_step            | {}
                                                                 |
| description            | None
                                                                 |
| driver                 | ipmi
                                                                 |
| driver_info            | {'ipmi_port': 623, 'ipmi_username': 'hsc',
'ipmi_password': '******', 'ipmi_address': '10.0.1.183',               |
|                        | 'deploy_kernel':
'bc62f3dc-d091-4dbd-b730-cf7b6cb48625', 'deploy_ramdisk':
                     |
|                        | 'd58bcc08-cb7c-4f21-8158-0a5ed4198108'}
                                                                  |
| driver_internal_info   | {'agent_erase_devices_iterations': 1,
'agent_erase_devices_zeroize': True, 'agent_continue_if_ata_erase_failed':
 |
|                        | False, 'agent_enable_ata_secure_erase': True,
'disk_erasure_concurrency': 1, 'last_power_state_change':           |
|                        | '2022-02-11T13:14:29.581361', 'agent_version':
'5.0.5.dev25', 'agent_last_heartbeat':                             |
|                        | '2022-02-11T13:14:24.151928',
'hardware_manager_version': {'generic_hardware_manager': '1.1'},
         |
|                        | 'agent_cached_clean_steps': {'deploy': [{'step':
'erase_devices', 'priority': 10, 'interface': 'deploy',          |
|                        | 'reboot_requested': False, 'abortable': True},
{'step': 'erase_devices_metadata', 'priority': 99, 'interface':    |
|                        | 'deploy', 'reboot_requested': False,
'abortable': True}], 'raid': [{'step': 'delete_configuration', 'priority':
  |
|                        | 0, 'interface': 'raid', 'reboot_requested':
False, 'abortable': True}, {'step': 'create_configuration',           |
|                        | 'priority': 0, 'interface': 'raid',
'reboot_requested': False, 'abortable': True}]},
   |
|                        | 'agent_cached_clean_steps_refreshed':
'2022-02-11 13:14:22.580729', 'clean_steps': None}
 |
| extra                  | {}
                                                                 |
| fault                  | None
                                                                 |
| inspect_interface      | inspector
                                                                  |
| inspection_finished_at | None
                                                                 |
| inspection_started_at  | None
                                                                 |
| instance_info          | {}
                                                                 |
| instance_uuid          | None
                                                                 |
| last_error             | None
                                                                 |
| maintenance            | False
                                                                  |
| maintenance_reason     | None
                                                                 |
| management_interface   | ipmitool
                                                                 |
| name                   | baremetal-node
                                                                 |
| network_interface      | flat
                                                                 |
| owner                  | None
                                                                 |
| power_interface        | ipmitool
                                                                 |
| power_state            | power off
                                                                  |

*| properties             | {'cpus': 20, 'memory_mb': 63700, 'local_gb':
470, 'cpu_arch': 'x86_64', 'capabilities':                           ||
                   | 'boot_option:local,boot_mode:uefi', 'vendor':
'hewlett-packard'}     *                                             |
| protected              | False
                                                                  |
| protected_reason       | None
                                                                 |
| provision_state        | available
                                                                  |
| provision_updated_at   | 2022-02-11T13:14:51+00:00
                                                                  |
| raid_config            | {}
                                                                 |
| raid_interface         | no-raid
                                                                  |
| rescue_interface       | agent
                                                                  |
| reservation            | None
                                                                 |
*| resource_class         | baremetal-resource-class  *
                                                                   |
| storage_interface      | noop
                                                                 |
| target_power_state     | None
                                                                 |
| target_provision_state | None
                                                                 |
| target_raid_config     | {}
                                                                 |
| traits                 | []
                                                                 |
| updated_at             | 2022-02-11T13:14:52+00:00
                                                                  |
| uuid                   | e64ad28c-43d6-4b9f-aa34-f8bc58e9e8fe
                                                                 |
| vendor_interface       | ipmitool
                                                                 |
+------------------------+-------------------------------------------------------------------------------------------------------------------+
(overcloud) [stack at undercloud v4]$




(overcloud) [stack at undercloud v4]$ openstack flavor show
my-baremetal-flavor --fit-width
+----------------------------+---------------------------------------------------------------------------------------------------------------+
| Field                      | Value
                                                                  |
+----------------------------+---------------------------------------------------------------------------------------------------------------+
| OS-FLV-DISABLED:disabled   | False
                                                                  |
| OS-FLV-EXT-DATA:ephemeral  | 0
                                                                  |
| access_project_ids         | None
                                                                 |
| description                | None
                                                                 |
| disk                       | 470
                                                                  |

*| extra_specs                |
{'resources:CUSTOM_BAREMETAL_RESOURCE_CLASS': '1', 'resources:VCPU': '0',
'resources:MEMORY_MB': '0',         ||                            |
'resources:DISK_GB': '0', 'capabilities:boot_option':
'local,boot_mode:uefi'} *                                |
| id                         | 66a13404-4c47-4b67-b954-e3df42ae8103
                                                                 |
| name                       | my-baremetal-flavor
                                                                  |
| os-flavor-access:is_public | True
                                                                 |

*| properties                 |
capabilities:boot_option='local,boot_mode:uefi',
resources:CUSTOM_BAREMETAL_RESOURCE_CLASS='1',               ||
               | resources:DISK_GB='0', resources:MEMORY_MB='0',
resources:VCPU='0'    *                                        |
| ram                        | 63700
                                                                  |
| rxtx_factor                | 1.0
                                                                  |
| swap                       | 0
                                                                  |
| vcpus                      | 20
                                                                 |
+----------------------------+---------------------------------------------------------------------------------------------------------------+
(overcloud) [stack at undercloud v4]$

Can you please check and suggest if something is missing.

Thanks once again for your support.

-Lokendra




On Thu, Feb 10, 2022 at 10:09 PM Lokendra Rathour <lokendrarathour at gmail.com>
wrote:

> Hi Harald,
> Thanks for the response, please find my response inline:
>
>
> On Thu, Feb 10, 2022 at 8:24 PM Harald Jensas <hjensas at redhat.com> wrote:
>
>> On 2/10/22 14:49, Lokendra Rathour wrote:
>> > Hi Harald,
>> > Thanks once again for your support, we tried activating the parameters:
>> > ServiceNetMap:
>> >      IronicApiNetwork: provisioning
>> >      IronicNetwork: provisioning
>> > at environments/network-environments.yaml
>> > image.png
>> > After changing these values the updated or even the fresh deployments
>> > are failing.
>> >
>>
>> How did deployment fail?
>>
>
> [Loke] : it failed immediately after when the IP for ctlplane network is
> assigned, and ssh is established and stack creation is completed, I think
> at the start of ansible execution.
>
> Error:
> "enabling ssh admin - COMPLETE.
> Host 10.0.1.94 not found in /home/stack/.ssh/known_hosts"
> Although this message is even seen when the deployment is successful. so I
> do not think this is the culprit.
>
>
>
>
>> > The command that we are using to deploy the OpenStack overcloud:
>> > /openstack overcloud deploy --templates \
>> >      -n /home/stack/templates/network_data.yaml \
>> >      -r /home/stack/templates/roles_data.yaml \
>> >      -e /home/stack/templates/node-info.yaml \
>> >      -e /home/stack/templates/environment.yaml \
>> >      -e /home/stack/templates/environments/network-isolation.yaml \
>> >      -e /home/stack/templates/environments/network-environment.yaml \
>>
>> What modifications did you do to network-isolation.yaml and
>
> [Loke]:
> *Network-isolation.yaml:*
>
> # Enable the creation of Neutron networks for isolated Overcloud
> # traffic and configure each role to assign ports (related
> # to that role) on these networks.
> resource_registry:
>   # networks as defined in network_data.yaml
>   OS::TripleO::Network::J3Mgmt: ../network/j3mgmt.yaml
>   OS::TripleO::Network::Tenant: ../network/tenant.yaml
>   OS::TripleO::Network::InternalApi: ../network/internal_api.yaml
>   OS::TripleO::Network::External: ../network/external.yaml
>
>
>   # Port assignments for the VIPs
>   OS::TripleO::Network::Ports::J3MgmtVipPort: ../network/ports/j3mgmt.yaml
>
>
>   OS::TripleO::Network::Ports::InternalApiVipPort:
> ../network/ports/internal_api.yaml
>   OS::TripleO::Network::Ports::ExternalVipPort:
> ../network/ports/external.yaml
>
>
>   OS::TripleO::Network::Ports::RedisVipPort: ../network/ports/vip.yaml
>   OS::TripleO::Network::Ports::OVNDBsVipPort: ../network/ports/vip.yaml
>
>
>
>   # Port assignments by role, edit role definition to assign networks to
> roles.
>   # Port assignments for the Controller
>   OS::TripleO::Controller::Ports::J3MgmtPort: ../network/ports/j3mgmt.yaml
>   OS::TripleO::Controller::Ports::TenantPort: ../network/ports/tenant.yaml
>   OS::TripleO::Controller::Ports::InternalApiPort:
> ../network/ports/internal_api.yaml
>   OS::TripleO::Controller::Ports::ExternalPort:
> ../network/ports/external.yaml
>   # Port assignments for the Compute
>   OS::TripleO::Compute::Ports::J3MgmtPort: ../network/ports/j3mgmt.yaml
>   OS::TripleO::Compute::Ports::TenantPort: ../network/ports/tenant.yaml
>   OS::TripleO::Compute::Ports::InternalApiPort:
> ../network/ports/internal_api.yaml
>
> ~
>
>
>>
>> network-environment.yaml?
>>
>
> resource_registry:
>   # Network Interface templates to use (these files must exist). You can
>   # override these by including one of the net-*.yaml environment files,
>   # such as net-bond-with-vlans.yaml, or modifying the list here.
>   # Port assignments for the Controller
>   OS::TripleO::Controller::Net::SoftwareConfig:
>     ../network/config/bond-with-vlans/controller.yaml
>   # Port assignments for the Compute
>   OS::TripleO::Compute::Net::SoftwareConfig:
>     ../network/config/bond-with-vlans/compute.yaml
> parameter_defaults:
>
>   J3MgmtNetCidr: '80.0.1.0/24'
>   J3MgmtAllocationPools: [{'start': '80.0.1.4', 'end': '80.0.1.250'}]
>   J3MgmtNetworkVlanID: 400
>
>   TenantNetCidr: '172.16.0.0/24'
>   TenantAllocationPools: [{'start': '172.16.0.4', 'end': '172.16.0.250'}]
>   TenantNetworkVlanID: 416
>   TenantNetPhysnetMtu: 1500
>
>   InternalApiNetCidr: '172.16.2.0/24'
>   InternalApiAllocationPools: [{'start': '172.16.2.4', 'end':
> '172.16.2.250'}]
>   InternalApiNetworkVlanID: 418
>
>   ExternalNetCidr: '10.0.1.0/24'
>   ExternalAllocationPools: [{'start': '10.0.1.85', 'end': '10.0.1.98'}]
>   ExternalNetworkVlanID: 408
>
>   DnsServers: []
>   NeutronNetworkType: 'geneve,vlan'
>   NeutronNetworkVLANRanges: 'datacentre:1:1000'
>   BondInterfaceOvsOptions: "bond_mode=active-backup"
>
>
>>
>> I typically use:
>> -e
>>
>> /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
>> -e
>>
>> /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml
>> -e /home/stack/templates/environments/network-overrides.yaml
>>
>> The network-isolation.yaml and network-environment.yaml are Jinja2
>> rendered based on the -n input, so too keep in sync with change in the
>> `-n` file reference the file in
>> /usr/share/opentack-tripleo-heat-templates. Then add overrides in
>> network-overrides.yaml as neede.
>>
>
> [Loke] : we are using this as like only, I do not know what you pass in
> network-overrides.yaml but I pass other files as per commands as below:
>
> [stack at undercloud templates]$ cat environment.yaml
> parameter_defaults:
>   ControllerCount: 3
>   TimeZone: 'Asia/Kolkata'
>   NtpServer: ['30.30.30.3']
>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>   NeutronFlatNetworks: datacentre,baremetal
> [stack at undercloud templates]$ cat ironic-config.yaml
> parameter_defaults:
>     IronicEnabledHardwareTypes:
>         - ipmi
>         - redfish
>     IronicEnabledPowerInterfaces:
>         - ipmitool
>         - redfish
>     IronicEnabledManagementInterfaces:
>         - ipmitool
>         - redfish
>     IronicCleaningDiskErase: metadata
>     IronicIPXEEnabled: true
>     IronicInspectorSubnets:
>     - ip_range: 172.23.3.100,172.23.3.150
>     IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel", "
> http://30.30.30.1:8088/agent.ramdisk"]'
>     IronicInspectorInterface: 'br-baremetal'
> [stack at undercloud templates]$
> [stack at undercloud templates]$ cat node-info.yaml
> parameter_defaults:
>   OvercloudControllerFlavor: control
>   OvercloudComputeFlavor: compute
>   ControllerCount: 3
>   ComputeCount: 1
> [stack at undercloud templates]$
>
>
>
>>
>> >      -e
>> >
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>>
>> > \
>> >      -e
>> >
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>>
>> > \
>> >      -e
>> >
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>>
>> > \
>> >      -e /home/stack/templates/ironic-config.yaml \
>> >      -e
>> > /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
>> \
>> >      -e
>> > /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>> >      -e /home/stack/containers-prepare-parameter.yaml/
>> >
>> > **/home/stack/templates/ironic-config.yaml :
>> > (overcloud) [stack at undercloud ~]$ cat
>> > /home/stack/templates/ironic-config.yaml
>> > parameter_defaults:
>> >      IronicEnabledHardwareTypes:
>> >          - ipmi
>> >          - redfish
>> >      IronicEnabledPowerInterfaces:
>> >          - ipmitool
>> >          - redfish
>> >      IronicEnabledManagementInterfaces:
>> >          - ipmitool
>> >          - redfish
>> >      IronicCleaningDiskErase: metadata
>> >      IronicIPXEEnabled: true
>> >      IronicInspectorSubnets:
>> >      - ip_range: 172.23.3.100,172.23.3.150
>> >      IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel
>> > <http://30.30.30.1:8088/agent.kernel>",
>> > "http://30.30.30.1:8088/agent.ramdisk
>> > <http://30.30.30.1:8088/agent.ramdisk>"] >
>> IronicInspectorInterface: 'br-baremetal'
>> >
>> > Also the baremetal network(provisioning)(172.23.3.x)  is  routed with
>> > ctlplane/admin network (30.30.30.x)
>> >
>>
>> Unless the network you created in the overcloud is named `provisioning`,
>> these parameters may be relevant.
>>
>> IronicCleaningNetwork:
>>    default: 'provisioning'
>>    description: Name or UUID of the *overcloud* network used for cleaning
>>                 bare metal nodes. The default value of "provisioning" can
>> be
>>                 left during the initial deployment (when no networks are
>>                 created yet) and should be changed to an actual UUID in
>>                 a post-deployment stack update.
>>    type: string
>>
>> IronicProvisioningNetwork:
>>    default: 'provisioning'
>>    description: Name or UUID of the *overcloud* network used for
>> provisioning
>>                 of bare metal nodes, if IronicDefaultNetworkInterface is
>>                 set to "neutron". The default value of "provisioning" can
>> be
>>                 left during the initial deployment (when no networks are
>>                 created yet) and should be changed to an actual UUID in
>>                 a post-deployment stack update.
>>    type: string
>>
>> IronicRescuingNetwork:
>>    default: 'provisioning'
>>    description: Name or UUID of the *overcloud* network used for resucing
>>                 of bare metal nodes, if IronicDefaultRescueInterface is
>> not
>>                 set to "no-rescue". The default value of "provisioning"
>> can be
>>                 left during the initial deployment (when no networks are
>>                 created yet) and should be changed to an actual UUID in
>>                 a post-deployment stack update.
>>    type: string
>>
>> > *Query:*
>> >
>> >  1. any other location/way where we should add these so that they are
>> >     included without error.
>> >
>> >         *ServiceNetMap:*
>> >
>> >         *    IronicApiNetwork: provisioning*
>> >
>> >         *    IronicNetwork: provisioning*
>> >
>>
>> `provisioning` network is defined in -n
>> /home/stack/templates/network_data.yaml right?
>
> [Loke]: No it does not have any entry for provisioning in this file, it is
> network entry for J3Mgmt,Tenant,InternalApi, and External. These n/w's are
> added as vlan based under the br-ext bridge.
> provisioning network I am creating after the overcloud is deployed and
> before the baremetal node is provisioned.
> in the provisioning network, we are giving the range of the ironic
> network. (172.23.3.x)
>
>
>
>
>> And an entry in
>> 'networks' for the controller role in
>> /home/stack/templates/roles_data.yaml?
>>
> [Loke]: we also did not added a similar entry in the roles_data.yaml as
> well.
>
> Just to add with these two files we have rendered the remaining templates.
>
>
>
>
>>
>>
>> >       2. Also are these commands(mentioned above) configure Baremetal
>> >     services are fine.
>> >
>>
>> Yes, what you are doing makes sense.
>>
>> I'm actually not sure why it did'nt work with your previous
>> configuration, it got the information about NBP file and obviously
>> attempted to download it from 30.30.30.220. With routing in place, that
>> should work.
>>
>> Changeing the ServiceNetMap to move IronicNetwork services to the
>> 172.23.3 would avoid the routing.
>>
> [Loke] : we can try this but are somehow not able to do so because of some
> weird reasons.
>
>>
>>
>> What is NeutronBridgeMappings?
>>   br-baremetal maps to the physical network of the overcloud
>> `provisioning` neutron network?
>>
>
>
>> [Loke] : yes , we create br-barmetal and then we create provisioning
>> network mapping it to br-baremetal.
>>
>> Also attaching the complete rendered template folder along with custom
> yaml files that I am using, maybe referring that you might have a more
> clear picture of our problem.
> Any clue would help.
> Our problem,
> we are not able to provision the baremetal node after the overcloud is
> deployed.
> Do we have any straight-forward documents using which we can test the
> baremetal provision, please provide that.
>
> Thanks once again for reading all these.
>
>
>
>
>> --
>> Harald
>>
>>
>
> -
> skype: lokendrarathour
>
>
>

--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/956a41a9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 173439 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/956a41a9/attachment-0001.png>

From sbauza at redhat.com  Fri Feb 11 14:55:09 2022
From: sbauza at redhat.com (Sylvain Bauza)
Date: Fri, 11 Feb 2022 15:55:09 +0100
Subject: [election][nova] Sylvain to throw his hat into the Nova PTL ring again
Message-ID: <CALOCmukMMqvcM1DwCEYMQqsB5FhNost7CP7dHBx28xZWeKqhrg@mail.gmail.com>

Hello again Nova (and Placement) fellows,

This went fast, but it's time for me to run again for the Nova PTL position,
this time for the Zen/Zombie/Zeta [1] release cycle, after having been the
PTL
for the Yoga cycle.

Just a quick look at this current cycle. First, it was quick but :

 - we added a new way to help contributors to say they are reviewing some
   change
 - we now have a new nova-core
 - we have around 25 accepted feature requests and 15 of them are already
   reviewed.


What we had't yet time to discuss and what I'd like us to start to look are
:

 - given some operators want to upgrade at least every year, we should try
   to start seeing how to support two-cycle-older computes

 - sometimes we want to do things that we'd like but that we don't have
   time for. Some of them are actually simple to implement. Maybe then
   we should organize back ways to share ideas to new contributors and
   provide them mentoring efforts (eg. with Outreachy or any engineering
   interns wanting to work on OpenStack and Nova in particular)

As you know, I'm also open to any idea. I'm not a leader, I'm just a herder.

Thanks,
-Sylvain

[1] Pick any Z name you want given we don't know yet the result.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/f7218146/attachment.htm>

From elod.illes at est.tech  Fri Feb 11 15:34:04 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Fri, 11 Feb 2022 16:34:04 +0100
Subject: [release] Release countdown for week R-6, Feb 14-18
Message-ID: <8380854a-7843-94cc-8f4d-ad8a7c4eb5ba@est.tech>

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

Work on libraries should be wrapping up, in preparation for the various
library-related deadlines coming up. Now is a good time to make decisions
on deferring feature work to the next development cycle in order to be
able to focus on finishing already-started feature work.

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

We are now getting close to the end of the cycle, and will be gradually
freezing feature work on the various deliverables that make up the
OpenStack release.

This coming week is the deadline for general libraries (except client
libraries): their last feature release needs to happen before "Non-client
library freeze" on February 17th, 2022. Only bugfixes releases will be 
allowed
beyond this point.

When requesting those library releases, you can also include the
stable/yogabranching request with the review (as an example, see the
"branches" section here:
https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/os-brick.yaml#n2

In the next weeks we will have deadlines for:

* Client libraries (think python-*client libraries), which need to have
their last feature release before "Client library freeze" (February 
24th, 2022)

* Deliverables following a cycle-with-rc model (that would be most
services), which observe a Feature freeze on that same date, February 
24th, 2022.
Any feature addition beyond that date should be discussed on the
mailing-list and get PTL approval.

As we are getting to the point of creating stable/yogabranches, this
would be a good point for teams to review membership in their
$project-stable-maint groups. Once the stable/yogabranches are cut
for a repo, the ability to approve any necessary backports into those
branches for Yogawill be limited to the members of that stable team.
If there are any questions about stable policy or stable team membership,
please reach out in the #openstack-stable channel.

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

Non-client library freeze: February 17th, 2022(R-6 week)
Client library freeze: February 24th, 2022(R-5 week)
Yoga-3 milestone: February 24th, 2022(R-5 week)
Cycle Highlights Due: February 24th, 2022(R-5 week)
Yogafinal release: March 30th, 2022
Next PTG: April 4 - 8, 2022 (virtual)



El?dIll?s
irc: elodilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/20145869/attachment-0001.htm>

From DHilsbos at performair.com  Fri Feb 11 18:16:26 2022
From: DHilsbos at performair.com (DHilsbos at performair.com)
Date: Fri, 11 Feb 2022 18:16:26 +0000
Subject: OpenStack Trove experimental datastores
In-Reply-To: <10DE5E61-5A25-49FB-88D7-D918823EF53A@gmail.com>
References: <10DE5E61-5A25-49FB-88D7-D918823EF53A@gmail.com>
Message-ID: <0670B960225633449A24709C291A525251E7C31C@COM03.performair.local>

In Victoria, Trove moved to Docker images for the datastores.  Any datastores that didn't update themselves were removed, regardless of state.  I believe the only datastores currently supported are MariaDB, and PostgreSQL, though MySQL might be supported as well.

Personally. I find this to have been a bad example of the "containerize all the things" mentality.  Trove now deploys an instance (vm) for each datastore instance, running a single container.  The exception is if you request backups, in which case a backup container is added to the instance (vm).

Trove is installed in our OpenStack cloud, but we don't use it.

Thank you,

Dominic L. Hilsbos, MBA
Vice President - Information Technology
Perform Air International Inc.
DHilsbos at PerformAir.com
www.PerformAir.com


From: ????? ?????? [mailto:rishat.azizov at gmail.com] 
Sent: Sunday, February 6, 2022 11:10 AM
To: openstack-discuss at lists.openstack.org
Subject: OpenStack Trove experimental datastores

Hello!

Why were the experimental datastores removed in the Trove OpenStack Victoria release??https://review.opendev.org/c/openstack/trove/+/728419

Thanks!


From fernandoperches at gmail.com  Fri Feb 11 18:59:11 2022
From: fernandoperches at gmail.com (Fernando Ferraz)
Date: Fri, 11 Feb 2022 15:59:11 -0300
Subject: [Manila] Yoga Collab reviews
Message-ID: <CAGO9e9tCju9N00Y97hwBMqKOA-iyM16dSD73qMNwMwFvxiDdyw@mail.gmail.com>

Hi Team,

Would like to invite you to our collaborative review session occurring next
Monday and Thursday (Feb. 14tth and 17th). Following our proposals targeted
to the Yoga cycle, all patches partially implement the release independent
spec "*Add spec for multiple subnet share servers" *[1].

*February 14th (16:00-17:30 UTC):*

   - 825110: Add multiple subnets per AZ support
   https://review.opendev.org/c/openstack/manila/+/825110

*February 17th (16:00-17:30 UTC):*

   - 825155: NetApp ONTAP: Add support to multiple subnets per AZ
   https://review.opendev.org/c/openstack/manila/+/825155
   - 826462: Container: Multiple subnets per AZ
   https://review.opendev.org/c/openstack/manila/+/826462


[1] https://review.opendev.org/c/openstack/manila-specs/+/619925

Regards,
Fernando
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/648c7754/attachment.htm>

From gouthampravi at gmail.com  Fri Feb 11 19:27:26 2022
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Fri, 11 Feb 2022 11:27:26 -0800
Subject: [Manila] Yoga Collab reviews
In-Reply-To: <CAGO9e9tCju9N00Y97hwBMqKOA-iyM16dSD73qMNwMwFvxiDdyw@mail.gmail.com>
References: <CAGO9e9tCju9N00Y97hwBMqKOA-iyM16dSD73qMNwMwFvxiDdyw@mail.gmail.com>
Message-ID: <CAKSuTPZ8fpejw-LuNYxkVQwt_MDk8DJFEegYNK7+g76eQZ2QoA@mail.gmail.com>

On Fri, Feb 11, 2022 at 11:06 AM Fernando Ferraz
<fernandoperches at gmail.com> wrote:
>
> Hi Team,
>
> Would like to invite you to our collaborative review session occurring next Monday and Thursday (Feb. 14tth and 17th). Following our proposals targeted to the Yoga cycle, all patches partially implement the release independent spec "Add spec for multiple subnet share servers" [1].
>
> February 14th (16:00-17:30 UTC):
>
> 825110: Add multiple subnets per AZ support https://review.opendev.org/c/openstack/manila/+/825110
>
> February 17th (16:00-17:30 UTC):
>
> 825155: NetApp ONTAP: Add support to multiple subnets per AZ https://review.opendev.org/c/openstack/manila/+/825155
> 826462: Container: Multiple subnets per AZ https://review.opendev.org/c/openstack/manila/+/826462
>
>

++ Thanks for sharing this here Fernando.
Perhaps share the meeting link on OFTC's #openstack-manila before the
sessions begin...


> [1] https://review.opendev.org/c/openstack/manila-specs/+/619925
>
> Regards,
> Fernando


From laurentfdumont at gmail.com  Fri Feb 11 19:31:24 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Fri, 11 Feb 2022 14:31:24 -0500
Subject: Masquerading VM works 99%
In-Reply-To: <46615849.557895.1644509565653@mail.yahoo.com>
References: <46615849.557895.1644509565653.ref@mail.yahoo.com>
 <46615849.557895.1644509565653@mail.yahoo.com>
Message-ID: <CAOAKi8wMGa0FRgT4SjTb85e8AkNUwfjyZ2XQZu35fusai5dreA@mail.gmail.com>

You might want to look at port-security if you are using an Openstack VM as
more of a router. By default, it will permit only it's own mac-address +
ip-address from exiting the interface.

You can fully disable it to see if it's the root cause.

   1. Remove allowed-address-pairs.
   2. Remove security-groups
   3. Disable port-security.


On Thu, Feb 10, 2022 at 11:17 AM Derek O keeffe <derekokeeffe85 at yahoo.ie>
wrote:

> Hi all,
>
> We have an openstack cluster with one controller and 4 computes (Victoria)
> we have set it up using vlan provider networks with linuxbridge agent,
> distributed routing & ml2 (I am only partly on the networking so there
> could be more to that which I can find out if needed)
>
> So I was tasked with creating two Instances, one (lets call it the
> external vm) with an external interface 10.55.9.67 and internal interface
> 192.168.1.2. A second instance (lets call it the internal vm) would then be
> placed on the 192.168.1.0 network.
>
> I configured masquerading on the "external vm" and tried to ping the
> outside world from the "internal" vm as per something like this
> https://kifarunix.com/configure-ubuntu-20-04-as-linux-router/?unapproved=49571&moderation-hash=b5168c04420557dcdc088994ffa4bdbb#comment-49571
>
>
> Both VM's were instantiated on the same compute host (I've tried it with
> them on separate hosts as well).
>
> I can see the ping leave using tcpdumps along the way and it makes it all
> the way back to the internal interface on the external machine. It just
> fails on the last hop to the internal machine. I've tried everything in my
> power to find why this won't work so I would be grateful for any advice at
> all. I have added the below to show how I followed the ping manually and
> where it went and when it failed. Thank you in advance.
>
> Following the ping from source to destination and back:
> Generated on the private VM
> sent to the internal interface on the external vm
> sent to the external interface on the external vm
> sent to the tap interface on the compute
> sent to the physical nic on the compute
> sent to the nic on the network device out to the internet
>
> received on nic on the network devicefrom the internet
> received on physical nic on the compute
> received on tap interface on compute
> received on external interface on the external vm
> received on the internal interface on the external vm
> NEVER gets to last step on the internal vm
>
> Regards,
> Derek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/26f5b407/attachment.htm>

From fernandoperches at gmail.com  Fri Feb 11 19:39:42 2022
From: fernandoperches at gmail.com (Fernando Ferraz)
Date: Fri, 11 Feb 2022 16:39:42 -0300
Subject: [Manila] Yoga Collab reviews
In-Reply-To: <CAKSuTPZ8fpejw-LuNYxkVQwt_MDk8DJFEegYNK7+g76eQZ2QoA@mail.gmail.com>
References: <CAGO9e9tCju9N00Y97hwBMqKOA-iyM16dSD73qMNwMwFvxiDdyw@mail.gmail.com>
 <CAKSuTPZ8fpejw-LuNYxkVQwt_MDk8DJFEegYNK7+g76eQZ2QoA@mail.gmail.com>
Message-ID: <CAGO9e9tM+iaL85Mpw-bMXYnSK5WSeBRA_d9EgtC39Rev+du2hQ@mail.gmail.com>

Will do! Thanks for the reminder Goutham.

Fernando

Em sex., 11 de fev. de 2022 ?s 16:27, Goutham Pacha Ravi <
gouthampravi at gmail.com> escreveu:

> On Fri, Feb 11, 2022 at 11:06 AM Fernando Ferraz
> <fernandoperches at gmail.com> wrote:
> >
> > Hi Team,
> >
> > Would like to invite you to our collaborative review session occurring
> next Monday and Thursday (Feb. 14tth and 17th). Following our proposals
> targeted to the Yoga cycle, all patches partially implement the release
> independent spec "Add spec for multiple subnet share servers" [1].
> >
> > February 14th (16:00-17:30 UTC):
> >
> > 825110: Add multiple subnets per AZ support
> https://review.opendev.org/c/openstack/manila/+/825110
> >
> > February 17th (16:00-17:30 UTC):
> >
> > 825155: NetApp ONTAP: Add support to multiple subnets per AZ
> https://review.opendev.org/c/openstack/manila/+/825155
> > 826462: Container: Multiple subnets per AZ
> https://review.opendev.org/c/openstack/manila/+/826462
> >
> >
>
> ++ Thanks for sharing this here Fernando.
> Perhaps share the meeting link on OFTC's #openstack-manila before the
> sessions begin...
>
>
> > [1] https://review.opendev.org/c/openstack/manila-specs/+/619925
> >
> > Regards,
> > Fernando
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/6e10a210/attachment-0001.htm>

From juliaashleykreger at gmail.com  Fri Feb 11 19:15:02 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Fri, 11 Feb 2022 11:15:02 -0800
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAJm6b-5+6=sWB2yXf8-mToBKdA53paSxRiP0WQ9Bqi+Dfnn84w@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
 <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
 <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>
 <CAJm6b-4+z67on3D94k02m5yN79Yr91TdFyN=vntKmSQNBBK+pQ@mail.gmail.com>
 <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com>
 <CAJm6b-6PYvKPW4AVd19uTmRk=j2Uw-Gh6fjNjDhBOvB0zyMGpg@mail.gmail.com>
 <CAJm6b-5+6=sWB2yXf8-mToBKdA53paSxRiP0WQ9Bqi+Dfnn84w@mail.gmail.com>
Message-ID: <CAF7gwditOunfQH-Whc1rY8M9bbH52d2xOJK06oeroUCaV-4-cg@mail.gmail.com>

On Fri, Feb 11, 2022 at 6:32 AM Lokendra Rathour <lokendrarathour at gmail.com>
wrote:

> Hi Harald/ Openstack Team,
> Thank you again for your support.
>
> we have successfully provisioned the baremetal node as per the inputs
> shared by you. The only change that we did was to add an entry for the
> ServiceNetmap.
>
> Further, we were trying to launch the baremetal node instance  in which we
> are facing ISSUE as mentioned below:
>
>
> [trim'ed picture because of message size]

>
> *"2022-02-11 18:13:45.840 7 ERROR nova.compute.manager
> [req-aafdea4d-815f-4504-b7d7-4fd95d1e083e - - - - -] Error updating
> resources for node 9560bc2d-5f94-4ba0-9711-340cb8ad7d8a.:
> nova.exception.NoResourceClass: Resource class not found for Ironic node
> 9560bc2d-5f94-4ba0-9711-340cb8ad7d8a.*
>
> *2022-02-11 18:13:45.840 7 ERROR nova.compute.manager Traceback (most
> recent call last):2022-02-11 18:13:45.840 7 ERROR nova.compute.manager
> File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 8894,
> in _update_available_resource_for_node*
> "
>

So this exception can only be raised if the resource_class field is just
not populated for the node. It is a required field for nova/ironic
integration. Also, Interestingly enough, this UUID in the error doesn't
match the baremetal node below. I don't know if that is intentional?


> for your reference please refer following details:
> (overcloud) [stack at undercloud v4]$ openstack baremetal node show
> baremetal-node --fit-width
>
> +------------------------+-------------------------------------------------------------------------------------------------------------------+
> | Field                  | Value
>                                                                   |
>
> +------------------------+-------------------------------------------------------------------------------------------------------------------+
> | allocation_uuid        | None
>                                                                    |
> | automated_clean        | None
>                                                                    |
> | bios_interface         | no-bios
>                                                                   |
> | boot_interface         | ipxe
>                                                                    |
> | chassis_uuid           | None
>                                                                    |
> | clean_step             | {}
>                                                                    |
> | conductor              | overcloud-controller-0.localdomain
>                                                                    |
> | conductor_group        |
>                                                                   |
> | console_enabled        | False
>                                                                   |
> | console_interface      | ipmitool-socat
>                                                                    |
> | created_at             | 2022-02-11T13:02:40+00:00
>                                                                   |
> | deploy_interface       | iscsi
>                                                                   |
> | deploy_step            | {}
>                                                                    |
> | description            | None
>                                                                    |
> | driver                 | ipmi
>                                                                    |
> | driver_info            | {'ipmi_port': 623, 'ipmi_username': 'hsc',
> 'ipmi_password': '******', 'ipmi_address': '10.0.1.183',               |
> |                        | 'deploy_kernel':
> 'bc62f3dc-d091-4dbd-b730-cf7b6cb48625', 'deploy_ramdisk':
>                      |
> |                        | 'd58bcc08-cb7c-4f21-8158-0a5ed4198108'}
>                                                                   |
> | driver_internal_info   | {'agent_erase_devices_iterations': 1,
> 'agent_erase_devices_zeroize': True, 'agent_continue_if_ata_erase_failed':
>  |
> |                        | False, 'agent_enable_ata_secure_erase': True,
> 'disk_erasure_concurrency': 1, 'last_power_state_change':           |
> |                        | '2022-02-11T13:14:29.581361', 'agent_version':
> '5.0.5.dev25', 'agent_last_heartbeat':                             |
> |                        | '2022-02-11T13:14:24.151928',
> 'hardware_manager_version': {'generic_hardware_manager': '1.1'},
>          |
> |                        | 'agent_cached_clean_steps': {'deploy':
> [{'step': 'erase_devices', 'priority': 10, 'interface': 'deploy',          |
> |                        | 'reboot_requested': False, 'abortable': True},
> {'step': 'erase_devices_metadata', 'priority': 99, 'interface':    |
> |                        | 'deploy', 'reboot_requested': False,
> 'abortable': True}], 'raid': [{'step': 'delete_configuration', 'priority':
>   |
> |                        | 0, 'interface': 'raid', 'reboot_requested':
> False, 'abortable': True}, {'step': 'create_configuration',           |
> |                        | 'priority': 0, 'interface': 'raid',
> 'reboot_requested': False, 'abortable': True}]},
>    |
> |                        | 'agent_cached_clean_steps_refreshed':
> '2022-02-11 13:14:22.580729', 'clean_steps': None}
>  |
> | extra                  | {}
>                                                                    |
> | fault                  | None
>                                                                    |
> | inspect_interface      | inspector
>                                                                   |
> | inspection_finished_at | None
>                                                                    |
> | inspection_started_at  | None
>                                                                    |
> | instance_info          | {}
>                                                                    |
> | instance_uuid          | None
>                                                                    |
> | last_error             | None
>                                                                    |
> | maintenance            | False
>                                                                   |
> | maintenance_reason     | None
>                                                                    |
> | management_interface   | ipmitool
>                                                                    |
> | name                   | baremetal-node
>                                                                    |
> | network_interface      | flat
>                                                                    |
> | owner                  | None
>                                                                    |
> | power_interface        | ipmitool
>                                                                    |
> | power_state            | power off
>                                                                   |
>
> *| properties             | {'cpus': 20, 'memory_mb': 63700, 'local_gb':
> 470, 'cpu_arch': 'x86_64', 'capabilities':                           ||
>                    | 'boot_option:local,boot_mode:uefi', 'vendor':
> 'hewlett-packard'}     *                                             |
> | protected              | False
>                                                                   |
> | protected_reason       | None
>                                                                    |
> | provision_state        | available
>                                                                   |
> | provision_updated_at   | 2022-02-11T13:14:51+00:00
>                                                                   |
> | raid_config            | {}
>                                                                    |
> | raid_interface         | no-raid
>                                                                   |
> | rescue_interface       | agent
>                                                                   |
> | reservation            | None
>                                                                    |
> *| resource_class         | baremetal-resource-class  *
>                                                                      |
> | storage_interface      | noop
>                                                                    |
> | target_power_state     | None
>                                                                    |
> | target_provision_state | None
>                                                                    |
> | target_raid_config     | {}
>                                                                    |
> | traits                 | []
>                                                                    |
> | updated_at             | 2022-02-11T13:14:52+00:00
>                                                                   |
> | uuid                   | e64ad28c-43d6-4b9f-aa34-f8bc58e9e8fe
>                                                                    |
> | vendor_interface       | ipmitool
>                                                                    |
>
> +------------------------+-------------------------------------------------------------------------------------------------------------------+
> (overcloud) [stack at undercloud v4]$
>
>
>
>
> (overcloud) [stack at undercloud v4]$ openstack flavor show
> my-baremetal-flavor --fit-width
>
> +----------------------------+---------------------------------------------------------------------------------------------------------------+
> | Field                      | Value
>                                                                   |
>
> +----------------------------+---------------------------------------------------------------------------------------------------------------+
> | OS-FLV-DISABLED:disabled   | False
>                                                                   |
> | OS-FLV-EXT-DATA:ephemeral  | 0
>                                                                   |
> | access_project_ids         | None
>                                                                    |
> | description                | None
>                                                                    |
> | disk                       | 470
>                                                                   |
>
> *| extra_specs                |
> {'resources:CUSTOM_BAREMETAL_RESOURCE_CLASS': '1', 'resources:VCPU': '0',
> 'resources:MEMORY_MB': '0',         ||                            |
> 'resources:DISK_GB': '0', 'capabilities:boot_option':
> 'local,boot_mode:uefi'} *                                |
> | id                         | 66a13404-4c47-4b67-b954-e3df42ae8103
>                                                                    |
> | name                       | my-baremetal-flavor
>                                                                   |
> | os-flavor-access:is_public | True
>                                                                    |
>
> *| properties                 |
> capabilities:boot_option='local,boot_mode:uefi',
> resources:CUSTOM_BAREMETAL_RESOURCE_CLASS='1',               ||
>                | resources:DISK_GB='0', resources:MEMORY_MB='0',
> resources:VCPU='0'    *                                        |
> | ram                        | 63700
>                                                                   |
> | rxtx_factor                | 1.0
>                                                                   |
> | swap                       | 0
>                                                                   |
> | vcpus                      | 20
>                                                                    |
>
> +----------------------------+---------------------------------------------------------------------------------------------------------------+
>

However you've set your capabilities field, it is actually unable to be
parsed. Then again, it doesn't *have* to be defined to match the baremetal
node. The setting can still apply on the baremetal node if that is the
operational default for the machine as defined on the machine itself.

I suspect, based upon whatever the precise nova settings are, this would
result in an inability to schedule on to the node because it would parse it
incorrectly, possibly looking for a key value of
"capabilities:boot_option", instead of "capabilities".

(overcloud) [stack at undercloud v4]$
>
> Can you please check and suggest if something is missing.
>
> Thanks once again for your support.
>
> -Lokendra
>
>
>
>
> On Thu, Feb 10, 2022 at 10:09 PM Lokendra Rathour <
> lokendrarathour at gmail.com> wrote:
>
>> Hi Harald,
>> Thanks for the response, please find my response inline:
>>
>>
>> On Thu, Feb 10, 2022 at 8:24 PM Harald Jensas <hjensas at redhat.com> wrote:
>>
>>> On 2/10/22 14:49, Lokendra Rathour wrote:
>>> > Hi Harald,
>>> > Thanks once again for your support, we tried activating the parameters:
>>> > ServiceNetMap:
>>> >      IronicApiNetwork: provisioning
>>> >      IronicNetwork: provisioning
>>> > at environments/network-environments.yaml
>>> > image.png
>>> > After changing these values the updated or even the fresh deployments
>>> > are failing.
>>> >
>>>
>>> How did deployment fail?
>>>
>>
>> [Loke] : it failed immediately after when the IP for ctlplane network is
>> assigned, and ssh is established and stack creation is completed, I think
>> at the start of ansible execution.
>>
>> Error:
>> "enabling ssh admin - COMPLETE.
>> Host 10.0.1.94 not found in /home/stack/.ssh/known_hosts"
>> Although this message is even seen when the deployment is successful. so
>> I do not think this is the culprit.
>>
>>
>>
>>
>>> > The command that we are using to deploy the OpenStack overcloud:
>>> > /openstack overcloud deploy --templates \
>>> >      -n /home/stack/templates/network_data.yaml \
>>> >      -r /home/stack/templates/roles_data.yaml \
>>> >      -e /home/stack/templates/node-info.yaml \
>>> >      -e /home/stack/templates/environment.yaml \
>>> >      -e /home/stack/templates/environments/network-isolation.yaml \
>>> >      -e /home/stack/templates/environments/network-environment.yaml \
>>>
>>> What modifications did you do to network-isolation.yaml and
>>
>> [Loke]:
>> *Network-isolation.yaml:*
>>
>> # Enable the creation of Neutron networks for isolated Overcloud
>> # traffic and configure each role to assign ports (related
>> # to that role) on these networks.
>> resource_registry:
>>   # networks as defined in network_data.yaml
>>   OS::TripleO::Network::J3Mgmt: ../network/j3mgmt.yaml
>>   OS::TripleO::Network::Tenant: ../network/tenant.yaml
>>   OS::TripleO::Network::InternalApi: ../network/internal_api.yaml
>>   OS::TripleO::Network::External: ../network/external.yaml
>>
>>
>>   # Port assignments for the VIPs
>>   OS::TripleO::Network::Ports::J3MgmtVipPort: ../network/ports/j3mgmt.yaml
>>
>>
>>   OS::TripleO::Network::Ports::InternalApiVipPort:
>> ../network/ports/internal_api.yaml
>>   OS::TripleO::Network::Ports::ExternalVipPort:
>> ../network/ports/external.yaml
>>
>>
>>   OS::TripleO::Network::Ports::RedisVipPort: ../network/ports/vip.yaml
>>   OS::TripleO::Network::Ports::OVNDBsVipPort: ../network/ports/vip.yaml
>>
>>
>>
>>   # Port assignments by role, edit role definition to assign networks to
>> roles.
>>   # Port assignments for the Controller
>>   OS::TripleO::Controller::Ports::J3MgmtPort: ../network/ports/j3mgmt.yaml
>>   OS::TripleO::Controller::Ports::TenantPort: ../network/ports/tenant.yaml
>>   OS::TripleO::Controller::Ports::InternalApiPort:
>> ../network/ports/internal_api.yaml
>>   OS::TripleO::Controller::Ports::ExternalPort:
>> ../network/ports/external.yaml
>>   # Port assignments for the Compute
>>   OS::TripleO::Compute::Ports::J3MgmtPort: ../network/ports/j3mgmt.yaml
>>   OS::TripleO::Compute::Ports::TenantPort: ../network/ports/tenant.yaml
>>   OS::TripleO::Compute::Ports::InternalApiPort:
>> ../network/ports/internal_api.yaml
>>
>> ~
>>
>>
>>>
>>> network-environment.yaml?
>>>
>>
>> resource_registry:
>>   # Network Interface templates to use (these files must exist). You can
>>   # override these by including one of the net-*.yaml environment files,
>>   # such as net-bond-with-vlans.yaml, or modifying the list here.
>>   # Port assignments for the Controller
>>   OS::TripleO::Controller::Net::SoftwareConfig:
>>     ../network/config/bond-with-vlans/controller.yaml
>>   # Port assignments for the Compute
>>   OS::TripleO::Compute::Net::SoftwareConfig:
>>     ../network/config/bond-with-vlans/compute.yaml
>> parameter_defaults:
>>
>>   J3MgmtNetCidr: '80.0.1.0/24'
>>   J3MgmtAllocationPools: [{'start': '80.0.1.4', 'end': '80.0.1.250'}]
>>   J3MgmtNetworkVlanID: 400
>>
>>   TenantNetCidr: '172.16.0.0/24'
>>   TenantAllocationPools: [{'start': '172.16.0.4', 'end': '172.16.0.250'}]
>>   TenantNetworkVlanID: 416
>>   TenantNetPhysnetMtu: 1500
>>
>>   InternalApiNetCidr: '172.16.2.0/24'
>>   InternalApiAllocationPools: [{'start': '172.16.2.4', 'end':
>> '172.16.2.250'}]
>>   InternalApiNetworkVlanID: 418
>>
>>   ExternalNetCidr: '10.0.1.0/24'
>>   ExternalAllocationPools: [{'start': '10.0.1.85', 'end': '10.0.1.98'}]
>>   ExternalNetworkVlanID: 408
>>
>>   DnsServers: []
>>   NeutronNetworkType: 'geneve,vlan'
>>   NeutronNetworkVLANRanges: 'datacentre:1:1000'
>>   BondInterfaceOvsOptions: "bond_mode=active-backup"
>>
>>
>>>
>>> I typically use:
>>> -e
>>>
>>> /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
>>> -e
>>>
>>> /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml
>>> -e /home/stack/templates/environments/network-overrides.yaml
>>>
>>> The network-isolation.yaml and network-environment.yaml are Jinja2
>>> rendered based on the -n input, so too keep in sync with change in the
>>> `-n` file reference the file in
>>> /usr/share/opentack-tripleo-heat-templates. Then add overrides in
>>> network-overrides.yaml as neede.
>>>
>>
>> [Loke] : we are using this as like only, I do not know what you pass in
>> network-overrides.yaml but I pass other files as per commands as below:
>>
>> [stack at undercloud templates]$ cat environment.yaml
>> parameter_defaults:
>>   ControllerCount: 3
>>   TimeZone: 'Asia/Kolkata'
>>   NtpServer: ['30.30.30.3']
>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>   NeutronFlatNetworks: datacentre,baremetal
>> [stack at undercloud templates]$ cat ironic-config.yaml
>> parameter_defaults:
>>     IronicEnabledHardwareTypes:
>>         - ipmi
>>         - redfish
>>     IronicEnabledPowerInterfaces:
>>         - ipmitool
>>         - redfish
>>     IronicEnabledManagementInterfaces:
>>         - ipmitool
>>         - redfish
>>     IronicCleaningDiskErase: metadata
>>     IronicIPXEEnabled: true
>>     IronicInspectorSubnets:
>>     - ip_range: 172.23.3.100,172.23.3.150
>>     IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel", "
>> http://30.30.30.1:8088/agent.ramdisk"]'
>>     IronicInspectorInterface: 'br-baremetal'
>> [stack at undercloud templates]$
>> [stack at undercloud templates]$ cat node-info.yaml
>> parameter_defaults:
>>   OvercloudControllerFlavor: control
>>   OvercloudComputeFlavor: compute
>>   ControllerCount: 3
>>   ComputeCount: 1
>> [stack at undercloud templates]$
>>
>>
>>
>>>
>>> >      -e
>>> >
>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>>>
>>> > \
>>> >      -e
>>> >
>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>>>
>>> > \
>>> >      -e
>>> >
>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>>>
>>> > \
>>> >      -e /home/stack/templates/ironic-config.yaml \
>>> >      -e
>>> >
>>> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>>> >      -e
>>> > /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>>> >      -e /home/stack/containers-prepare-parameter.yaml/
>>> >
>>> > **/home/stack/templates/ironic-config.yaml :
>>> > (overcloud) [stack at undercloud ~]$ cat
>>> > /home/stack/templates/ironic-config.yaml
>>> > parameter_defaults:
>>> >      IronicEnabledHardwareTypes:
>>> >          - ipmi
>>> >          - redfish
>>> >      IronicEnabledPowerInterfaces:
>>> >          - ipmitool
>>> >          - redfish
>>> >      IronicEnabledManagementInterfaces:
>>> >          - ipmitool
>>> >          - redfish
>>> >      IronicCleaningDiskErase: metadata
>>> >      IronicIPXEEnabled: true
>>> >      IronicInspectorSubnets:
>>> >      - ip_range: 172.23.3.100,172.23.3.150
>>> >      IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel
>>> > <http://30.30.30.1:8088/agent.kernel>",
>>> > "http://30.30.30.1:8088/agent.ramdisk
>>> > <http://30.30.30.1:8088/agent.ramdisk>"] >
>>> IronicInspectorInterface: 'br-baremetal'
>>> >
>>> > Also the baremetal network(provisioning)(172.23.3.x)  is  routed with
>>> > ctlplane/admin network (30.30.30.x)
>>> >
>>>
>>> Unless the network you created in the overcloud is named `provisioning`,
>>> these parameters may be relevant.
>>>
>>> IronicCleaningNetwork:
>>>    default: 'provisioning'
>>>    description: Name or UUID of the *overcloud* network used for cleaning
>>>                 bare metal nodes. The default value of "provisioning"
>>> can be
>>>                 left during the initial deployment (when no networks are
>>>                 created yet) and should be changed to an actual UUID in
>>>                 a post-deployment stack update.
>>>    type: string
>>>
>>> IronicProvisioningNetwork:
>>>    default: 'provisioning'
>>>    description: Name or UUID of the *overcloud* network used for
>>> provisioning
>>>                 of bare metal nodes, if IronicDefaultNetworkInterface is
>>>                 set to "neutron". The default value of "provisioning"
>>> can be
>>>                 left during the initial deployment (when no networks are
>>>                 created yet) and should be changed to an actual UUID in
>>>                 a post-deployment stack update.
>>>    type: string
>>>
>>> IronicRescuingNetwork:
>>>    default: 'provisioning'
>>>    description: Name or UUID of the *overcloud* network used for resucing
>>>                 of bare metal nodes, if IronicDefaultRescueInterface is
>>> not
>>>                 set to "no-rescue". The default value of "provisioning"
>>> can be
>>>                 left during the initial deployment (when no networks are
>>>                 created yet) and should be changed to an actual UUID in
>>>                 a post-deployment stack update.
>>>    type: string
>>>
>>> > *Query:*
>>> >
>>> >  1. any other location/way where we should add these so that they are
>>> >     included without error.
>>> >
>>> >         *ServiceNetMap:*
>>> >
>>> >         *    IronicApiNetwork: provisioning*
>>> >
>>> >         *    IronicNetwork: provisioning*
>>> >
>>>
>>> `provisioning` network is defined in -n
>>> /home/stack/templates/network_data.yaml right?
>>
>> [Loke]: No it does not have any entry for provisioning in this file, it
>> is network entry for J3Mgmt,Tenant,InternalApi, and External. These n/w's
>> are added as vlan based under the br-ext bridge.
>> provisioning network I am creating after the overcloud is deployed and
>> before the baremetal node is provisioned.
>> in the provisioning network, we are giving the range of the ironic
>> network. (172.23.3.x)
>>
>>
>>
>>
>>> And an entry in
>>> 'networks' for the controller role in
>>> /home/stack/templates/roles_data.yaml?
>>>
>> [Loke]: we also did not added a similar entry in the roles_data.yaml as
>> well.
>>
>> Just to add with these two files we have rendered the remaining
>> templates.
>>
>>
>>
>>
>>>
>>>
>>> >       2. Also are these commands(mentioned above) configure Baremetal
>>> >     services are fine.
>>> >
>>>
>>> Yes, what you are doing makes sense.
>>>
>>> I'm actually not sure why it did'nt work with your previous
>>> configuration, it got the information about NBP file and obviously
>>> attempted to download it from 30.30.30.220. With routing in place, that
>>> should work.
>>>
>>> Changeing the ServiceNetMap to move IronicNetwork services to the
>>> 172.23.3 would avoid the routing.
>>>
>> [Loke] : we can try this but are somehow not able to do so because of
>> some weird reasons.
>>
>>>
>>>
>>> What is NeutronBridgeMappings?
>>>   br-baremetal maps to the physical network of the overcloud
>>> `provisioning` neutron network?
>>>
>>
>>
>>> [Loke] : yes , we create br-barmetal and then we create provisioning
>>> network mapping it to br-baremetal.
>>>
>>> Also attaching the complete rendered template folder along with custom
>> yaml files that I am using, maybe referring that you might have a more
>> clear picture of our problem.
>> Any clue would help.
>> Our problem,
>> we are not able to provision the baremetal node after the overcloud is
>> deployed.
>> Do we have any straight-forward documents using which we can test the
>> baremetal provision, please provide that.
>>
>> Thanks once again for reading all these.
>>
>>
>>
>>
>>> --
>>> Harald
>>>
>>>
>>
>> -
>> skype: lokendrarathour
>>
>>
>>
>
> --
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220211/91404a84/attachment-0001.htm>

From gmann at ghanshyammann.com  Fri Feb 11 21:27:07 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 11 Feb 2022 15:27:07 -0600
Subject: [all][tc] What's happening in Technical Committee: summary 11th
 Feb, 21: Reading: 5 min
Message-ID: <17eeaaebf7c.c28756a3230522.4001236200874473851@ghanshyammann.com>

Hello Everyone,

Here is this week's summary of the Technical Committee activities.

1. TC Meetings:
============
* We had this week meeting yesterday. Most of the meeting discussions are summarized below (Completed
or in-progress activities section). Meeting full logs are available
@https://meetings.opendev.org/meetings/tc/2022/tc.2022-02-10-15.00.log.html

* Next week's meeting is on 17th Feb Thursday 15:00 UTC, feel free add the topic on
the agenda[1] by 16th Feb.


2. What we completed this week:
=========================
* Reverted the neutron-fwaas deprecation and it is maintained under neutron stadium now[2].
* Removed security-specs from security sig[3].


3. Activities In progress:
==================
TC Tracker for Yoga cycle
------------------------------
* This etherpad includes the Yoga cycle targets/working items for TC[4].
2 out of 9 items are completed.

Open Reviews
-----------------
* Four open reviews for ongoing activities[5].

Dropping tags framework
------------------------------
yoctozepto has updated the part1 of dropping the tag framework[6] which is ready
for review. He will continue working on part2 which is to update the release scripts
and openstack navigation sites to remove the tag usage.

Z release cycle name
-------------------------
TC selection on proposed names is closed and selected names are under trademark checks
by foundation, follow the ML[7] for updates.

Z release cycle Technical Election
---------------------------------------
Nomination for PTL and TC election are in-progress and will be open until 15th Feb[8]. I would
like to encourage project leaders to stand for PTL and community members to run for TC. Please
add your nomination before deadline[9].

TC position on release cadence
-------------------------------------
We had separate call to discuss the next step and TC position on release cadence[10] and
as discussed Dan has proposed the new release model as TC resolution[11]. 

Fixing Zuul config error
----------------------------
Requesting projects with zuul config error to look into those and fix them which should
not take much time[12].

Project updates
-------------------
* Retire js-openstack-lib (waiting on Adjutant to have new PTL/maintainer) [13]


4. How to contact the TC:
====================
If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways:

1. Email: you can send the email with tag [tc] on openstack-discuss ML[14].
2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [15]
3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel.


[1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
[2] https://review.opendev.org/c/openstack/governance/+/828078
[3] https://review.opendev.org/c/openstack/governance/+/828018
[4] https://etherpad.opendev.org/p/tc-yoga-tracker
[5] https://review.opendev.org/q/projects:openstack/governance+status:open
[6] https://review.opendev.org/c/openstack/governance/+/822900
[7] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026810.html
[8] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027117.html
[9] https://governance.openstack.org/election/
[10] https://meetpad.opendev.org/OpenStackReleasecadence
[11] https://review.opendev.org/c/openstack/governance/+/828777
[12] https://etherpad.opendev.org/p/zuul-config-error-openstack
[13] https://review.opendev.org/c/openstack/governance/+/798540
[14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting

-gmann                 



From dmendiza at redhat.com  Fri Feb 11 22:01:32 2022
From: dmendiza at redhat.com (Douglas Mendizabal)
Date: Fri, 11 Feb 2022 16:01:32 -0600
Subject: [elections][ptl][barbican]
Message-ID: <e8528b6d-ed76-13b4-3a75-86a60a36747a@redhat.com>

Hi All,

I would like to continue to serve as Barbican PTL for the Z cycle.
Barbican is slowly moving forward, and I would like to see improvements
continue for the next cycle.

Thanks,
Douglas Mendiz?bal
OFTC: dmendiza[m]



From dmendiza at redhat.com  Fri Feb 11 22:11:13 2022
From: dmendiza at redhat.com (Douglas Mendizabal)
Date: Fri, 11 Feb 2022 16:11:13 -0600
Subject: [elections][ptl][keystone] PTL Candidacy for Keystone
Message-ID: <038c8572-5f5d-769a-bfa8-28f35d5c8d16@redhat.com>

Hi All,

I would like to announce my candidacy for Keystone PTL.  Keystone is an
important project for OpenStack and I would like to help ensure things
keep moving forward.

I'm very much interested in the Secure RBAC effort and I want to make 
sure that the Keystone project has everything it needs to support the 
greater community pursue the completion of this goal.

Thanks,
Douglas Mendiz?bal
OFTC: dmendiza[m]



From hjensas at redhat.com  Sat Feb 12 01:57:47 2022
From: hjensas at redhat.com (Harald Jensas)
Date: Sat, 12 Feb 2022 02:57:47 +0100
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
Message-ID: <8b8ea100-7119-eb46-0156-0e069fe3a131@redhat.com>

+1

On 2/10/22 15:35, Jose Luis Franco Arza wrote:
> Hello folks,
> 
> I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer 
> on the TripleO repositories related to the upgrades workflow 
> (openstack/tripleo-heat-templates, openstack/tripleo-ansible, 
> openstack/python-tripleoclient, openstack/tripleo-ci, 
> openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). 
> Sergii has been working in OpenStack for the last 10 years, he is 
> already core-reviewer of thetripleo-upgrade 
> <https://github.com/openstack/tripleo-upgrade>repository in which he is 
> providing with very valuable feedback, as well as helping getting 
> relevant patches merged.
> 
> His deep knowledge of the different OpenStack projects, as well as his 
> involvement in the upgrades/updates workflows for the last 9 OpenStack 
> releases makes him a great code reviewer, being able to catch several 
> issues during the code review process.
> 
> I will monitor the thread for a week and if no objections are exposed I 
> will add him to the tripleo-core group.
> 
> PD: Here comes the +1 from my side.
> 
> Thanks.
> 
> Cheers,
> Jos? Luis
> 
> [1]:https://review.opendev.org/q/owner:sgolovat%2540redhat.com 
> <https://review.opendev.org/q/owner:sgolovat%2540redhat.com>
> [2]: 
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all 
> <https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all>
> [3]: Position #25 in the most active TripleO contributors list 
> <https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180>



From anlin.kong at gmail.com  Sat Feb 12 03:40:02 2022
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Sat, 12 Feb 2022 16:40:02 +1300
Subject: OpenStack Trove experimental datastores
In-Reply-To: <0670B960225633449A24709C291A525251E7C31C@COM03.performair.local>
References: <10DE5E61-5A25-49FB-88D7-D918823EF53A@gmail.com>
 <0670B960225633449A24709C291A525251E7C31C@COM03.performair.local>
Message-ID: <CALjNAZ3T6do4gNtRyNzzRLFx27VSo-oSqwszisYzHXnZ9DHhHA@mail.gmail.com>

Hi Dominic,

Although I'm not going to contribute to the Trove project anymore, I
disagree with what you said that using database containers is a bad
example, especially considering the project situation in the open source
community in the past several years.

I've explained this several times to different people when I was making the
change, but I don't mind repeating myself.

Trove was supporting multiple datastores previously and maintaining a bunch
of DIB image elements to build different guest images. However, the task of
keeping those elements up to date is not easy, and needs the domain
knowledge of the specific database, but most of the active contributors
have left and the project itself was on the edge of death.

It was that time when I picked up the project because the
database-as-a-service was on the service roadmap of our openstack based
public cloud. Given this is such a complicated project with such a small
team, it's impossible to maintain those different kinds of datastores. As a
result, I made the decision to simplify the trove guest image build process
and introduce container based database inside trove guest instance, so the
project only needs to maintain a single common guest image but to support
as more datastores as possible, offloading the database container image
maintenance work to other upstream teams who specialize in the database
technology area.

I don't think we had other better choices at that time.

Anyway, hope there will be more people could see my comment here and there
will be someone raises his hand to lead this project forward. I'm glad to
know Trove is deployed in your cloud, it's a pity that I didn't see any
contribution coming from the team behind your cloud.

---
Lingxian Kong


On Sat, Feb 12, 2022 at 7:24 AM <DHilsbos at performair.com> wrote:

> In Victoria, Trove moved to Docker images for the datastores.  Any
> datastores that didn't update themselves were removed, regardless of
> state.  I believe the only datastores currently supported are MariaDB, and
> PostgreSQL, though MySQL might be supported as well.
>
> Personally. I find this to have been a bad example of the "containerize
> all the things" mentality.  Trove now deploys an instance (vm) for each
> datastore instance, running a single container.  The exception is if you
> request backups, in which case a backup container is added to the instance
> (vm).
>
> Trove is installed in our OpenStack cloud, but we don't use it.
>
> Thank you,
>
> Dominic L. Hilsbos, MBA
> Vice President - Information Technology
> Perform Air International Inc.
> DHilsbos at PerformAir.com
> www.PerformAir.com
>
>
> From: ????? ?????? [mailto:rishat.azizov at gmail.com]
> Sent: Sunday, February 6, 2022 11:10 AM
> To: openstack-discuss at lists.openstack.org
> Subject: OpenStack Trove experimental datastores
>
> Hello!
>
> Why were the experimental datastores removed in the Trove OpenStack
> Victoria release? https://review.opendev.org/c/openstack/trove/+/728419
>
> Thanks!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220212/587e9fc4/attachment-0001.htm>

From derekokeeffe85 at yahoo.ie  Sat Feb 12 09:47:54 2022
From: derekokeeffe85 at yahoo.ie (Derek O keeffe)
Date: Sat, 12 Feb 2022 09:47:54 +0000
Subject: Masquerading VM works 99%
In-Reply-To: <CAOAKi8wMGa0FRgT4SjTb85e8AkNUwfjyZ2XQZu35fusai5dreA@mail.gmail.com>
References: <CAOAKi8wMGa0FRgT4SjTb85e8AkNUwfjyZ2XQZu35fusai5dreA@mail.gmail.com>
Message-ID: <F25AB574-B5DF-4149-B4F3-91C0429F6796@yahoo.ie>

Hi Laurent,

I will double check but I?m sure I?ve checked that. I forgot to mention that both vm?s can ping each other on the ?private? interfaces.

Regards, 
Derek

> On 11 Feb 2022, at 19:33, Laurent Dumont <laurentfdumont at gmail.com> wrote:
> 
> ?
> You might want to look at port-security if you are using an Openstack VM as more of a router. By default, it will permit only it's own mac-address + ip-address from exiting the interface.
> 
> You can fully disable it to see if it's the root cause.
> Remove allowed-address-pairs.
> Remove security-groups
> Disable port-security.
> 
>> On Thu, Feb 10, 2022 at 11:17 AM Derek O keeffe <derekokeeffe85 at yahoo.ie> wrote:
>> Hi all,
>> 
>> We have an openstack cluster with one controller and 4 computes (Victoria) we have set it up using vlan provider networks with linuxbridge agent, distributed routing & ml2 (I am only partly on the networking so there could be more to that which I can find out if needed)
>> 
>> So I was tasked with creating two Instances, one (lets call it the external vm) with an external interface 10.55.9.67 and internal interface 192.168.1.2. A second instance (lets call it the internal vm) would then be placed on the 192.168.1.0 network.
>> 
>> I configured masquerading on the "external vm" and tried to ping the outside world from the "internal" vm as per something like this https://kifarunix.com/configure-ubuntu-20-04-as-linux-router/?unapproved=49571&moderation-hash=b5168c04420557dcdc088994ffa4bdbb#comment-49571
>> 
>> 
>> Both VM's were instantiated on the same compute host (I've tried it with them on separate hosts as well).
>> 
>> I can see the ping leave using tcpdumps along the way and it makes it all the way back to the internal interface on the external machine. It just fails on the last hop to the internal machine. I've tried everything in my power to find why this won't work so I would be grateful for any advice at all. I have added the below to show how I followed the ping manually and where it went and when it failed. Thank you in advance.
>> 
>> Following the ping from source to destination and back:
>> Generated on the private VM
>> sent to the internal interface on the external vm
>> sent to the external interface on the external vm
>> sent to the tap interface on the compute
>> sent to the physical nic on the compute
>> sent to the nic on the network device out to the internet
>> 
>> received on nic on the network devicefrom the internet 
>> received on physical nic on the compute
>> received on tap interface on compute 
>> received on external interface on the external vm
>> received on the internal interface on the external vm
>> NEVER gets to last step on the internal vm 
>> 
>> Regards,
>> Derek
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220212/29d0353b/attachment.htm>

From franck.vedel at univ-grenoble-alpes.fr  Sat Feb 12 10:20:40 2022
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Sat, 12 Feb 2022 11:20:40 +0100
Subject: [kolla-ansible][nova] volume creation time
In-Reply-To: <20220209081211.Horde.WAVvbmDzp-FEZWmNHXHb6GR@webmail.nde.ag>
References: <20220209081211.Horde.WAVvbmDzp-FEZWmNHXHb6GR@webmail.nde.ag>
Message-ID: <6339B870-49E9-4B56-B666-F3003D1E97BD@univ-grenoble-alpes.fr>

Thank you for your help.

my openstack being operational and must absolutely be ok for several months (student projects), I don't touch it...

In France we have the saying "Scalded cat fears cold water ?

But I put all this information aside. I will have to look at this more closely, and especially that I change storage by switching to ceph.
Thanks again Eugen

Franck 
> Le 9 f?vr. 2022 ? 09:12, Eugen Block <eblock at nde.ag> a ?crit :
> 
> I haven't used iscsi as a backend yet, but for HDDs the speed looks relatable, on a system with HDD ceph backend the volume creation of a volume (image is 2 GB) takes about 40 seconds, as you yee the download is quite slow, the conversion is a little faster:
> 
> Image download 541.00 MB at 28.14 MB/s
> Converted 2252.00 MB image at 172.08 MB/s
> 
> With a factor of 10 (20 GB) I would probably end up with similar creation times. Just for comparison, this is almost the same image (also 2 GB) in a different ceph cluster where I mounted the cinder conversion path from cephfs, SSD pool:
> 
> Image download 555.12 MB at 41.34 MB/s
> Converted 2252.00 MB image at 769.17 MB/s
> 
> This volume was created within 20 seconds. You might also want to tweak these options:
> 
> block_device_allocate_retries = 300
> block_device_allocate_retries_interval = 10
> 
> These are the defaults:
> 
> block_device_allocate_retries = 60
> block_device_allocate_retries_interval = 3
> 
> This would fit your error message:
> 
>> Volume be0f28eb-1045-4687-8bdb-5a6d385be6fa did not finish being created even after we waited 187 seconds or 61 attempts. And its status is downloading.
> 
> It tried 60 times with a 3 second interval, apparently that's not enough. Can you see any bottlenecks in the network or disk utilization which would slow down the download?
> 
> 
> Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:
> 
>> Hi Eugen,
>> thanks for your help
>> We have 3 servers (s1, s2 , s3) and an iscsi bay attached on s3.
>> Multinode:
>> [control]
>> s1
>> s2
>> 
>> [compute]
>> s1
>> s2
>> s3
>> 
>> [storage]
>> s3
>> 
>> on s1: more /etc/kolla/globals.yml
>> ...
>> enable_cinder: "yes"
>> enable_cinder_backend_iscsi: "yes"
>> enable_cinder_backend_lvm: ? yes"
>> enable_iscsid: ? yes"
>> cinder_volume_group: "cinder-volumes ?
>> ...
>> enable_glance_image_cache: "yes"
>> glance_cache_max_size: "21474836480"
>> glance_file_datadir_volume: ? /images/?
>> ...
>> 
>> on s3:  /images is on the iscsi bay
>> mount |grep images
>> /dev/mapper/VG--IMAGES-LV--IMAGES on /images type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=1024,swidth=1024,noquota)
>> 
>> lsblk
>> sdf                                                                             8:80   0   500G  0 disk
>> ??mpathc                                                                      253:3    0   500G  0 mpath
>> ??mpathc1                                                                   253:4    0   500G  0 part
>>   ??VG--IMAGES-LV--IMAGES                                                   253:5    0   500G  0 lvm   /images
>> 
>> 
>> ls -l /images:
>> drwxr-x---. 5 42415 42415 4096  6 f?vr. 18:40 image-cache
>> drwxr-x---. 2 42415 42415 4096  4 f?vr. 15:16 images
>> drwxr-x---. 2 42415 42415    6 22 nov.  12:03 staging
>> drwxr-x---. 2 42415 42415    6 22 nov.  12:03 tasks_work_dir
>> 
>> ls -l /images/image-cache
>> total 71646760
>> -rw-r-----. 1 42415 42415   360841216  2 d?c.  11:52 3e3aada8-7610-4c55-b116-a12db68f8ea4
>> -rw-r-----. 1 42415 42415   237436928 28 nov.  16:56 6419642b-fcbd-4e5d-9c77-46a48d2af93f
>> -rw-r-----. 1 42415 42415 10975379456 26 nov.  14:59 7490e914-8001-4d56-baea-fabf80f425e1
>> -rw-r-----. 1 42415 42415 21474836480 22 nov.  16:46 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5
>> -rw-r-----. 1 42415 42415  2694512640 15 d?c.  18:07 890fd2e8-2fac-42c6-956b-6b10f2253a56
>> -rw-r-----. 1 42415 42415 12048400384  1 d?c.  17:04 9a235763-ff0c-40fd-9a8d-7cdca3d3e9ce
>> -rw-r-----. 1 42415 42415  5949227008 15 d?c.  20:41 9cbba37b-1de1-482a-87f2-631d2143cd46
>> -rw-r-----. 1 42415 42415   566994944  6 d?c.  12:32 b6e29dd9-a66d-4569-a222-6fc0bd9b1b11
>> -rw-r-----. 1 42415 42415   578748416  2 d?c.  11:24 c40953ee-4b39-43a5-8f6c-b48a046c38e9
>> -rw-r-----. 1 42415 42415    16300544 27 janv. 12:19 c88630c7-a7c6-44ff-bfa0-e5af4b1720e3
>> -rw-r-----. 1 42415 42415       12288  6 f?vr. 18:40 cache.db
>> -rw-r-----. 1 42415 42415 12324503552  1 d?c.  07:50 e0d4fddd-5aa7-4177-a1d6-e6b4c56f12e8
>> -rw-r-----. 1 42415 42415  6139084800 22 nov.  15:05 eda93204-9846-4216-a6e8-c29977fdcf2f
>> -rw-r-----. 1 42415 42415           0 22 nov.  12:03 image_cache_db_init
>> drwxr-x---. 2 42415 42415           6 27 janv. 12:19 incomplete
>> drwxr-x---. 2 42415 42415           6 22 nov.  12:03 invalid
>> drwxr-x---. 2 42415 42415           6 22 nov.  12:03 queue
>> 
>> on s1
>> openstack image list
>> +--------------------------------------+-----------------------------+--------+
>> | ID                                   | Name                        | Status |
>> +--------------------------------------+-----------------------------+--------+
>> ?..
>> | 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5 | rocky8.4                    | active |
>> ?.
>> | 7490e914-8001-4d56-baea-fabf80f425e1 | win10_2104                  | active |
>> ?.
>> +???????????????????+-----------------------------+????+
>> 
>> 
>> openstack image show 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5
>> disk_format      | raw
>> 
>> when I try to add an instance from this image (2G RAM, 40G HDD):
>> [Error : Build of instance baa06bef-9628-407f-8bae-500ef7bce065 aborted: Volume be0f28eb-1045-4687-8bdb-5a6d385be6fa did not finish being created even after we waited 187 seconds or 61 attempts. And its status is downloading.
>> 
>> it?s impossible. I need to add the volume from image first, and after add instance from volume.
>> 
>> Is it normal ?
>> 
>> 
>> Franck
>> 
>>> Le 7 f?vr. 2022 ? 10:55, Eugen Block <eblock at nde.ag> a ?crit :
>>> 
>>> Hi Franck,
>>> 
>>> although it's a different topic than your original question I wanted to comment on the volume creation time (maybe a new thread would make sense). What is your storage back end? If it is ceph, are your images in raw format? Otherwise cinder has to download the image from glance (to /var/lib/cinder/conversion) and convert it, then upload it back to ceph. It's similar with nova, nova stores base images in /var/lib/nova/instances/_base to prevent the compute nodes from downloading it every time. This may save some time for the download, but the upload has to happen anyway. And if you don't use shared storage for nova (e.g. for live-migration) you may encounter that some compute nodes are quicker creating an instance because they only have to upload, others will first have to download, convert and then upload it.
>>> 
>>> You would see the conversion in the logs of cinder:
>>> 
>>> INFO cinder.image.image_utils [req-f2062570-4006-464b-a1f5-d0d5ac34670d d71f59600f1c40c394022738d4864915 31b9b4900a4d4bdaabaf263d0b4021be - - -] Converted 2252.00 MB image at 757.52 MB/s
>>> 
>>> Hope this helps.
>>> 
>>> Eugen
>>> 
>>> 
>>> Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:
>>> 
>>>> Sunday morning: my openstack works?. OUF.
>>>> the "kolla-ansible -i multimode mariadb_recovery"  command (which is magic anyway) fixed the problem and then the mariadb and nova containers started.
>>>> Once solved the problems between my serv3 and the iscsi bay, restart the container glance, everything seems to work.
>>>> 
>>>>> 4 minutes to create a 20GB empty volume seems too long to me. For an actual 20GB image, it's going to depend on the speed of the backing storage tech.
>>>> 4 minutes is for a volume from an image. I will see this problem next summer , I will retry to change the MTU value.
>>>> 
>>>> Thanks a lot, really
>>>> 
>>>> 
>>>> Franck
>>>> 
>>>>> Le 5 f?vr. 2022 ? 17:08, Laurent Dumont <laurentfdumont at gmail.com> a ?crit :
>>>>> 
>>>>> Any chance to revert back switches + server? That would indicate that MTU was the issue.
>>>>> Dont ping the iscsi bay, ping between the controllers in Openstack, they are the ones running mariadb/galera.
>>>>> Since the icmp packets are small, it might not trigger the MTU issues. Can you try something like "ping -s 8972 -M do -c 4 $mariadb_host_2" from $ mariadb_host_1?
>>>>> What is your network setup on the servers? Two ports in a bond? Did you change both physical interface MTU + bond interface itself?
>>>>> 
>>>>> 4 minutes to create a 20GB empty volume seems too long to me. For an actual 20GB image, it's going to depend on the speed of the backing storage tech.
>>>>> 
>>>>> On Sat, Feb 5, 2022 at 1:51 AM Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>>>> Thanks for your help.
>>>>> 
>>>>> 
>>>>>> What was the starting value for MTU?
>>>>> 1500
>>>>>> What was the starting value changed to for MTU?
>>>>> 9000
>>>>>> Can ping between all your controllers?
>>>>> yes, all container starts except nova-conductor, nova-scheduler, maraidb
>>>>> 
>>>>> 
>>>>>> Do you just have two controllers running mariadb?
>>>>> yes
>>>>>> How did you change MTU?
>>>>> 
>>>>> On the 3 servers:
>>>>> nmcli connection modify team0-port1 802-3-ethernet.mtu 9000
>>>>> nmcli connection modify team1-port2 802-3-ethernet.mtu 9000
>>>>> nmcli connection modify type team0 team.runner lack ethernet.mtu 9000
>>>>> nmcli con down team0
>>>>> nmcli con down team1
>>>>> 
>>>>> 
>>>>>> Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)
>>>>> I didn?t change Mtu on network (switches) , but ping -s 10.0.5.117 (iscsi bay) was working from serv3.
>>>>> 
>>>>> I changed the value of the mtu because the creation of the volumes takes a lot of time I find (4 minutes for 20G, which is too long for what I want to do, the patience of the students decreases with the years)
>>>>> 
>>>>> Franck
>>>>> 
>>>>>> Le 4 f?vr. 2022 ? 23:12, Laurent Dumont <laurentfdumont at gmail.com <mailto:laurentfdumont at gmail.com>> a ?crit :
>>>>>> 
>>>>>> What was the starting value for MTU?
>>>>>> What was the starting value changed to for MTU?
>>>>>> Can ping between all your controllers?
>>>>>> Do you just have two controllers running mariadb?
>>>>>> How did you change MTU?
>>>>>> Was the change reverted at the network level as well (switches need to be configured higher or at the same MTU value then the servers)
>>>>>> 4567 seems to be the port for galera (clustering for mariadb) <>
>>>>>> On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>>>>> Hello,
>>>>>> I am in an emergency situation, quite catastrophic situation because I do not know what to do.
>>>>>> 
>>>>>> I have an Openstack cluster with 3 servers (serv1, serv2, serv3). He was doing so well?
>>>>>> 
>>>>>> 
>>>>>> A network admin came to me and told me to change an MTU on the cards. I knew it shouldn't be done...I shouldn't have done it.
>>>>>> I did it.
>>>>>> Of course, it didn't work as expected. I went back to my starting configuration and there I have a big problem with mariadb which is set up on serv1 and serv2.
>>>>>> 
>>>>>> Here are my errors:
>>>>>> 
>>>>>> 
>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
>>>>>> 	 at gcomm/src/pc.cpp:connect():160
>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out)
>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': <> -110 (Connection timed out)
>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed: Connection timed out
>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567 <>) failed: 7
>>>>>> 2022-02-04 17:40:36 0 [ERROR] Aborting
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I do not know what to do. My installation is done with kolla-ansible, mariadb docker restarts every 30 seconds.
>>>>>> 
>>>>>> Can the "kolla-ansible reconfigure mariadb" command be a solution?
>>>>>> Could the command "kolla-ansible mariadb recovery" be a solution?
>>>>>> 
>>>>>> Thanks in advance if you can help me.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Franck
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220212/aea1dec4/attachment-0001.htm>

From satish.txt at gmail.com  Sat Feb 12 14:31:19 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Sat, 12 Feb 2022 09:31:19 -0500
Subject: nova rabbitmq strange bug
In-Reply-To: <20220211141145.Horde.IKvAmCrL6OKIsbZyAjRGa8C@webmail.nde.ag>
References: <20220211141145.Horde.IKvAmCrL6OKIsbZyAjRGa8C@webmail.nde.ag>
Message-ID: <871E483F-33E8-4C5F-91B2-72E1853245DA@gmail.com>

This is what I did, I am not very expert in rabbitMQ debugging where I can trace back message via ID or something. If there is a any good way then let me know I will give it a try. 

Finally I did following to recover after 24 hour. Shutdown all nova service first, api, conductor, scheduler etc. then I wipe out my rabbitMQ completely including mnesia and then rebuild cluster and then start nova service one by one. 

After that I didn?t see any issue in all my compute nodes. No error and nothing and they came back clean. 

Im trying to reproduce same incident in lab to see if I can get that condition. I don?t know what is the relationship here so I have to stop all nova service in order to rebuild rabbitMQ. We have 200 compute nodes in this cluster do you think that could be the issue because they are constantly trying to talk to rabbit and it was down?

I have one more openstack deployment running on queens and it?s 250 node cloud and I rebuild rabbitMQ million times but never ever had issue like I had with wallaby. 



Sent from my iPhone

> On Feb 11, 2022, at 9:11 AM, Eugen Block <eblock at nde.ag> wrote:
> 
> ?So 'rabbitmqctl cluster_status' show the expected output? Can you trace back the request ID (req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b) and see if it was completed? Usually I see nova recovering after a rabbit outage, this would be unexpected. One more thing, you wrote you're seeing these messages today but you pasted messages from yesterday. Is nova still logging those messages?
> 
> Zitat von Satish Patel <satish.txt at gmail.com>:
> 
>> RabbitMQ logs are very clean and all info logging. It?s feel like something is broken between conductor and nova-compute. Compute is saying waiting for message ID.
>> 
>> May be I rebuild rabbit during that time nova-conductor was keep trying to connect or doing something and when rabbit back then some message stuck in queue half way. I don?t know the flow so just making up some theory.
>> 
>> All computes showing same logs but waiting for different message ID. Is nova-compute talk to conductor and wait for ack reply or not?
>> 
>> Sent from my iPhone
>> 
>>>> On Feb 11, 2022, at 5:39 AM, Eugen Block <eblock at nde.ag> wrote:
>>> 
>>> ?What do the rabbit logs reveal?
>>> 
>>> 
>>> Zitat von Satish Patel <satish.txt at gmail.com>:
>>> 
>>>> Folks,
>>>> 
>>>> I am running wallaby and Today i had rabbitMQ issue and i rebuild
>>>> RabbitMQ. but now my all compute node throwing following error. not
>>>> sure what is going on up they are not trying to come up and keep
>>>> crashing with following error
>>>> 
>>>> 
>>>> 2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> [req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b - - - - -] Error starting
>>>> thread.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting
>>>> for a reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> Traceback (most recent call last):
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>> line 433, in get
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> return self._queues[msg_id].get(block=True, timeout=timeout)
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
>>>> line 322, in get
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> return waiter.wait()
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
>>>> line 141, in wait
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> return get_hub().switch()
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/hubs/hub.py",
>>>> line 313, in switch
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> return self.greenlet.switch()
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> _queue.Empty
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service During
>>>> handling of the above exception, another exception occurred:
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> Traceback (most recent call last):
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_service/service.py",
>>>> line 807, in run_service
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> service.start()
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/service.py",
>>>> line 159, in start
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> self.manager.init_host()
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/compute/manager.py",
>>>> line 1413, in init_host
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> self.driver.init_host(host=self.host)
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
>>>> line 792, in init_host
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> self._register_instance_machine_type()
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
>>>> line 811, in _register_instance_machine_type
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service     for
>>>> instance in objects.InstanceList.get_by_host(context, hostname):
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_versionedobjects/base.py",
>>>> line 175, in wrapper
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> result = cls.indirection_api.object_class_action_versions(
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/conductor/rpcapi.py",
>>>> line 240, in object_class_action_versions
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> return cctxt.call(context, 'object_class_action_versions',
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/rpc/client.py",
>>>> line 175, in call
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> self.transport._send(self.target, msg_ctxt, msg,
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/transport.py",
>>>> line 123, in _send
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> return self._driver.send(target, ctxt, message,
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>> line 680, in send
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> return self._send(target, ctxt, message, wait_for_reply, timeout,
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>> line 669, in _send
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> result = self._waiter.wait(msg_id, timeout,
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>> line 559, in wait
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> message = self.waiters.get(msg_id, timeout=timeout)
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>> line 435, in get
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> raise oslo_messaging.MessagingTimeout(
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>> oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a
>>>> reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>>>> 
>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>> 
>>> 
>>> 
>>> 
> 
> 
> 


From sandeepggn93 at gmail.com  Sat Feb 12 16:04:28 2022
From: sandeepggn93 at gmail.com (Sandeep Yadav)
Date: Sat, 12 Feb 2022 21:34:28 +0530
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <8b8ea100-7119-eb46-0156-0e069fe3a131@redhat.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
 <8b8ea100-7119-eb46-0156-0e069fe3a131@redhat.com>
Message-ID: <CAONAEX-ZotJqzkhN2M26nXHv6hp1UKQOCEYyoh32UxFJxjGAnQ@mail.gmail.com>

+1

On Sat, 12 Feb, 2022, 7:37 AM Harald Jensas, <hjensas at redhat.com> wrote:

> +1
>
> On 2/10/22 15:35, Jose Luis Franco Arza wrote:
> > Hello folks,
> >
> > I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer
> > on the TripleO repositories related to the upgrades workflow
> > (openstack/tripleo-heat-templates, openstack/tripleo-ansible,
> > openstack/python-tripleoclient, openstack/tripleo-ci,
> > openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras).
> > Sergii has been working in OpenStack for the last 10 years, he is
> > already core-reviewer of thetripleo-upgrade
> > <https://github.com/openstack/tripleo-upgrade>repository in which he is
> > providing with very valuable feedback, as well as helping getting
> > relevant patches merged.
> >
> > His deep knowledge of the different OpenStack projects, as well as his
> > involvement in the upgrades/updates workflows for the last 9 OpenStack
> > releases makes him a great code reviewer, being able to catch several
> > issues during the code review process.
> >
> > I will monitor the thread for a week and if no objections are exposed I
> > will add him to the tripleo-core group.
> >
> > PD: Here comes the +1 from my side.
> >
> > Thanks.
> >
> > Cheers,
> > Jos? Luis
> >
> > [1]:https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> > <https://review.opendev.org/q/owner:sgolovat%2540redhat.com>
> > [2]:
> >
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> > <
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> >
> > [3]: Position #25 in the most active TripleO contributors list
> > <
> https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220212/774c397d/attachment.htm>

From rosmaita.fossdev at gmail.com  Sat Feb 12 19:38:46 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Sat, 12 Feb 2022 14:38:46 -0500
Subject: [cinder] final reviews needed for os-brick yoga release
Message-ID: <4580dbb3-cabf-c4e5-ce11-4f0d764b714e@gmail.com>

Hello Argonauts,

We are now aiming to release on Tuesday 15 Feb at 20:00 UTC.

The list of patches needing review and some comments on their status is 
here:
   https://etherpad.opendev.org/p/os-brick-yoga-release

We're in mostly good shape, just need a final sprint to close this out.

reviewers: please review!

patch authors: please keep an eye on your patches and respond quickly 
and make sure your CI has responded with success


thanks,
brian


From syedammad83 at gmail.com  Sun Feb 13 18:28:28 2022
From: syedammad83 at gmail.com (Ammad Syed)
Date: Sun, 13 Feb 2022 23:28:28 +0500
Subject: [neutron] lldpd Errors
Message-ID: <CAKOoz51Vu_BYj-jt=14zgWh9tg4tMVoNEuyGWDviRwsRY-B_Ug@mail.gmail.com>

Hello,

I am using ovn 21.09 with neutron 19.0. I am continuously seeing below
lldpd errors in my journalctl and syslog of compute nodes. Is there
anything to worry about?

Feb 13 21:17:29 computehost02 lldpd[5025]: MSAP has changed for port
tap30b18e08-00, sending a shutdown LLDPDU
Feb 13 21:17:29 computehost02 lldpd[5025]: unable to send packet on real
device for tap30b18e08-00: No such device or address
Feb 13 21:17:29 computehost02 lldpd[5025]: unable to send packet on real
device for tap48d8e15e-ee: No such device or address
Feb 13 21:17:59 computehost02 lldpd[5025]: unable to send packet on real
device for tap48d8e15e-ee: No such device or address
Feb 13 21:17:59 computehost02 lldpd[5025]: MSAP has changed for port
tap30b18e08-00, sending a shutdown LLDPDU

Ammad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220213/dd6a546d/attachment.htm>

From radoslaw.piliszek at gmail.com  Sun Feb 13 20:14:56 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Sun, 13 Feb 2022 21:14:56 +0100
Subject: [tc][release] Removing TC tags framework - next steps for release
 notes
Message-ID: <CAKZ_x795heRnzJuFRXGLBC7jE5kuwHoDjvDD5zBa+k9xYSUeCw@mail.gmail.com>

Hello Release Team,

As you might have heard, the TC is removing the TC tags framework. [1]
The first step has already been proposed and is being voted on. [2]

The removal of certain parts seems to be affecting the release team
tooling, especially with the usage of the stable:follows-policy tag to
show a relevant banner. [3]
The proposed change purposely avoids breaking the releases repo and
awaits a "part 2" which cleans up everything
TC-tags-framework-related.

Thus, I am asking for your help to remove this dependency on the tags framework.
I understand there might be several approaches to this and need your
assistance to continue.
The simplest approach is to drop the relevant code - assuming it is
not actively used for release process purposes.
Obviously, for anything else I need your input on what the options are.
It is also possible that you would prefer to port this tag to your
internal metadata.
I am open to ideas and will help enact the changes.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.html
[2] https://review.opendev.org/c/openstack/governance/+/822900
[3] https://opendev.org/openstack/releases/src/commit/768a12e233c23999db18c807c228b6ec0b042eea/openstack_releases/cmds/list_changes.py#L303

Kind regards,
-yoctozepto


From hanguangyu2 at gmail.com  Mon Feb 14 02:20:22 2022
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Mon, 14 Feb 2022 10:20:22 +0800
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
 <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
 <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>
Message-ID: <CAOirdiUPkXOVZDg8DgrOMDeK8xJxPGcbsu4Y+XPVCbbjJOGCDg@mail.gmail.com>

Hi Arne and Julia,

You make me feel so warm. Best wishes to you.

I have tried to boot the node into a CentOS7, but it still coundnot to
find disk. And sorry that I didn't notice the RAID card.

# lspci -v
...
23:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108
[Invader] (rev 02)
        Subsystem: Broadcom / LSI MegaRAID SAS 9361-8i
        Flags: bus master, fast devsel, latency 0, IRQ -2147483648, NUMA node 1
        I/O ports at 3000 [size=256]
        Memory at e9900000 (64-bit, non-prefetchable) [size=64K]
        Memory at e9700000 (64-bit, non-prefetchable) [size=1M]
        Expansion ROM at e9800000 [disabled] [size=1M]
        Capabilities: [50] Power Management version 3
        Capabilities: [68] Express Endpoint, MSI 00
        Capabilities: [d0] Vital Product Data
        Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [1e0] #19
        Capabilities: [1c0] Power Budgeting <?>
        Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
        Kernel driver in use: megaraid_sas
        Kernel modules: megaraid_sas
...

I try to config raid fallowing
https://docs.openstack.org/ironic/latest/admin/raid.html
by `baremetal node set $NODE_UUID --target-raid-config raid.json`. The
server have  three same disk(Western Digital DC HA210 2TB SATA 6GB/s)
# cat raid.json
{
  "logical_disks": [
    {
      "size_gb": "MAX",
      "raid_level": "0",
      "is_root_volume": true
    }
  ]
}

But Ironic still coundn't see disk. I still got
```
## In deploy images
# journalctl -fxeu ironic-python-agent
Feb 14 02:17:22 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
02:17:22.863 2329 WARNING root [-] Path /dev/disk/by-path is
inaccessible, /dev/disk/by-path/* version of block device name is
unavailable Cause: [Errno 2] No such file or directory:
'/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
directory: '/dev/disk/by-path'
Feb 14 02:17:44 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
02:17:44.391 2329 ERROR root [-] Unexpected error dispatching
get_os_install_device to manager
<ironic_python_agent.hardware.GenericHardwareManager object at
0x7efbf4da2208>: Error finding the disk or partition device to deploy
the image onto: No suitable device was found for deployment - root
device hints were not provided and all found block devices are smaller
than 4294967296B.: ironic_python_agent.errors.DeviceNotFound: Error
finding the disk or partition device to deploy the image onto: No
suitable device was found for deployment - root device hints were not
provided and all found block devices are smaller than 4294967296B.
```

I don't know if it's a lack of a RAID card driver or a lack of a disk
driver or a lack of RAID configuration. Could you have some idea about
this question?

love you,
Han Guangyu


Julia Kreger <juliaashleykreger at gmail.com> ?2022?2?10??? 23:11???

>
> If the disk controllers *are* enumerated in the kernel log, which is
> something to also look for, then the disks themselves may be in some
> weird state like security locked. Generally this shows up as the
> operating system kind of sees the disk and the SATA port connected but
> can't really access it. This is also an exceptionally rare state to
> find one's self in.
>
> More common, especially in enterprise grade hardware: If the disk
> controller is actually a raid controller, and there are no raid
> volumes configured, then the operating system likely cannot see the
> underlying disks and turn that into a usable block device. I've seen a
> couple drivers over the years which expose hints of disks in the
> kernel log and without raid configuration in the cards, the drivers
> can't present usable block devices to the operating system system.
>
> -Julia
>
> On Thu, Feb 10, 2022 at 3:17 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
> >
> > Hi Guangyu,
> >
> > No worries about asking questions, this is what the mailing
> > list is for :)
> >
> > Just to clarify, you do not have to set root device hints,
> > it also works without (with the algorithm I mentioned).
> > However, hints help to define the exact device and/or make
> > deployment more predictable/repeatable.
> >
> > If it is really a driver problem, it is an issue with the
> > operating system of the image you use, i.e. CentOS8. Some
> > drivers were removed from 7 to 8, and we have seen issues
> > with specific drive models as well.
> >
> > You can try to build your own IPA images as described in
> > [1], e.g. to add your ssh key to be able to log into the
> > IPA to debug further, and to eventually include drivers
> > (if you can identify them and they are available for CentOS8).
> >
> > Another option may be to add another (newer) disk model to
> > the server, just to confirm it is the disk model/driver which
> > is the cause.
> >
> > You could also try to boot the node into a CentOS7 (and then
> > a CentOS8) live image to confirm it can see the disks at all.
> >
> > Hope this helps!
> >   Arne
> >
> > [1]
> > https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html
> >
> >
> > On 10.02.22 11:15, ??? wrote:
> > > Hi Arne,
> > >
> > > Thank you very much for your response. Love you. You take away a lot
> > > of my confusion.
> > >
> > > You are right, I didn't set 'root device'. And Ironic also can not see
> > > disk, the content of the 'lsblk' file in the deploy los is emply.
> > > I tried to set 'root device', but because ironic can't find any disk,
> > > the deploy still filed.
> > >
> > > Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > > 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
> > > inaccessible, /dev/disk/by-path/* version of block device name is
> > > unavailable Cause: [Errno 2] No such file or directory:
> > > '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> > > directory: '/dev/disk/by-path'
> > > Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > > 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
> > > matches the root device hints {'wwn': '0x50014EE2691D724C'}:
> > > StopIteration
> > >
> > > Sorry to bother you, I'm a newcomer of Ironic and I didn't find
> > > information about it on google.
> > >
> > > The bare metal node have three same disk(Western Digital DC HA210 2TB
> > > SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
> > > this disk?
> > >
> > > And If Ironic cannot find disk since the corresponding drivers in the
> > > IPA image are missing, do you know how to resolve it? I have used the
> > > latest deploy images in
> > > https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
> > > .  Do I need to find and manually add driver in the source code or
> > > ramdisk(That was difficult tome)?
> > >
> > > Love you.
> > >
> > > Cheers,
> > > Guangyu
> > >
> > > Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
> > >>
> > >> Hi Guangyu,
> > >>
> > >> The error indicates that Ironic was not able to find
> > >> a device where it could deploy the image to.
> > >>
> > >> To find a device, Ironic will use 'root device'
> > >> hints [1], usually set by the admin on a node. If that
> > >> does not yield anything, Ironic will loop over all
> > >> block devices and pick the smallest which is larger
> > >> than 4GB (and order them alphabetically).
> > >>
> > >> If you have disks in your server which are larger than
> > >> 4GB, one potential explanation is that Ironic cannot see them,
> > >> e.g. since the corresponding drivers in the IPA image are missing.
> > >> The logs you posted seem to confirm something along those
> > >> lines.
> > >>
> > >> Check the content of the 'lsblk' file in the deploy logs which
> > >> you can find in the tar archive in /var/log/ironic/deploy/
> > >> on the controller for your deployment attempt to see what
> > >> devices Ironic has access to.
> > >>
> > >> Cheers,
> > >>    Arne
> > >>
> > >>
> > >> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
> > >>
> > >> On 10.02.22 02:50, ??? wrote:
> > >>> Dear all,
> > >>>
> > >>> I have a OpenStack Victoria environment, and tried to use ironic
> > >>> manage bare metal. But I got "- root device hints were not provided
> > >>> and all found block devices are smaller than 4294967296B." in deploy
> > >>> stage.
> > >>>
> > >>> 2022-02-09 17:57:56.492 3908982 ERROR
> > >>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
> > >>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
> > >>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
> > >>> No suitable device was found for deployment - root device hints were
> > >>> not provided and all found block devices are smaller than
> > >>> 4294967296B..
> > >>>
> > >>> I used "openstack server create --flavor my-baremetal-flavor --nic
> > >>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
> > >>> download deploy images(ipa-centos8-master.kernel and
> > >>> ipa-centos8-master.initramfs) in
> > >>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
> > >>>
> > >>> The baremetal node info and flavor info as following:
> > >>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
> > >>> Ironic configure file as following:
> > >>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
> > >>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
> > >>> The log of ironic-python-agent in bare metal node:
> > >>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
> > >>>
> > >>> I see some old discussion about this, such as:
> > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
> > >>> discussions took place a long time ago, not version V, and no solution
> > >>> was seen.
> > >>>
> > >>> Does anyone know how to solve this problem? I would appreciate any
> > >>> kind of guidance or help.
> > >>>
> > >>> Thank you,
> > >>> Han Guangyu
> > >>>
> >


From ly2008080808 at yeah.net  Mon Feb 14 02:54:48 2022
From: ly2008080808 at yeah.net (liyang)
Date: Mon, 14 Feb 2022 10:54:48 +0800 (CST)
Subject: oslo.messaging integration development
Message-ID: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>

Hi  everyone,
    I find Apache Pulsar is very popular in MQ area, especially in clound native area. Is there any body integrate this MQ to oslo.messaging?
    Said to the truth. RabbitMQ developed in Erlang has very little source code level material, Qpid has very little operation practice in the internet. Kafka only support notification in oslo.messaging.
    I think the Apache Pulsar  is clound native based. It may enforece the big scale in extension about Openstack deployment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/45a80fef/attachment.htm>

From flux.adam at gmail.com  Mon Feb 14 06:55:55 2022
From: flux.adam at gmail.com (Adam Harwell)
Date: Mon, 14 Feb 2022 15:55:55 +0900
Subject: oslo.messaging integration development
In-Reply-To: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
Message-ID: <CAHxXnhcGbcOsZf6LBGspsaWSQy4pkTfXYp4oQCkz4rFMZvMLSg@mail.gmail.com>

Hey! It?s cool to see someone else talking about this. My team considered
this, and personally I think it would work very well, we just didn?t have
the development resources to throw at the problem on our own. I think it?s
likely that we could participate in a larger discussion about it though,
and possibly help here and there if someone else was driving it.

   ?Adam

On Mon, Feb 14, 2022 at 11:59 liyang <ly2008080808 at yeah.net> wrote:

> Hi  everyone,
>     I find Apache Pulsar is very popular in MQ area, especially in clound
> native area. Is there any body integrate this MQ to oslo.messaging?
>     Said to the truth. RabbitMQ developed in Erlang has very little source
> code level material, Qpid has very little operation practice in the
> internet. Kafka only support notification in oslo.messaging.
>     I think the Apache Pulsar  is clound native based. It may enforece the
> big scale in extension about Openstack deployment.
>
>
>
>
-- 
Thanks,
    --Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/e16ec0f4/attachment-0001.htm>

From ly2008080808 at yeah.net  Mon Feb 14 07:18:25 2022
From: ly2008080808 at yeah.net (liyang)
Date: Mon, 14 Feb 2022 15:18:25 +0800 (CST)
Subject: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D:Re:_oslo.messaging_integration_development?=
In-Reply-To: <CAHxXnhcGbcOsZf6LBGspsaWSQy4pkTfXYp4oQCkz4rFMZvMLSg@mail.gmail.com>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
 <CAHxXnhcGbcOsZf6LBGspsaWSQy4pkTfXYp4oQCkz4rFMZvMLSg@mail.gmail.com>
Message-ID: <107e6cd3.1227.17ef718cf82.Coremail.ly2008080808@yeah.net>

Hi, Thanks to rely. I found this link should be very helpful to us. https://streamnative.io/en/blog/tech/2020-06-15-announcing-aop-on-pulsar/ .



? 2022-02-14 14:55:55?"Adam Harwell" <flux.adam at gmail.com> ???

Hey! It?s cool to see someone else talking about this. My team considered this, and personally I think it would work very well, we just didn?t have the development resources to throw at the problem on our own. I think it?s likely that we could participate in a larger discussion about it though, and possibly help here and there if someone else was driving it.


   ?Adam


On Mon, Feb 14, 2022 at 11:59 liyang <ly2008080808 at yeah.net> wrote:

Hi  everyone,
    I find Apache Pulsar is very popular in MQ area, especially in clound native area. Is there any body integrate this MQ to oslo.messaging?
    Said to the truth. RabbitMQ developed in Erlang has very little source code level material, Qpid has very little operation practice in the internet. Kafka only support notification in oslo.messaging.
    I think the Apache Pulsar  is clound native based. It may enforece the big scale in extension about Openstack deployment.




 

--

Thanks,
    --Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/30a466e2/attachment.htm>

From ly2008080808 at yeah.net  Mon Feb 14 07:20:42 2022
From: ly2008080808 at yeah.net (liyang)
Date: Mon, 14 Feb 2022 15:20:42 +0800 (CST)
Subject: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D:=E5=9B=9E=E5=A4=8D:Re:_oslo.messaging?=
 =?UTF-8?Q?_integration_development?=
In-Reply-To: <107e6cd3.1227.17ef718cf82.Coremail.ly2008080808@yeah.net>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
 <CAHxXnhcGbcOsZf6LBGspsaWSQy4pkTfXYp4oQCkz4rFMZvMLSg@mail.gmail.com>
 <107e6cd3.1227.17ef718cf82.Coremail.ly2008080808@yeah.net>
Message-ID: <3dbed8c4.1241.17ef71ae627.Coremail.ly2008080808@yeah.net>

I think if we deploy Apache pulsar with AOP in cluster & HA, the effect will be ok. I am going to ready practise this schema.



? 2022-02-14 15:18:25?"liyang" <ly2008080808 at yeah.net> ???

Hi, Thanks to rely. I found this link should be very helpful to us. https://streamnative.io/en/blog/tech/2020-06-15-announcing-aop-on-pulsar/ .



? 2022-02-14 14:55:55?"Adam Harwell" <flux.adam at gmail.com> ???

Hey! It?s cool to see someone else talking about this. My team considered this, and personally I think it would work very well, we just didn?t have the development resources to throw at the problem on our own. I think it?s likely that we could participate in a larger discussion about it though, and possibly help here and there if someone else was driving it.


   ?Adam


On Mon, Feb 14, 2022 at 11:59 liyang <ly2008080808 at yeah.net> wrote:

Hi  everyone,
    I find Apache Pulsar is very popular in MQ area, especially in clound native area. Is there any body integrate this MQ to oslo.messaging?
    Said to the truth. RabbitMQ developed in Erlang has very little source code level material, Qpid has very little operation practice in the internet. Kafka only support notification in oslo.messaging.
    I think the Apache Pulsar  is clound native based. It may enforece the big scale in extension about Openstack deployment.




 

--

Thanks,
    --Adam




 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/f41cf069/attachment.htm>

From flux.adam at gmail.com  Mon Feb 14 07:39:04 2022
From: flux.adam at gmail.com (Adam Harwell)
Date: Mon, 14 Feb 2022 16:39:04 +0900
Subject: =?UTF-8?B?UmU6IOWbnuWkjTpSZTogb3Nsby5tZXNzYWdpbmcgaW50ZWdyYXRpb24gZGV2ZWxvcG1lbg==?=
 =?UTF-8?B?dA==?=
In-Reply-To: <3dbed8c4.1241.17ef71ae627.Coremail.ly2008080808@yeah.net>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
 <CAHxXnhcGbcOsZf6LBGspsaWSQy4pkTfXYp4oQCkz4rFMZvMLSg@mail.gmail.com>
 <107e6cd3.1227.17ef718cf82.Coremail.ly2008080808@yeah.net>
 <3dbed8c4.1241.17ef71ae627.Coremail.ly2008080808@yeah.net>
Message-ID: <CAHxXnhf=Ye7qE1dgNEz=6FT7bWqid28H7Le12YcW-qUV1aowXA@mail.gmail.com>

I wonder if the limitation of forced durable queues will make things too
slow? Right now I believe it?s recommended to not use queues in durable
mode with openstack (if I recall correctly)?

Also, it does add to the setup side of things, as it would require
explicitly creating each vhost in Pulsar ahead of deployment, but that
might not matter if people don?t use a ton of vhosts (we use one per
service, but that?s not actually too many I suppose, and certainly isn?t
required). I guess a lot of deployments may only use a single vhost?

On Mon, Feb 14, 2022 at 16:21 liyang <ly2008080808 at yeah.net> wrote:

> I think if we deploy Apache pulsar with AOP in cluster & HA, the effect
> will be ok. I am going to ready practise this schema.
>
> ? 2022-02-14 15:18:25?"liyang" <ly2008080808 at yeah.net> ???
>
> Hi, Thanks to rely. I found this link should be very helpful to us.
> https://streamnative.io/en/blog/tech/2020-06-15-announcing-aop-on-pulsar/
> .
>
> ? 2022-02-14 14:55:55?"Adam Harwell" <flux.adam at gmail.com> ???
>
> Hey! It?s cool to see someone else talking about this. My team considered
> this, and personally I think it would work very well, we just didn?t have
> the development resources to throw at the problem on our own. I think it?s
> likely that we could participate in a larger discussion about it though,
> and possibly help here and there if someone else was driving it.
>
>    ?Adam
>
> On Mon, Feb 14, 2022 at 11:59 liyang <ly2008080808 at yeah.net> wrote:
>
>> Hi  everyone,
>>     I find Apache Pulsar is very popular in MQ area, especially in clound
>> native area. Is there any body integrate this MQ to oslo.messaging?
>>     Said to the truth. RabbitMQ developed in Erlang has very little
>> source code level material, Qpid has very little operation practice in the
>> internet. Kafka only support notification in oslo.messaging.
>>     I think the Apache Pulsar  is clound native based. It may enforece
>> the big scale in extension about Openstack deployment.
>>
>>
>>
>>
> --
> Thanks,
>     --Adam
>
>
>
>
>
>
>
>
>
-- 
Thanks,
    --Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/4012f9ee/attachment.htm>

From openstack at a.spamming.party  Mon Feb 14 07:42:03 2022
From: openstack at a.spamming.party (JP E)
Date: Mon, 14 Feb 2022 08:42:03 +0100
Subject: [all][tc] Relmgt team position on release cadence
In-Reply-To: <17ee46051c6.12bb64653143256.163506775198229925@ghanshyammann.com>
References: <40f6f51b-6903-1afe-7318-0689b2af482d@openstack.org>
 <8301ef05-4011-43e9-beec-66f6aeeb00f9@www.fastmail.com>
 <20211129130957.3poysdeqsufkp3pg@yuggoth.org>
 <f2c4ab93-a1e1-475c-8b35-1b303b8fb96b@www.fastmail.com>
 <d28fc7ccfecd753561e1d395c672e987f95eb748.camel@redhat.com>
 <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com>
 <CAF7gwdiUF2wj7RqN-LzwvwH1FQ1A7j=F-CikHKS0ct8AKNAdJg@mail.gmail.com>
 <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org>
 <CAF7gwdhnS_101_Ljf++V=-jGwKZ_NUm6gn+Jzo_N-VDwDuvayw@mail.gmail.com>
 <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com>
 <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
 <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>
 <fc5569d6-15e6-4d33-b0f4-2d619f90e732@www.fastmail.com>
 <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com>
 <17ee46051c6.12bb64653143256.163506775198229925@ghanshyammann.com>
Message-ID: <830769aa-4a5a-407f-9668-7f28bf5f3bfd@www.fastmail.com>

I am sorry I didn?t see this in time. ?Tomorrow? is a short notice ;)

Can you link to the meetings notes, please ?

Regards,
JP


From arne.wiebalck at cern.ch  Mon Feb 14 07:59:24 2022
From: arne.wiebalck at cern.ch (Arne Wiebalck)
Date: Mon, 14 Feb 2022 08:59:24 +0100
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <CAOirdiUPkXOVZDg8DgrOMDeK8xJxPGcbsu4Y+XPVCbbjJOGCDg@mail.gmail.com>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
 <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
 <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>
 <CAOirdiUPkXOVZDg8DgrOMDeK8xJxPGcbsu4Y+XPVCbbjJOGCDg@mail.gmail.com>
Message-ID: <ca926b29-9dff-cceb-5734-7d510a48a045@cern.ch>

Hi Guangyu,

It seems like Julia had the right idea and the disks
are not visible since the RAID controller does not
expose anything to the operating system. This seems
to be confirmed by you booting into the CentOS7 image.

What I would suggest to try next is to look for the
hardware RAID config option during the initial boot
sequence to enter the RAID config menu (there should be
a message quite early on, and maybe Ctrl-H is needed
to enter the menu).

Once there, manually configure the disks as JBODs or
create a RAID device. Upon reboot this should be visible
and accessible as a device. Maybe check from your CentOS7
image again. If the devices are there, Ironic should
also be able to deploy on them (for this you can remove
the RAID config you added).

It depends a little on what your goal is, but I would
try this first to see if you can make a device visible
and if the Ironic deploy bit works, before trying to
configure the hardware RAID via Ironic.

Cheers,
  Arne

On 14.02.22 03:20, ??? wrote:
> Hi Arne and Julia,
> 
> You make me feel so warm. Best wishes to you.
> 
> I have tried to boot the node into a CentOS7, but it still coundnot to
> find disk. And sorry that I didn't notice the RAID card.
> 
> # lspci -v
> ...
> 23:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108
> [Invader] (rev 02)
>          Subsystem: Broadcom / LSI MegaRAID SAS 9361-8i
>          Flags: bus master, fast devsel, latency 0, IRQ -2147483648, NUMA node 1
>          I/O ports at 3000 [size=256]
>          Memory at e9900000 (64-bit, non-prefetchable) [size=64K]
>          Memory at e9700000 (64-bit, non-prefetchable) [size=1M]
>          Expansion ROM at e9800000 [disabled] [size=1M]
>          Capabilities: [50] Power Management version 3
>          Capabilities: [68] Express Endpoint, MSI 00
>          Capabilities: [d0] Vital Product Data
>          Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
>          Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
>          Capabilities: [100] Advanced Error Reporting
>          Capabilities: [1e0] #19
>          Capabilities: [1c0] Power Budgeting <?>
>          Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
>          Kernel driver in use: megaraid_sas
>          Kernel modules: megaraid_sas
> ...
> 
> I try to config raid fallowing
> https://docs.openstack.org/ironic/latest/admin/raid.html
> by `baremetal node set $NODE_UUID --target-raid-config raid.json`. The
> server have  three same disk(Western Digital DC HA210 2TB SATA 6GB/s)
> # cat raid.json
> {
>    "logical_disks": [
>      {
>        "size_gb": "MAX",
>        "raid_level": "0",
>        "is_root_volume": true
>      }
>    ]
> }
> 
> But Ironic still coundn't see disk. I still got
> ```
> ## In deploy images
> # journalctl -fxeu ironic-python-agent
> Feb 14 02:17:22 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> 02:17:22.863 2329 WARNING root [-] Path /dev/disk/by-path is
> inaccessible, /dev/disk/by-path/* version of block device name is
> unavailable Cause: [Errno 2] No such file or directory:
> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> directory: '/dev/disk/by-path'
> Feb 14 02:17:44 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> 02:17:44.391 2329 ERROR root [-] Unexpected error dispatching
> get_os_install_device to manager
> <ironic_python_agent.hardware.GenericHardwareManager object at
> 0x7efbf4da2208>: Error finding the disk or partition device to deploy
> the image onto: No suitable device was found for deployment - root
> device hints were not provided and all found block devices are smaller
> than 4294967296B.: ironic_python_agent.errors.DeviceNotFound: Error
> finding the disk or partition device to deploy the image onto: No
> suitable device was found for deployment - root device hints were not
> provided and all found block devices are smaller than 4294967296B.
> ```
> 
> I don't know if it's a lack of a RAID card driver or a lack of a disk
> driver or a lack of RAID configuration. Could you have some idea about
> this question?
> 
> love you,
> Han Guangyu
> 
> 
> Julia Kreger <juliaashleykreger at gmail.com> ?2022?2?10??? 23:11???
> 
>>
>> If the disk controllers *are* enumerated in the kernel log, which is
>> something to also look for, then the disks themselves may be in some
>> weird state like security locked. Generally this shows up as the
>> operating system kind of sees the disk and the SATA port connected but
>> can't really access it. This is also an exceptionally rare state to
>> find one's self in.
>>
>> More common, especially in enterprise grade hardware: If the disk
>> controller is actually a raid controller, and there are no raid
>> volumes configured, then the operating system likely cannot see the
>> underlying disks and turn that into a usable block device. I've seen a
>> couple drivers over the years which expose hints of disks in the
>> kernel log and without raid configuration in the cards, the drivers
>> can't present usable block devices to the operating system system.
>>
>> -Julia
>>
>> On Thu, Feb 10, 2022 at 3:17 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
>>>
>>> Hi Guangyu,
>>>
>>> No worries about asking questions, this is what the mailing
>>> list is for :)
>>>
>>> Just to clarify, you do not have to set root device hints,
>>> it also works without (with the algorithm I mentioned).
>>> However, hints help to define the exact device and/or make
>>> deployment more predictable/repeatable.
>>>
>>> If it is really a driver problem, it is an issue with the
>>> operating system of the image you use, i.e. CentOS8. Some
>>> drivers were removed from 7 to 8, and we have seen issues
>>> with specific drive models as well.
>>>
>>> You can try to build your own IPA images as described in
>>> [1], e.g. to add your ssh key to be able to log into the
>>> IPA to debug further, and to eventually include drivers
>>> (if you can identify them and they are available for CentOS8).
>>>
>>> Another option may be to add another (newer) disk model to
>>> the server, just to confirm it is the disk model/driver which
>>> is the cause.
>>>
>>> You could also try to boot the node into a CentOS7 (and then
>>> a CentOS8) live image to confirm it can see the disks at all.
>>>
>>> Hope this helps!
>>>    Arne
>>>
>>> [1]
>>> https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html
>>>
>>>
>>> On 10.02.22 11:15, ??? wrote:
>>>> Hi Arne,
>>>>
>>>> Thank you very much for your response. Love you. You take away a lot
>>>> of my confusion.
>>>>
>>>> You are right, I didn't set 'root device'. And Ironic also can not see
>>>> disk, the content of the 'lsblk' file in the deploy los is emply.
>>>> I tried to set 'root device', but because ironic can't find any disk,
>>>> the deploy still filed.
>>>>
>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
>>>> 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
>>>> inaccessible, /dev/disk/by-path/* version of block device name is
>>>> unavailable Cause: [Errno 2] No such file or directory:
>>>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
>>>> directory: '/dev/disk/by-path'
>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
>>>> 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
>>>> matches the root device hints {'wwn': '0x50014EE2691D724C'}:
>>>> StopIteration
>>>>
>>>> Sorry to bother you, I'm a newcomer of Ironic and I didn't find
>>>> information about it on google.
>>>>
>>>> The bare metal node have three same disk(Western Digital DC HA210 2TB
>>>> SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
>>>> this disk?
>>>>
>>>> And If Ironic cannot find disk since the corresponding drivers in the
>>>> IPA image are missing, do you know how to resolve it? I have used the
>>>> latest deploy images in
>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
>>>> .  Do I need to find and manually add driver in the source code or
>>>> ramdisk(That was difficult tome)?
>>>>
>>>> Love you.
>>>>
>>>> Cheers,
>>>> Guangyu
>>>>
>>>> Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
>>>>>
>>>>> Hi Guangyu,
>>>>>
>>>>> The error indicates that Ironic was not able to find
>>>>> a device where it could deploy the image to.
>>>>>
>>>>> To find a device, Ironic will use 'root device'
>>>>> hints [1], usually set by the admin on a node. If that
>>>>> does not yield anything, Ironic will loop over all
>>>>> block devices and pick the smallest which is larger
>>>>> than 4GB (and order them alphabetically).
>>>>>
>>>>> If you have disks in your server which are larger than
>>>>> 4GB, one potential explanation is that Ironic cannot see them,
>>>>> e.g. since the corresponding drivers in the IPA image are missing.
>>>>> The logs you posted seem to confirm something along those
>>>>> lines.
>>>>>
>>>>> Check the content of the 'lsblk' file in the deploy logs which
>>>>> you can find in the tar archive in /var/log/ironic/deploy/
>>>>> on the controller for your deployment attempt to see what
>>>>> devices Ironic has access to.
>>>>>
>>>>> Cheers,
>>>>>     Arne
>>>>>
>>>>>
>>>>> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
>>>>>
>>>>> On 10.02.22 02:50, ??? wrote:
>>>>>> Dear all,
>>>>>>
>>>>>> I have a OpenStack Victoria environment, and tried to use ironic
>>>>>> manage bare metal. But I got "- root device hints were not provided
>>>>>> and all found block devices are smaller than 4294967296B." in deploy
>>>>>> stage.
>>>>>>
>>>>>> 2022-02-09 17:57:56.492 3908982 ERROR
>>>>>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
>>>>>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
>>>>>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
>>>>>> No suitable device was found for deployment - root device hints were
>>>>>> not provided and all found block devices are smaller than
>>>>>> 4294967296B..
>>>>>>
>>>>>> I used "openstack server create --flavor my-baremetal-flavor --nic
>>>>>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
>>>>>> download deploy images(ipa-centos8-master.kernel and
>>>>>> ipa-centos8-master.initramfs) in
>>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
>>>>>>
>>>>>> The baremetal node info and flavor info as following:
>>>>>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
>>>>>> Ironic configure file as following:
>>>>>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
>>>>>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
>>>>>> The log of ironic-python-agent in bare metal node:
>>>>>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
>>>>>>
>>>>>> I see some old discussion about this, such as:
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
>>>>>> discussions took place a long time ago, not version V, and no solution
>>>>>> was seen.
>>>>>>
>>>>>> Does anyone know how to solve this problem? I would appreciate any
>>>>>> kind of guidance or help.
>>>>>>
>>>>>> Thank you,
>>>>>> Han Guangyu
>>>>>>
>>>


From zhangbailin at inspur.com  Mon Feb 14 09:08:38 2022
From: zhangbailin at inspur.com (=?gb2312?B?QnJpbiBaaGFuZyjVxbDZwdYp?=)
Date: Mon, 14 Feb 2022 09:08:38 +0000
Subject: [election][Cyborg]PTL candidacy for Z
Message-ID: <b2a13c943f96490eb08d3b64d8258079@inspur.com>

Hi all,



I write to submit my candidacy for the Cyborg PTL position during the Z cycle.



I have been PTL for the Yoga cycle, and I would like to serve the community

for another cycle.



In yoga cycle, we have competed get device profile by name, clearly resource

provide, updated devices, deployables' API docs, etc.. But we also have some

new feature need to trace, e.g. vGPU support (splite a new spec wit usage of

new trait of OWNER_NOVA, need to be down with Nova team), add xilinx FPGA

driver, and add the UT to cover many scenarios.



Another thing is to attract more contributors to the Cyborg contribution, to

increase the activity of the Cyborg project, although I have started to do so.



In summary, I want to keep the stability and diversity of accelerator devices

in OpenStack.



Best regards for you.



Brin Zhang (brinzhang)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/c6bd2c42/attachment.htm>

From bcafarel at redhat.com  Mon Feb 14 09:35:09 2022
From: bcafarel at redhat.com (Bernard Cafarelli)
Date: Mon, 14 Feb 2022 10:35:09 +0100
Subject: [neutron] Bug deputy report (week starting on 2022-02-07)
Message-ID: <CABHdKwpzBTxUQnnoxkq2suz-c4gkujHZj24umMokAVaN_fT6Sw@mail.gmail.com>

Hi neutrinos,

I was bug deputy last week, here is the list of reported bugs
A quiet week overall, no high importance bugs without assignee

High
* [fullstack] Test "test_east_west_traffic" randomly failing -
https://bugs.launchpad.net/neutron/+bug/1960338
  Mostly affecting Wallaby,
https://review.opendev.org/c/openstack/neutron/+/828231 backports seem to
have helped
* "ovn_agent._run_process" ovs-appctl fails setting the service log
configuration - https://bugs.launchpad.net/neutron/+bug/1960514
  devstack deployment issue for DPDK environments, OVN_BUILD_MODULES=True,
patch by ralonsoh https://review.opendev.org/c/openstack/devstack/+/828877

Medium
* snat is used instead of dnat_and_snat when L3GW resides on chassis -
https://bugs.launchpad.net/neutron/+bug/1960405
  elvira is checking this bug
* [OVN] OVN_BUILD_MODULES/OVN_BUILD_FROM_SOURCE differences -
https://bugs.launchpad.net/neutron/+bug/1960397
  An ask-for-opinion bug on these variables, are they both needed?

Low
* Logging service writing errors in the logs when RPC required -
https://bugs.launchpad.net/neutron/+bug/1960533
  Service itself works fine, but it is better not to generate this kind of
error message

-- 
Bernard Cafarelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/279a98fc/attachment-0001.htm>

From thierry at openstack.org  Mon Feb 14 09:54:11 2022
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 14 Feb 2022 10:54:11 +0100
Subject: [largescale-sig] Next meeting: Feb 16th, 15utc
Message-ID: <97e918c6-a74c-ae38-dce1-ff738c95d989@openstack.org>

Hi everyone,

The Large Scale SIG will be meeting this Wednesday in 
#openstack-operators on OFTC IRC, at 15UTC.

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

We'll look back at the new format for the Large Scale OpenStack show and 
discuss the next episode.

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

Regards,

-- 
Thierry Carrez


From zigo at debian.org  Mon Feb 14 10:17:56 2022
From: zigo at debian.org (Thomas Goirand)
Date: Mon, 14 Feb 2022 11:17:56 +0100
Subject: [neutron] lldpd Errors
In-Reply-To: <CAKOoz51Vu_BYj-jt=14zgWh9tg4tMVoNEuyGWDviRwsRY-B_Ug@mail.gmail.com>
References: <CAKOoz51Vu_BYj-jt=14zgWh9tg4tMVoNEuyGWDviRwsRY-B_Ug@mail.gmail.com>
Message-ID: <f3356eb6-eeb6-4b73-5240-06fb552dece7@debian.org>

On 2/13/22 19:28, Ammad Syed wrote:
> Hello,
> 
> I am using ovn 21.09 with neutron 19.0. I am continuously?seeing below 
> lldpd errors in my journalctl and syslog of compute nodes. Is there 
> anything to worry about?
> 
> Feb 13 21:17:29 computehost02 lldpd[5025]: MSAP has changed for port 
> tap30b18e08-00, sending a shutdown LLDPDU
> Feb 13 21:17:29 computehost02 lldpd[5025]: unable to send packet on real 
> device for tap30b18e08-00: No such device or address
> Feb 13 21:17:29 computehost02 lldpd[5025]: unable to send packet on real 
> device for tap48d8e15e-ee: No such device or address
> Feb 13 21:17:59 computehost02 lldpd[5025]: unable to send packet on real 
> device for tap48d8e15e-ee: No such device or address
> Feb 13 21:17:59 computehost02 lldpd[5025]: MSAP has changed for port 
> tap30b18e08-00, sending a shutdown LLDPDU
> 
> Ammad

I'd suggest adding this to your setup so you're not annoyed anymore:

# cat /etc/lldpd.d/only-eth.conf
configure system interface pattern eth*

That's what OCI [1] does by default.

Cheers,

Thomas Goirand (zigo)

[1] 
https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer


From zigo at debian.org  Mon Feb 14 10:23:14 2022
From: zigo at debian.org (Thomas Goirand)
Date: Mon, 14 Feb 2022 11:23:14 +0100
Subject: [tooz] [mistral] Tenacity >= 8.0.1 issues (in Debian)
Message-ID: <f861039e-d0c5-6ca5-e69e-b7a969717457@debian.org>

Hi,

It seems Tenacity has some incompatible changes leading to this:

https://bugs.debian.org/1005636 (tooz)
https://bugs.debian.org/1005467 (mistral)

Note that both Manila and Heat were fixed already for this last version 
of Tenacity, so these would likely be the only remaining blockers to 
upgrade to 8.0.1.

As Tenacity 8.0.1 is already in Debian Unstable, I'd prefer if we fixed 
these rather than pinning to a lower version.

Can anyone help?

Cheers,

Thomas Goirand (zigo)


From zigo at debian.org  Mon Feb 14 11:22:18 2022
From: zigo at debian.org (Thomas Goirand)
Date: Mon, 14 Feb 2022 12:22:18 +0100
Subject: oslo.messaging integration development
In-Reply-To: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
Message-ID: <f739af94-55ba-114c-ea8a-0129126b2676@debian.org>

On 2/14/22 03:54, liyang wrote:
> Hi? everyone,
>  ? ? I find Apache Pulsar is very popular in MQ area, especially in 
> clound native area. Is there any body integrate this MQ to oslo.messaging?
>  ? ? Said to the truth. RabbitMQ developed in Erlang has very little 
> source code level?material, Qpid has very little?operation practice in 
> the internet. Kafka only support notification in oslo.messaging.
>  ? ? I think the Apache Pulsar? is clound native based. It may enforece 
> the big?scale in extension about Openstack deployment.

Between Erlang and Java, I very much prefer that Java stays away from my 
clusters. We already have Zookeeper and I'd very much love to get rid of 
it (but no choice...).

Isn't there any better implementation of message queuing somewhere?!?

Cheers,

Thomas Goirand (zigo)


From elod.illes at est.tech  Mon Feb 14 11:39:28 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Mon, 14 Feb 2022 12:39:28 +0100
Subject: [tc][release] Removing TC tags framework - next steps for release
 notes
In-Reply-To: <CAKZ_x795heRnzJuFRXGLBC7jE5kuwHoDjvDD5zBa+k9xYSUeCw@mail.gmail.com>
References: <CAKZ_x795heRnzJuFRXGLBC7jE5kuwHoDjvDD5zBa+k9xYSUeCw@mail.gmail.com>
Message-ID: <cc65fbdd-c1f5-6539-0382-607de45439eb@est.tech>

Hi,

As far as I know the 'follows-stable-policy' tag is now works as kind of 
a reminder for release management team that the given deliverables needs 
some extra attention that it does not violate the stable policy. Though 
for example I always try to review the release content in this respect. 
For me this was a good indicator, but on the other hand, maybe it is not 
that relevant for the release team nowadays. If the TC decided that tags 
will be removed, I'm not against it. So I think it's OK to drop it.

Regarding what needs to be done in release repository: I proposed a 
simple clean up script [1]. I think there is nothing else to do.

@Release Management Team: let me know if you see something else that i 
might missed.

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

Cheers,

El?d
(irc: elodilles @ #openstack-release)


On 2022. 02. 13. 21:14, Rados?aw Piliszek wrote:
> Hello Release Team,
>
> As you might have heard, the TC is removing the TC tags framework. [1]
> The first step has already been proposed and is being voted on. [2]
>
> The removal of certain parts seems to be affecting the release team
> tooling, especially with the usage of the stable:follows-policy tag to
> show a relevant banner. [3]
> The proposed change purposely avoids breaking the releases repo and
> awaits a "part 2" which cleans up everything
> TC-tags-framework-related.
>
> Thus, I am asking for your help to remove this dependency on the tags framework.
> I understand there might be several approaches to this and need your
> assistance to continue.
> The simplest approach is to drop the relevant code - assuming it is
> not actively used for release process purposes.
> Obviously, for anything else I need your input on what the options are.
> It is also possible that you would prefer to port this tag to your
> internal metadata.
> I am open to ideas and will help enact the changes.
>
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.html
> [2] https://review.opendev.org/c/openstack/governance/+/822900
> [3] https://opendev.org/openstack/releases/src/commit/768a12e233c23999db18c807c228b6ec0b042eea/openstack_releases/cmds/list_changes.py#L303
>
> Kind regards,
> -yoctozepto
>

From florian at citynetwork.eu  Mon Feb 14 12:41:51 2022
From: florian at citynetwork.eu (Florian Haas)
Date: Mon, 14 Feb 2022 13:41:51 +0100
Subject: [openstacksdk][magnum] Adding get_coe_cluster_by_id() method to
 openstack.cloud._coe
Message-ID: <9983785c-d456-abd0-c696-c77b6bde1ee6@citynetwork.eu>

Hi everyone,

here's something I recently ran into while playing with openstacksdk 
against Magnum; I could use some help/feedback there if anyone's 
inclined. :)

It looks as though openstacksdk, which presently doesn't include 
get_coe_cluster_by_id() in cloud._coe[1], will effectively only ever 
list clusters and then filter client-side, as opposed to looking up 
individual clusters directly. That means that it only ever hits the 
Magnum API's /v1/clusters URL[2], which provides only limited properties 
on each cluster it returns.

Were it to implement get_coe_cluster_by_id(), then any Connection object 
that has use_direct_get set to True could hit /v1/clusters/<uuid> 
instead[3], which provides a much richer set of properties.

I have submitted a patch for this[4], but I have a couple of open questions:

(1) I'm not quite sure what's the proper way to test that 
get_coe_cluster() actually invokes get_coe_cluster_by_id() when passed a 
UUID. Normally I'd do that with unittest.mock's assert_called() method, 
but openstacksdk heavily wraps various mock.patch() calls so I'm sure 
there's a better, preferred way to do it for the openstacksdk codebase.

(2) Even if implementing get_coe_cluster_by_id() is the correct approach 
(which I am entirely not sure of), it still strikes me as a bit 
unintuitive that there are additional details that could be retrieved 
only if use_direct_get is set on the Connection object. I think having 
an explicit "get me more detail" toggle on the call would be preferable, 
which would hit /v1/clusters first (to retrieve the cluster UUID from 
the name), and then hit /v1/clusters/<uuid> to retrieve the rich set of 
properties. Now, the docstring for search_coe_clusters() mentions a 
"detail" parameter[5], but that appears to be a bit of a red herring as 
that method doesn't actually use that param. So I'm a bit stuck and 
unsure what to do there. :)

If anyone has thoughts on this they'd like to share, I'd be most grateful!

Cheers,
Florian


References:
[1] 
https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_coe.py
[2] 
https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=list-all-clusters-detail#list-all-clusters
[3] 
https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=list-all-clusters-detail#show-details-of-a-cluster
[4] https://review.opendev.org/c/openstack/openstacksdk/+/828791
[5] 
https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_coe.py#L52


From eblock at nde.ag  Mon Feb 14 13:25:40 2022
From: eblock at nde.ag (Eugen Block)
Date: Mon, 14 Feb 2022 13:25:40 +0000
Subject: nova rabbitmq strange bug
In-Reply-To: <871E483F-33E8-4C5F-91B2-72E1853245DA@gmail.com>
References: <20220211141145.Horde.IKvAmCrL6OKIsbZyAjRGa8C@webmail.nde.ag>
 <871E483F-33E8-4C5F-91B2-72E1853245DA@gmail.com>
Message-ID: <20220214132540.Horde.0KZbeneopEuHAjiGtJdzb2R@webmail.nde.ag>

Hi,

> This is what I did, I am not very expert in rabbitMQ debugging where  
> I can trace back message via ID or something. If there is a any good  
> way then let me know I will give it a try.

you'll find the request ID across the respective services, so if you  
grep for that ID in the log neutron, nova, cinder, etc. directories  
you'll likely be able to find out which services tried to do what.

> Im trying to reproduce same incident in lab to see if I can get that  
> condition. I don?t know what is the relationship here so I have to  
> stop all nova service in order to rebuild rabbitMQ. We have 200  
> compute nodes in this cluster do you think that could be the issue  
> because they are constantly trying to talk to rabbit and it was down?

All openstack services try to talk to rabbit all the time, not only  
nova. You'll notice a "transport_url" in all service config files. And  
yes, if rabbit is down the services will complain. But as I already  
wrote, usually they recover eventually, although there might be some  
timeout you may have hit, I'm not sure. Or this is indeed an issue  
with Wallaby, I didn't have the chance to install it yet, the latest  
version I'm working with is Victoria, and there the recovery seems to  
work as expected. Have you check launchpad for existing bugs?


Zitat von Satish Patel <satish.txt at gmail.com>:

> This is what I did, I am not very expert in rabbitMQ debugging where  
> I can trace back message via ID or something. If there is a any good  
> way then let me know I will give it a try.
>
> Finally I did following to recover after 24 hour. Shutdown all nova  
> service first, api, conductor, scheduler etc. then I wipe out my  
> rabbitMQ completely including mnesia and then rebuild cluster and  
> then start nova service one by one.
>
> After that I didn?t see any issue in all my compute nodes. No error  
> and nothing and they came back clean.
>
> Im trying to reproduce same incident in lab to see if I can get that  
> condition. I don?t know what is the relationship here so I have to  
> stop all nova service in order to rebuild rabbitMQ. We have 200  
> compute nodes in this cluster do you think that could be the issue  
> because they are constantly trying to talk to rabbit and it was down?
>
> I have one more openstack deployment running on queens and it?s 250  
> node cloud and I rebuild rabbitMQ million times but never ever had  
> issue like I had with wallaby.
>
>
>
> Sent from my iPhone
>
>> On Feb 11, 2022, at 9:11 AM, Eugen Block <eblock at nde.ag> wrote:
>>
>> ?So 'rabbitmqctl cluster_status' show the expected output? Can you  
>> trace back the request ID  
>> (req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b) and see if it was  
>> completed? Usually I see nova recovering after a rabbit outage,  
>> this would be unexpected. One more thing, you wrote you're seeing  
>> these messages today but you pasted messages from yesterday. Is  
>> nova still logging those messages?
>>
>> Zitat von Satish Patel <satish.txt at gmail.com>:
>>
>>> RabbitMQ logs are very clean and all info logging. It?s feel like  
>>> something is broken between conductor and nova-compute. Compute is  
>>> saying waiting for message ID.
>>>
>>> May be I rebuild rabbit during that time nova-conductor was keep  
>>> trying to connect or doing something and when rabbit back then  
>>> some message stuck in queue half way. I don?t know the flow so  
>>> just making up some theory.
>>>
>>> All computes showing same logs but waiting for different message  
>>> ID. Is nova-compute talk to conductor and wait for ack reply or not?
>>>
>>> Sent from my iPhone
>>>
>>>>> On Feb 11, 2022, at 5:39 AM, Eugen Block <eblock at nde.ag> wrote:
>>>>
>>>> ?What do the rabbit logs reveal?
>>>>
>>>>
>>>> Zitat von Satish Patel <satish.txt at gmail.com>:
>>>>
>>>>> Folks,
>>>>>
>>>>> I am running wallaby and Today i had rabbitMQ issue and i rebuild
>>>>> RabbitMQ. but now my all compute node throwing following error. not
>>>>> sure what is going on up they are not trying to come up and keep
>>>>> crashing with following error
>>>>>
>>>>>
>>>>> 2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> [req-6c3cdaa3-ecf9-4bef-9def-6b6a69dfd30b - - - - -] Error starting
>>>>> thread.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting
>>>>> for a reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> Traceback (most recent call last):
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>>> line 433, in get
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> return self._queues[msg_id].get(block=True, timeout=timeout)
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
>>>>> line 322, in get
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> return waiter.wait()
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/queue.py",
>>>>> line 141, in wait
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> return get_hub().switch()
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/eventlet/hubs/hub.py",
>>>>> line 313, in switch
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> return self.greenlet.switch()
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> _queue.Empty
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service During
>>>>> handling of the above exception, another exception occurred:
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> Traceback (most recent call last):
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_service/service.py",
>>>>> line 807, in run_service
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> service.start()
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/service.py",
>>>>> line 159, in start
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> self.manager.init_host()
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/compute/manager.py",
>>>>> line 1413, in init_host
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> self.driver.init_host(host=self.host)
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
>>>>> line 792, in init_host
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> self._register_instance_machine_type()
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/virt/libvirt/driver.py",
>>>>> line 811, in _register_instance_machine_type
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service     for
>>>>> instance in objects.InstanceList.get_by_host(context, hostname):
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_versionedobjects/base.py",
>>>>> line 175, in wrapper
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> result = cls.indirection_api.object_class_action_versions(
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/nova/conductor/rpcapi.py",
>>>>> line 240, in object_class_action_versions
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> return cctxt.call(context, 'object_class_action_versions',
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/rpc/client.py",
>>>>> line 175, in call
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> self.transport._send(self.target, msg_ctxt, msg,
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/transport.py",
>>>>> line 123, in _send
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> return self._driver.send(target, ctxt, message,
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>>> line 680, in send
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> return self._send(target, ctxt, message, wait_for_reply, timeout,
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>>> line 669, in _send
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> result = self._waiter.wait(msg_id, timeout,
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>>> line 559, in wait
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> message = self.waiters.get(msg_id, timeout=timeout)
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service   File
>>>>> "/openstack/venvs/nova-23.1.1/lib/python3.8/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>>>> line 435, in get
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> raise oslo_messaging.MessagingTimeout(
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>> oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a
>>>>> reply to message ID 9510bd6c0d6a48e782ed7bc2887f32c8
>>>>>
>>>>>  2022-02-10 00:52:27.843 3660531 ERROR oslo_service.service
>>>>
>>>>
>>>>
>>>>
>>
>>
>>





From eblock at nde.ag  Mon Feb 14 13:30:12 2022
From: eblock at nde.ag (Eugen Block)
Date: Mon, 14 Feb 2022 13:30:12 +0000
Subject: [kolla-ansible][nova] volume creation time
In-Reply-To: <6339B870-49E9-4B56-B666-F3003D1E97BD@univ-grenoble-alpes.fr>
References: <20220209081211.Horde.WAVvbmDzp-FEZWmNHXHb6GR@webmail.nde.ag>
 <6339B870-49E9-4B56-B666-F3003D1E97BD@univ-grenoble-alpes.fr>
Message-ID: <20220214133012.Horde.l4tUZE6NmlUQMK3TrMN1j31@webmail.nde.ag>

Hi,

> my openstack being operational and must absolutely be ok for several  
> months (student projects), I don't touch it...
>
> In France we have the saying "Scalded cat fears cold water ?

I understand :-)

> But I put all this information aside. I will have to look at this  
> more closely, and especially that I change storage by switching to  
> ceph.

Although Ceph might be challenging at the beginning I'm a big fan of  
it and can only encourage you to do that.


Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:

> Thank you for your help.
>
> my openstack being operational and must absolutely be ok for several  
> months (student projects), I don't touch it...
>
> In France we have the saying "Scalded cat fears cold water ?
>
> But I put all this information aside. I will have to look at this  
> more closely, and especially that I change storage by switching to  
> ceph.
> Thanks again Eugen
>
> Franck
>> Le 9 f?vr. 2022 ? 09:12, Eugen Block <eblock at nde.ag> a ?crit :
>>
>> I haven't used iscsi as a backend yet, but for HDDs the speed looks  
>> relatable, on a system with HDD ceph backend the volume creation of  
>> a volume (image is 2 GB) takes about 40 seconds, as you yee the  
>> download is quite slow, the conversion is a little faster:
>>
>> Image download 541.00 MB at 28.14 MB/s
>> Converted 2252.00 MB image at 172.08 MB/s
>>
>> With a factor of 10 (20 GB) I would probably end up with similar  
>> creation times. Just for comparison, this is almost the same image  
>> (also 2 GB) in a different ceph cluster where I mounted the cinder  
>> conversion path from cephfs, SSD pool:
>>
>> Image download 555.12 MB at 41.34 MB/s
>> Converted 2252.00 MB image at 769.17 MB/s
>>
>> This volume was created within 20 seconds. You might also want to  
>> tweak these options:
>>
>> block_device_allocate_retries = 300
>> block_device_allocate_retries_interval = 10
>>
>> These are the defaults:
>>
>> block_device_allocate_retries = 60
>> block_device_allocate_retries_interval = 3
>>
>> This would fit your error message:
>>
>>> Volume be0f28eb-1045-4687-8bdb-5a6d385be6fa did not finish being  
>>> created even after we waited 187 seconds or 61 attempts. And its  
>>> status is downloading.
>>
>> It tried 60 times with a 3 second interval, apparently that's not  
>> enough. Can you see any bottlenecks in the network or disk  
>> utilization which would slow down the download?
>>
>>
>> Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:
>>
>>> Hi Eugen,
>>> thanks for your help
>>> We have 3 servers (s1, s2 , s3) and an iscsi bay attached on s3.
>>> Multinode:
>>> [control]
>>> s1
>>> s2
>>>
>>> [compute]
>>> s1
>>> s2
>>> s3
>>>
>>> [storage]
>>> s3
>>>
>>> on s1: more /etc/kolla/globals.yml
>>> ...
>>> enable_cinder: "yes"
>>> enable_cinder_backend_iscsi: "yes"
>>> enable_cinder_backend_lvm: ? yes"
>>> enable_iscsid: ? yes"
>>> cinder_volume_group: "cinder-volumes ?
>>> ...
>>> enable_glance_image_cache: "yes"
>>> glance_cache_max_size: "21474836480"
>>> glance_file_datadir_volume: ? /images/?
>>> ...
>>>
>>> on s3:  /images is on the iscsi bay
>>> mount |grep images
>>> /dev/mapper/VG--IMAGES-LV--IMAGES on /images type xfs  
>>> (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=1024,swidth=1024,noquota)
>>>
>>> lsblk
>>> sdf                                                                 
>>>              8:80   0   500G  0 disk
>>> ??mpathc                                                            
>>>            253:3    0   500G  0 mpath
>>> ??mpathc1                                                           
>>>          253:4    0   500G  0 part
>>>   ??VG--IMAGES-LV--IMAGES                                           
>>>          253:5    0   500G  0 lvm   /images
>>>
>>>
>>> ls -l /images:
>>> drwxr-x---. 5 42415 42415 4096  6 f?vr. 18:40 image-cache
>>> drwxr-x---. 2 42415 42415 4096  4 f?vr. 15:16 images
>>> drwxr-x---. 2 42415 42415    6 22 nov.  12:03 staging
>>> drwxr-x---. 2 42415 42415    6 22 nov.  12:03 tasks_work_dir
>>>
>>> ls -l /images/image-cache
>>> total 71646760
>>> -rw-r-----. 1 42415 42415   360841216  2 d?c.  11:52  
>>> 3e3aada8-7610-4c55-b116-a12db68f8ea4
>>> -rw-r-----. 1 42415 42415   237436928 28 nov.  16:56  
>>> 6419642b-fcbd-4e5d-9c77-46a48d2af93f
>>> -rw-r-----. 1 42415 42415 10975379456 26 nov.  14:59  
>>> 7490e914-8001-4d56-baea-fabf80f425e1
>>> -rw-r-----. 1 42415 42415 21474836480 22 nov.  16:46  
>>> 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5
>>> -rw-r-----. 1 42415 42415  2694512640 15 d?c.  18:07  
>>> 890fd2e8-2fac-42c6-956b-6b10f2253a56
>>> -rw-r-----. 1 42415 42415 12048400384  1 d?c.  17:04  
>>> 9a235763-ff0c-40fd-9a8d-7cdca3d3e9ce
>>> -rw-r-----. 1 42415 42415  5949227008 15 d?c.  20:41  
>>> 9cbba37b-1de1-482a-87f2-631d2143cd46
>>> -rw-r-----. 1 42415 42415   566994944  6 d?c.  12:32  
>>> b6e29dd9-a66d-4569-a222-6fc0bd9b1b11
>>> -rw-r-----. 1 42415 42415   578748416  2 d?c.  11:24  
>>> c40953ee-4b39-43a5-8f6c-b48a046c38e9
>>> -rw-r-----. 1 42415 42415    16300544 27 janv. 12:19  
>>> c88630c7-a7c6-44ff-bfa0-e5af4b1720e3
>>> -rw-r-----. 1 42415 42415       12288  6 f?vr. 18:40 cache.db
>>> -rw-r-----. 1 42415 42415 12324503552  1 d?c.  07:50  
>>> e0d4fddd-5aa7-4177-a1d6-e6b4c56f12e8
>>> -rw-r-----. 1 42415 42415  6139084800 22 nov.  15:05  
>>> eda93204-9846-4216-a6e8-c29977fdcf2f
>>> -rw-r-----. 1 42415 42415           0 22 nov.  12:03 image_cache_db_init
>>> drwxr-x---. 2 42415 42415           6 27 janv. 12:19 incomplete
>>> drwxr-x---. 2 42415 42415           6 22 nov.  12:03 invalid
>>> drwxr-x---. 2 42415 42415           6 22 nov.  12:03 queue
>>>
>>> on s1
>>> openstack image list
>>> +--------------------------------------+-----------------------------+--------+
>>> | ID                                   | Name                       
>>>   | Status |
>>> +--------------------------------------+-----------------------------+--------+
>>> ?..
>>> | 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5 | rocky8.4                   
>>>   | active |
>>> ?.
>>> | 7490e914-8001-4d56-baea-fabf80f425e1 | win10_2104                 
>>>   | active |
>>> ?.
>>> +???????????????????+-----------------------------+????+
>>>
>>>
>>> openstack image show 7fc7f9a6-ab0e-45cf-9c29-7e59f6aa68a5
>>> disk_format      | raw
>>>
>>> when I try to add an instance from this image (2G RAM, 40G HDD):
>>> [Error : Build of instance baa06bef-9628-407f-8bae-500ef7bce065  
>>> aborted: Volume be0f28eb-1045-4687-8bdb-5a6d385be6fa did not  
>>> finish being created even after we waited 187 seconds or 61  
>>> attempts. And its status is downloading.
>>>
>>> it?s impossible. I need to add the volume from image first, and  
>>> after add instance from volume.
>>>
>>> Is it normal ?
>>>
>>>
>>> Franck
>>>
>>>> Le 7 f?vr. 2022 ? 10:55, Eugen Block <eblock at nde.ag> a ?crit :
>>>>
>>>> Hi Franck,
>>>>
>>>> although it's a different topic than your original question I  
>>>> wanted to comment on the volume creation time (maybe a new thread  
>>>> would make sense). What is your storage back end? If it is ceph,  
>>>> are your images in raw format? Otherwise cinder has to download  
>>>> the image from glance (to /var/lib/cinder/conversion) and convert  
>>>> it, then upload it back to ceph. It's similar with nova, nova  
>>>> stores base images in /var/lib/nova/instances/_base to prevent  
>>>> the compute nodes from downloading it every time. This may save  
>>>> some time for the download, but the upload has to happen anyway.  
>>>> And if you don't use shared storage for nova (e.g. for  
>>>> live-migration) you may encounter that some compute nodes are  
>>>> quicker creating an instance because they only have to upload,  
>>>> others will first have to download, convert and then upload it.
>>>>
>>>> You would see the conversion in the logs of cinder:
>>>>
>>>> INFO cinder.image.image_utils  
>>>> [req-f2062570-4006-464b-a1f5-d0d5ac34670d  
>>>> d71f59600f1c40c394022738d4864915 31b9b4900a4d4bdaabaf263d0b4021be  
>>>> - - -] Converted 2252.00 MB image at 757.52 MB/s
>>>>
>>>> Hope this helps.
>>>>
>>>> Eugen
>>>>
>>>>
>>>> Zitat von Franck VEDEL <franck.vedel at univ-grenoble-alpes.fr>:
>>>>
>>>>> Sunday morning: my openstack works?. OUF.
>>>>> the "kolla-ansible -i multimode mariadb_recovery"  command  
>>>>> (which is magic anyway) fixed the problem and then the mariadb  
>>>>> and nova containers started.
>>>>> Once solved the problems between my serv3 and the iscsi bay,  
>>>>> restart the container glance, everything seems to work.
>>>>>
>>>>>> 4 minutes to create a 20GB empty volume seems too long to me.  
>>>>>> For an actual 20GB image, it's going to depend on the speed of  
>>>>>> the backing storage tech.
>>>>> 4 minutes is for a volume from an image. I will see this problem  
>>>>> next summer , I will retry to change the MTU value.
>>>>>
>>>>> Thanks a lot, really
>>>>>
>>>>>
>>>>> Franck
>>>>>
>>>>>> Le 5 f?vr. 2022 ? 17:08, Laurent Dumont  
>>>>>> <laurentfdumont at gmail.com> a ?crit :
>>>>>>
>>>>>> Any chance to revert back switches + server? That would  
>>>>>> indicate that MTU was the issue.
>>>>>> Dont ping the iscsi bay, ping between the controllers in  
>>>>>> Openstack, they are the ones running mariadb/galera.
>>>>>> Since the icmp packets are small, it might not trigger the MTU  
>>>>>> issues. Can you try something like "ping -s 8972 -M do -c 4  
>>>>>> $mariadb_host_2" from $ mariadb_host_1?
>>>>>> What is your network setup on the servers? Two ports in a bond?  
>>>>>> Did you change both physical interface MTU + bond interface  
>>>>>> itself?
>>>>>>
>>>>>> 4 minutes to create a 20GB empty volume seems too long to me.  
>>>>>> For an actual 20GB image, it's going to depend on the speed of  
>>>>>> the backing storage tech.
>>>>>>
>>>>>> On Sat, Feb 5, 2022 at 1:51 AM Franck VEDEL  
>>>>>> <franck.vedel at univ-grenoble-alpes.fr  
>>>>>> <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>>>>> Thanks for your help.
>>>>>>
>>>>>>
>>>>>>> What was the starting value for MTU?
>>>>>> 1500
>>>>>>> What was the starting value changed to for MTU?
>>>>>> 9000
>>>>>>> Can ping between all your controllers?
>>>>>> yes, all container starts except nova-conductor, nova-scheduler, maraidb
>>>>>>
>>>>>>
>>>>>>> Do you just have two controllers running mariadb?
>>>>>> yes
>>>>>>> How did you change MTU?
>>>>>>
>>>>>> On the 3 servers:
>>>>>> nmcli connection modify team0-port1 802-3-ethernet.mtu 9000
>>>>>> nmcli connection modify team1-port2 802-3-ethernet.mtu 9000
>>>>>> nmcli connection modify type team0 team.runner lack ethernet.mtu 9000
>>>>>> nmcli con down team0
>>>>>> nmcli con down team1
>>>>>>
>>>>>>
>>>>>>> Was the change reverted at the network level as well (switches  
>>>>>>> need to be configured higher or at the same MTU value then the  
>>>>>>> servers)
>>>>>> I didn?t change Mtu on network (switches) , but ping -s  
>>>>>> 10.0.5.117 (iscsi bay) was working from serv3.
>>>>>>
>>>>>> I changed the value of the mtu because the creation of the  
>>>>>> volumes takes a lot of time I find (4 minutes for 20G, which is  
>>>>>> too long for what I want to do, the patience of the students  
>>>>>> decreases with the years)
>>>>>>
>>>>>> Franck
>>>>>>
>>>>>>> Le 4 f?vr. 2022 ? 23:12, Laurent Dumont  
>>>>>>> <laurentfdumont at gmail.com <mailto:laurentfdumont at gmail.com>> a  
>>>>>>> ?crit :
>>>>>>>
>>>>>>> What was the starting value for MTU?
>>>>>>> What was the starting value changed to for MTU?
>>>>>>> Can ping between all your controllers?
>>>>>>> Do you just have two controllers running mariadb?
>>>>>>> How did you change MTU?
>>>>>>> Was the change reverted at the network level as well (switches  
>>>>>>> need to be configured higher or at the same MTU value then the  
>>>>>>> servers)
>>>>>>> 4567 seems to be the port for galera (clustering for mariadb) <>
>>>>>>> On Fri, Feb 4, 2022 at 11:52 AM Franck VEDEL  
>>>>>>> <franck.vedel at univ-grenoble-alpes.fr  
>>>>>>> <mailto:franck.vedel at univ-grenoble-alpes.fr>> wrote:
>>>>>>> Hello,
>>>>>>> I am in an emergency situation, quite catastrophic situation  
>>>>>>> because I do not know what to do.
>>>>>>>
>>>>>>> I have an Openstack cluster with 3 servers (serv1, serv2,  
>>>>>>> serv3). He was doing so well?
>>>>>>>
>>>>>>>
>>>>>>> A network admin came to me and told me to change an MTU on the  
>>>>>>> cards. I knew it shouldn't be done...I shouldn't have done it.
>>>>>>> I did it.
>>>>>>> Of course, it didn't work as expected. I went back to my  
>>>>>>> starting configuration and there I have a big problem with  
>>>>>>> mariadb which is set up on serv1 and serv2.
>>>>>>>
>>>>>>> Here are my errors:
>>>>>>>
>>>>>>>
>>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: failed to open gcomm  
>>>>>>> backend connection: 110: failed to reach primary view: 110  
>>>>>>> (Connection timed out)
>>>>>>> 	 at gcomm/src/pc.cpp:connect():160
>>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>>>>>> gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open  
>>>>>>> backend connection: -110 (Connection timed out)
>>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>>>>>> gcs/src/gcs.cpp:gcs_open():1475: Failed to open channel  
>>>>>>> 'openstack' at 'gcomm://10.0.5.109:4567,10.0.5.110:4567': <>  
>>>>>>> -110 (Connection timed out)
>>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP: gcs connect failed:  
>>>>>>> Connection timed out
>>>>>>> 2022-02-04 17:40:36 0 [ERROR] WSREP:  
>>>>>>> wsrep::connect(gcomm://10.0.5.109:4567,10.0.5.110:4567 <>)  
>>>>>>> failed: 7
>>>>>>> 2022-02-04 17:40:36 0 [ERROR] Aborting
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I do not know what to do. My installation is done with  
>>>>>>> kolla-ansible, mariadb docker restarts every 30 seconds.
>>>>>>>
>>>>>>> Can the "kolla-ansible reconfigure mariadb" command be a solution?
>>>>>>> Could the command "kolla-ansible mariadb recovery" be a solution?
>>>>>>>
>>>>>>> Thanks in advance if you can help me.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Franck
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>





From gthiemon at redhat.com  Mon Feb 14 13:46:48 2022
From: gthiemon at redhat.com (Gregory Thiemonge)
Date: Mon, 14 Feb 2022 14:46:48 +0100
Subject: [election][Octavia][ptl] PTL candidacy for Z
Message-ID: <CAKsmYT1uH4KTb4gCT_u5JykAfAQwO-vo_a_2f4MgTV6phsnp6Q@mail.gmail.com>

Hi,

I would like to nominate myself for Octavia PTL for the Z release cycle.
I am the current PTL and I would like to continue to contribute to this
role.

For the Z release, my plan for Octavia is to enable persistence in taskflow
in
the amphorav2 driver, to start working on HTTP/3 support, to fix old known
issues (handling multiple subnets on the VIP port, fixing multiple subnets
issue on member ports).

Thanks for your consideration,

Gregory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/4defc821/attachment.htm>

From tobias.urdin at binero.com  Mon Feb 14 14:19:39 2022
From: tobias.urdin at binero.com (Tobias Urdin)
Date: Mon, 14 Feb 2022 14:19:39 +0000
Subject: [neutron] lldpd Errors
In-Reply-To: <f3356eb6-eeb6-4b73-5240-06fb552dece7@debian.org>
References: <CAKOoz51Vu_BYj-jt=14zgWh9tg4tMVoNEuyGWDviRwsRY-B_Ug@mail.gmail.com>
 <f3356eb6-eeb6-4b73-5240-06fb552dece7@debian.org>
Message-ID: <FA67DCE9-D3AB-46FE-988E-1152E7B7D174@binero.com>

Hello,

Do what Thomas suggested or disable LLDP because it?s also
possible that you are leaking information about your compute node
to running instances.

Best regards

> On 14 Feb 2022, at 11:17, Thomas Goirand <zigo at debian.org> wrote:
> 
> On 2/13/22 19:28, Ammad Syed wrote:
>> Hello,
>> I am using ovn 21.09 with neutron 19.0. I am continuously seeing below lldpd errors in my journalctl and syslog of compute nodes. Is there anything to worry about?
>> Feb 13 21:17:29 computehost02 lldpd[5025]: MSAP has changed for port tap30b18e08-00, sending a shutdown LLDPDU
>> Feb 13 21:17:29 computehost02 lldpd[5025]: unable to send packet on real device for tap30b18e08-00: No such device or address
>> Feb 13 21:17:29 computehost02 lldpd[5025]: unable to send packet on real device for tap48d8e15e-ee: No such device or address
>> Feb 13 21:17:59 computehost02 lldpd[5025]: unable to send packet on real device for tap48d8e15e-ee: No such device or address
>> Feb 13 21:17:59 computehost02 lldpd[5025]: MSAP has changed for port tap30b18e08-00, sending a shutdown LLDPDU
>> Ammad
> 
> I'd suggest adding this to your setup so you're not annoyed anymore:
> 
> # cat /etc/lldpd.d/only-eth.conf
> configure system interface pattern eth*
> 
> That's what OCI [1] does by default.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> [1] https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
> 


From fungi at yuggoth.org  Mon Feb 14 14:44:47 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 14 Feb 2022 14:44:47 +0000
Subject: [all][tc] Relmgt team position on release cadence
In-Reply-To: <830769aa-4a5a-407f-9668-7f28bf5f3bfd@www.fastmail.com>
References: <CAF7gwdiUF2wj7RqN-LzwvwH1FQ1A7j=F-CikHKS0ct8AKNAdJg@mail.gmail.com>
 <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org>
 <CAF7gwdhnS_101_Ljf++V=-jGwKZ_NUm6gn+Jzo_N-VDwDuvayw@mail.gmail.com>
 <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com>
 <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
 <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>
 <fc5569d6-15e6-4d33-b0f4-2d619f90e732@www.fastmail.com>
 <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com>
 <17ee46051c6.12bb64653143256.163506775198229925@ghanshyammann.com>
 <830769aa-4a5a-407f-9668-7f28bf5f3bfd@www.fastmail.com>
Message-ID: <20220214144447.xarnobufa43tdadq@yuggoth.org>

On 2022-02-14 08:42:03 +0100 (+0100), JP E wrote:
> I am sorry I didn?t see this in time. ?Tomorrow? is a short notice ;)
> 
> Can you link to the meetings notes, please ?

https://etherpad.opendev.org/p/openstackreleasecadence
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/1e2a4e56/attachment.sig>

From lokendrarathour at gmail.com  Mon Feb 14 13:59:18 2022
From: lokendrarathour at gmail.com (Lokendra Rathour)
Date: Mon, 14 Feb 2022 19:29:18 +0530
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAF7gwditOunfQH-Whc1rY8M9bbH52d2xOJK06oeroUCaV-4-cg@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
 <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
 <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>
 <CAJm6b-4+z67on3D94k02m5yN79Yr91TdFyN=vntKmSQNBBK+pQ@mail.gmail.com>
 <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com>
 <CAJm6b-6PYvKPW4AVd19uTmRk=j2Uw-Gh6fjNjDhBOvB0zyMGpg@mail.gmail.com>
 <CAJm6b-5+6=sWB2yXf8-mToBKdA53paSxRiP0WQ9Bqi+Dfnn84w@mail.gmail.com>
 <CAF7gwditOunfQH-Whc1rY8M9bbH52d2xOJK06oeroUCaV-4-cg@mail.gmail.com>
Message-ID: <CAJm6b-6s-Ohrj7yykjZ67Ksv_sy+6hm8hBN2WiG-y=ik-6cd-w@mail.gmail.com>

Hi Julia,
Thanks once again. we got your point and understood the issue, but we still
are facing the same issue on our TRIPLEO Train HA Setup, even if the
settings are done as per your recommendations.

The error that we are seeing is  again "*No valid host was found"*

(overcloud) [stack at undercloud v4]$ openstack server show bm-server
--fit-width
+-------------------------------------+----------------------------------------------------------------------------------------+
| Field                               | Value
                                                   |
+-------------------------------------+----------------------------------------------------------------------------------------+
| OS-DCF:diskConfig                   | MANUAL
                                                    |
| OS-EXT-AZ:availability_zone         |
                                                   |
| OS-EXT-SRV-ATTR:host                | None
                                                    |
| OS-EXT-SRV-ATTR:hostname            | bm-server
                                                   |
| OS-EXT-SRV-ATTR:hypervisor_hostname | None
                                                    |
| OS-EXT-SRV-ATTR:instance_name       | instance-00000014
                                                   |
| OS-EXT-SRV-ATTR:kernel_id           |
                                                   |
| OS-EXT-SRV-ATTR:launch_index        | 0
                                                   |
| OS-EXT-SRV-ATTR:ramdisk_id          |
                                                   |
| OS-EXT-SRV-ATTR:reservation_id      | r-npd6m9ah
                                                    |
| OS-EXT-SRV-ATTR:root_device_name    | None
                                                    |
| OS-EXT-SRV-ATTR:user_data           |
I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnBhc3N3b3JkOiBoc2MzMjEKc3NoX3B3YXV0aDogdH
|
|                                     |
J1ZQptYW5hZ2VfZXRjX2hvc3RzOiB0cnVlCmNocGFzc3dkOiB7ZXhwaXJlOiBmYWxzZSB9Cg==
            |
| OS-EXT-STS:power_state              | NOSTATE
                                                   |
| OS-EXT-STS:task_state               | None
                                                    |
| OS-EXT-STS:vm_state                 | error
                                                   |
| OS-SRV-USG:launched_at              | None
                                                    |
| OS-SRV-USG:terminated_at            | None
                                                    |
| accessIPv4                          |
                                                   |
| accessIPv6                          |
                                                   |
| addresses                           |
                                                   |
| config_drive                        | True
                                                    |
| created                             | 2022-02-14T10:20:48Z
                                                    |
| description                         | None
                                                    |
| fault                               | {'code': 500, 'created':
'2022-02-14T10:20:49Z', 'message': 'No valid host was found.  |
|                                     | There are not enough hosts
available.', 'details': 'Traceback (most recent call        |
|                                     | last):\n  File
"/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line      |
|                                     | 1379, in
schedule_and_build_instances\n    instance_uuids, return_alternates=True)\n
  |
|                                     | File
"/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 839, in
       |
|                                     | _schedule_instances\n
 return_alternates=return_alternates)\n  File                  |
|                                     |
"/usr/lib/python3.6/site-packages/nova/scheduler/client/query.py", line 42,
in         |
|                                     | select_destinations\n
 instance_uuids, return_objects, return_alternates)\n  File    |
|                                     |
"/usr/lib/python3.6/site-packages/nova/scheduler/rpcapi.py", line 160, in
           |
|                                     | select_destinations\n    return
cctxt.call(ctxt, \'select_destinations\',              |
|                                     | **msg_args)\n  File
"/usr/lib/python3.6/site-packages/oslo_messaging/rpc/client.py",   |
|                                     | line 181, in call\n
 transport_options=self.transport_options)\n  File               |
|                                     |
"/usr/lib/python3.6/site-packages/oslo_messaging/transport.py", line 129,
in _send\n   |
|                                     |
transport_options=transport_options)\n  File "/usr/lib/python3.6/site-
            |
|                                     |
packages/oslo_messaging/_drivers/amqpdriver.py", line 674, in send\n
            |
|                                     |
transport_options=transport_options)\n  File "/usr/lib/python3.6/site-
            |
|                                     |
packages/oslo_messaging/_drivers/amqpdriver.py", line 664, in _send\n
 raise         |
|                                     |
result\nnova.exception_Remote.NoValidHost_Remote: No valid host was found.
There are   |
|                                     | not enough hosts
available.\nTraceback (most recent call last):\n\n  File              |
|                                     |
"/usr/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 235,
in inner\n  |
|                                     | return func(*args, **kwargs)\n\n
 File "/usr/lib/python3.6/site-                       |
|                                     |
packages/nova/scheduler/manager.py", line 214, in select_destinations\n
           |
|                                     | allocation_request_version,
return_alternates)\n\n  File "/usr/lib/python3.6/site-     |
|                                     |
packages/nova/scheduler/filter_scheduler.py", line 96, in
select_destinations\n        |
|                                     | allocation_request_version,
return_alternates)\n\n  File "/usr/lib/python3.6/site-     |
|                                     |
packages/nova/scheduler/filter_scheduler.py", line 265, in _schedule\n
            |
|                                     | claimed_instance_uuids)\n\n  File
"/usr/lib/python3.6/site-                            |
|                                     |
packages/nova/scheduler/filter_scheduler.py", line 302, in
_ensure_sufficient_hosts\n  |
|                                     | raise
exception.NoValidHost(reason=reason)\n\nnova.exception.NoValidHost: No
valid     |
|                                     | host was found. There are not
enough hosts available.\n\n'}                            |
| flavor                              | disk='470', ephemeral='0',
                                                    |
|                                     |
extra_specs.capabilities='boot_mode:uefi,boot_option:local',
            |
|                                     |
extra_specs.resources:CUSTOM_BAREMETAL_RESOURCE_CLASS='1',
            |
|                                     | extra_specs.resources:DISK_GB='0',
extra_specs.resources:MEMORY_MB='0',                |
|                                     | extra_specs.resources:VCPU='0',
original_name='bm-flavor', ram='63700', swap='0',      |
|                                     | vcpus='20'
                                                    |
| hostId                              |
                                                   |
| host_status                         |
                                                   |
| id                                  |
49944a1f-7758-4522-9ef1-867ede44b3fc
            |
| image                               | whole-disk-centos
(80724772-c760-4136-b453-754456d7c549)                               |
| key_name                            | None
                                                    |
| locked                              | False
                                                   |
| locked_reason                       | None
                                                    |
| name                                | bm-server
                                                   |
| project_id                          | 8dde31e24eba41bfb7212ae154d61268
                                                    |
| properties                          |
                                                   |
| server_groups                       | []
                                                    |
| status                              | ERROR
                                                   |
| tags                                | []
                                                    |
| trusted_image_certificates          | None
                                                    |
| updated                             | 2022-02-14T10:20:49Z
                                                    |
| user_id                             | f689d147221549f1a6cbd1310078127d
                                                    |
| volumes_attached                    |
                                                   |
+-------------------------------------+----------------------------------------------------------------------------------------+
(overcloud) [stack at undercloud v4]$
(overcloud) [stack at undercloud v4]$

 For your reference our update flavor and baremetal node properties are as
below:

(overcloud) [stack at undercloud v4]$ *openstack flavor show bm-flavor
--fit-width*
+----------------------------+-------------------------------------------------------------------------------------------------+
| Field                      | Value
                                                    |
+----------------------------+-------------------------------------------------------------------------------------------------+
| OS-FLV-DISABLED:disabled   | False
                                                    |
| OS-FLV-EXT-DATA:ephemeral  | 0
                                                    |
| access_project_ids         | None
                                                   |
| description                | None
                                                   |
| disk                       | 470
                                                    |
| extra_specs                |
{'resources:CUSTOM_BAREMETAL_RESOURCE_CLASS': '1', 'resources:VCPU': '0',
                    |
|                            | 'resources:MEMORY_MB': '0',
'resources:DISK_GB': '0', 'capabilities':                           |
|                            | 'boot_mode:uefi,boot_option:local'}
                                                    |
| id                         | 021c3021-56ec-4eba-bf57-c516ee9b2ee3
                                                   |
| name                       | bm-flavor
                                                    |
| os-flavor-access:is_public | True
                                                   |
| properties                 |*
capabilities='boot_mode:uefi,boot_option:local',
resources:CUSTOM_BAREMETAL_RESOURCE_CLASS='1', |*
|                            | resources:DISK_GB='0',
resources:MEMORY_MB='0', resources:VCPU='0'                              |
| ram                        | 63700
                                                    |
| rxtx_factor                | 1.0
                                                    |
| swap                       | 0
                                                    |
| vcpus                      | 20
                                                   |
+----------------------------+-------------------------------------------------------------------------------------------------+
(overcloud) [stack at undercloud v4]$

(overcloud) [stack at undercloud v4]$

(overcloud) [stack at undercloud v4]$* openstack baremetal node show
baremetal-node --fit-width*
+------------------------+-----------------------------------------------------------------------------------------------------+
| Field                  | Value
                                                    |
+------------------------+-----------------------------------------------------------------------------------------------------+
| allocation_uuid        | None
                                                   |
| automated_clean        | None
                                                   |
| bios_interface         | no-bios
                                                    |
| boot_interface         | ipxe
                                                   |
| chassis_uuid           | None
                                                   |
| clean_step             | {}
                                                   |
| conductor              | overcloud-controller-0.localdomain
                                                   |
| conductor_group        |
                                                    |
| console_enabled        | False
                                                    |
| console_interface      | ipmitool-socat
                                                   |
| created_at             | 2022-02-14T10:05:32+00:00
                                                    |
| deploy_interface       | iscsi
                                                    |
| deploy_step            | {}
                                                   |
| description            | None
                                                   |
| driver                 | ipmi
                                                   |
| driver_info            | {'ipmi_port': 623, 'ipmi_username': 'hsc',
'ipmi_password': '******', 'ipmi_address': '10.0.1.183', |
|                        | 'deploy_kernel':
'95a5b644-c04e-4a66-8f2b-e1e9806bed6e', 'deploy_ramdisk':
       |
|                        | '17644220-e623-4981-ae77-d789657851ba'}
                                                    |
| driver_internal_info   | {'agent_erase_devices_iterations': 1,
'agent_erase_devices_zeroize': True,                          |
|                        | 'agent_continue_if_ata_erase_failed': False,
'agent_enable_ata_secure_erase': True,                 |
|                        | 'disk_erasure_concurrency': 1,
'last_power_state_change': '2022-02-14T10:15:05.062161',             |
|                        | 'agent_version': '5.0.5.dev25',
'agent_last_heartbeat': '2022-02-14T10:14:59.666025',               |
|                        | 'hardware_manager_version':
{'generic_hardware_manager': '1.1'}, 'agent_cached_clean_steps':        |
|                        | {'deploy': [{'step': 'erase_devices',
'priority': 10, 'interface': 'deploy', 'reboot_requested':    |
|                        | False, 'abortable': True}, {'step':
'erase_devices_metadata', 'priority': 99, 'interface':          |
|                        | 'deploy', 'reboot_requested': False,
'abortable': True}], 'raid': [{'step': 'delete_configuration', |
|                        | 'priority': 0, 'interface': 'raid',
'reboot_requested': False, 'abortable': True}, {'step':         |
|                        | 'create_configuration', 'priority': 0,
'interface': 'raid', 'reboot_requested': False, 'abortable': |
|                        | True}]}, 'agent_cached_clean_steps_refreshed':
'2022-02-14 10:14:58.093777', 'clean_steps': None}   |
| extra                  | {}
                                                   |
| fault                  | None
                                                   |
| inspect_interface      | inspector
                                                    |
| inspection_finished_at | None
                                                   |
| inspection_started_at  | None
                                                   |
| instance_info          | {}
                                                   |
| instance_uuid          | None
                                                   |
| last_error             | None
                                                   |
| maintenance            | False
                                                    |
| maintenance_reason     | None
                                                   |
| management_interface   | ipmitool
                                                   |
| name                   | baremetal-node
                                                   |
| network_interface      | flat
                                                   |
| owner                  | None
                                                   |
| power_interface        | ipmitool
                                                   |
| power_state            | power off
                                                    |
|
*properties             | {'cpus': 20, 'memory_mb': 63700, 'local_gb': 470,
'cpu_arch': 'x86_64', 'capabilities':             ||
 | 'boot_mode:uefi,boot_option:local', 'vendor': 'hewlett-packard'}        *
                           |
| protected              | False
                                                    |
| protected_reason       | None
                                                   |
| provision_state        | available
                                                    |
| provision_updated_at   | 2022-02-14T10:15:27+00:00
                                                    |
| raid_config            | {}
                                                   |
| raid_interface         | no-raid
                                                    |
| rescue_interface       | agent
                                                    |
| reservation            | None
                                                   |
| resource_class         | baremetal-resource-class
                                                   |
| storage_interface      | noop
                                                   |
| target_power_state     | None
                                                   |
| target_provision_state | None
                                                   |
| target_raid_config     | {}
                                                   |
| traits                 | []
                                                   |
| updated_at             | 2022-02-14T10:15:27+00:00
                                                    |
| uuid                   | cd021878-40eb-407c-87c5-ce6ef92d29eb
                                                   |
| vendor_interface       | ipmitool
                                                   |
+------------------------+-----------------------------------------------------------------------------------------------------+
(overcloud) [stack at undercloud v4]$,

On further debugging, we found that in the nova-scheduler logs :


*2022-02-14 12:58:22.830 7 WARNING keystoneauth.discover [-] Failed to
contact the endpoint at http://172.16.2.224:8778/placement
<http://172.16.2.224:8778/placement> for discovery. Fallback to using that
endpoint as the base url.2022-02-14 12:58:23.438 7 WARNING
keystoneauth.discover [req-ad5801e4-efd7-4159-a601-68e72c0d651f - - - - -]
Failed to contact the endpoint at http://172.16.2.224:8778/placement
<http://172.16.2.224:8778/placement> for discovery. Fallback to using that
endpoint as the base url.*

where 172.16.2.224 is the internal IP.

going by document :
Bare Metal Instances in Overcloud ? TripleO 3.0.0 documentation
(openstack.org)
<https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/baremetal_overcloud.html>

it is given as below for commands:

(overcloud) [root at overcloud-controller-0 ~]# endpoint=
http://172.16.2.224:8778/placement
(overcloud) [root at overcloud-controller-0 ~]# token=$(openstack token issue
-f value -c id)
(overcloud) [root at overcloud-controller-0 ~]# curl -sH "X-Auth-Token:
$token" $endpoint/resource_providers/<node id> | jq .inventories
*null*

result is the same even if we run the curl command on public endpoint.

Please advice.



On Sat, Feb 12, 2022 at 12:45 AM Julia Kreger <juliaashleykreger at gmail.com>
wrote:

>
>
> On Fri, Feb 11, 2022 at 6:32 AM Lokendra Rathour <
> lokendrarathour at gmail.com> wrote:
>
>> Hi Harald/ Openstack Team,
>> Thank you again for your support.
>>
>> we have successfully provisioned the baremetal node as per the inputs
>> shared by you. The only change that we did was to add an entry for the
>> ServiceNetmap.
>>
>> Further, we were trying to launch the baremetal node instance  in which
>> we are facing ISSUE as mentioned below:
>>
>>
>> [trim'ed picture because of message size]
>
>>
>> *"2022-02-11 18:13:45.840 7 ERROR nova.compute.manager
>> [req-aafdea4d-815f-4504-b7d7-4fd95d1e083e - - - - -] Error updating
>> resources for node 9560bc2d-5f94-4ba0-9711-340cb8ad7d8a.:
>> nova.exception.NoResourceClass: Resource class not found for Ironic node
>> 9560bc2d-5f94-4ba0-9711-340cb8ad7d8a.*
>>
>> *2022-02-11 18:13:45.840 7 ERROR nova.compute.manager Traceback (most
>> recent call last):2022-02-11 18:13:45.840 7 ERROR nova.compute.manager
>> File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 8894,
>> in _update_available_resource_for_node*
>> "
>>
>
> So this exception can only be raised if the resource_class field is just
> not populated for the node. It is a required field for nova/ironic
> integration. Also, Interestingly enough, this UUID in the error doesn't
> match the baremetal node below. I don't know if that is intentional?
>
>
>> for your reference please refer following details:
>> (overcloud) [stack at undercloud v4]$ openstack baremetal node show
>> baremetal-node --fit-width
>>
>> +------------------------+-------------------------------------------------------------------------------------------------------------------+
>> | Field                  | Value
>>                                                                     |
>>
>> +------------------------+-------------------------------------------------------------------------------------------------------------------+
>> | allocation_uuid        | None
>>                                                                    |
>> | automated_clean        | None
>>                                                                    |
>> | bios_interface         | no-bios
>>                                                                     |
>> | boot_interface         | ipxe
>>                                                                    |
>> | chassis_uuid           | None
>>                                                                    |
>> | clean_step             | {}
>>                                                                    |
>> | conductor              | overcloud-controller-0.localdomain
>>                                                                    |
>> | conductor_group        |
>>                                                                     |
>> | console_enabled        | False
>>                                                                     |
>> | console_interface      | ipmitool-socat
>>                                                                    |
>> | created_at             | 2022-02-11T13:02:40+00:00
>>                                                                     |
>> | deploy_interface       | iscsi
>>                                                                     |
>> | deploy_step            | {}
>>                                                                    |
>> | description            | None
>>                                                                    |
>> | driver                 | ipmi
>>                                                                    |
>> | driver_info            | {'ipmi_port': 623, 'ipmi_username': 'hsc',
>> 'ipmi_password': '******', 'ipmi_address': '10.0.1.183',               |
>> |                        | 'deploy_kernel':
>> 'bc62f3dc-d091-4dbd-b730-cf7b6cb48625', 'deploy_ramdisk':
>>                      |
>> |                        | 'd58bcc08-cb7c-4f21-8158-0a5ed4198108'}
>>                                                                     |
>> | driver_internal_info   | {'agent_erase_devices_iterations': 1,
>> 'agent_erase_devices_zeroize': True, 'agent_continue_if_ata_erase_failed':
>>  |
>> |                        | False, 'agent_enable_ata_secure_erase': True,
>> 'disk_erasure_concurrency': 1, 'last_power_state_change':           |
>> |                        | '2022-02-11T13:14:29.581361', 'agent_version':
>> '5.0.5.dev25', 'agent_last_heartbeat':                             |
>> |                        | '2022-02-11T13:14:24.151928',
>> 'hardware_manager_version': {'generic_hardware_manager': '1.1'},
>>          |
>> |                        | 'agent_cached_clean_steps': {'deploy':
>> [{'step': 'erase_devices', 'priority': 10, 'interface': 'deploy',          |
>> |                        | 'reboot_requested': False, 'abortable': True},
>> {'step': 'erase_devices_metadata', 'priority': 99, 'interface':    |
>> |                        | 'deploy', 'reboot_requested': False,
>> 'abortable': True}], 'raid': [{'step': 'delete_configuration', 'priority':
>>   |
>> |                        | 0, 'interface': 'raid', 'reboot_requested':
>> False, 'abortable': True}, {'step': 'create_configuration',           |
>> |                        | 'priority': 0, 'interface': 'raid',
>> 'reboot_requested': False, 'abortable': True}]},
>>    |
>> |                        | 'agent_cached_clean_steps_refreshed':
>> '2022-02-11 13:14:22.580729', 'clean_steps': None}
>>  |
>> | extra                  | {}
>>                                                                    |
>> | fault                  | None
>>                                                                    |
>> | inspect_interface      | inspector
>>                                                                     |
>> | inspection_finished_at | None
>>                                                                    |
>> | inspection_started_at  | None
>>                                                                    |
>> | instance_info          | {}
>>                                                                    |
>> | instance_uuid          | None
>>                                                                    |
>> | last_error             | None
>>                                                                    |
>> | maintenance            | False
>>                                                                     |
>> | maintenance_reason     | None
>>                                                                    |
>> | management_interface   | ipmitool
>>                                                                    |
>> | name                   | baremetal-node
>>                                                                    |
>> | network_interface      | flat
>>                                                                    |
>> | owner                  | None
>>                                                                    |
>> | power_interface        | ipmitool
>>                                                                    |
>> | power_state            | power off
>>                                                                     |
>>
>> *| properties             | {'cpus': 20, 'memory_mb': 63700, 'local_gb':
>> 470, 'cpu_arch': 'x86_64', 'capabilities':                           ||
>>                    | 'boot_option:local,boot_mode:uefi', 'vendor':
>> 'hewlett-packard'}     *                                             |
>> | protected              | False
>>                                                                     |
>> | protected_reason       | None
>>                                                                    |
>> | provision_state        | available
>>                                                                     |
>> | provision_updated_at   | 2022-02-11T13:14:51+00:00
>>                                                                     |
>> | raid_config            | {}
>>                                                                    |
>> | raid_interface         | no-raid
>>                                                                     |
>> | rescue_interface       | agent
>>                                                                     |
>> | reservation            | None
>>                                                                    |
>> *| resource_class         | baremetal-resource-class  *
>>                                                                        |
>> | storage_interface      | noop
>>                                                                    |
>> | target_power_state     | None
>>                                                                    |
>> | target_provision_state | None
>>                                                                    |
>> | target_raid_config     | {}
>>                                                                    |
>> | traits                 | []
>>                                                                    |
>> | updated_at             | 2022-02-11T13:14:52+00:00
>>                                                                     |
>> | uuid                   | e64ad28c-43d6-4b9f-aa34-f8bc58e9e8fe
>>                                                                    |
>> | vendor_interface       | ipmitool
>>                                                                    |
>>
>> +------------------------+-------------------------------------------------------------------------------------------------------------------+
>> (overcloud) [stack at undercloud v4]$
>>
>>
>>
>>
>> (overcloud) [stack at undercloud v4]$ openstack flavor show
>> my-baremetal-flavor --fit-width
>>
>> +----------------------------+---------------------------------------------------------------------------------------------------------------+
>> | Field                      | Value
>>                                                                     |
>>
>> +----------------------------+---------------------------------------------------------------------------------------------------------------+
>> | OS-FLV-DISABLED:disabled   | False
>>                                                                     |
>> | OS-FLV-EXT-DATA:ephemeral  | 0
>>                                                                     |
>> | access_project_ids         | None
>>                                                                    |
>> | description                | None
>>                                                                    |
>> | disk                       | 470
>>                                                                     |
>>
>> *| extra_specs                |
>> {'resources:CUSTOM_BAREMETAL_RESOURCE_CLASS': '1', 'resources:VCPU': '0',
>> 'resources:MEMORY_MB': '0',         ||                            |
>> 'resources:DISK_GB': '0', 'capabilities:boot_option':
>> 'local,boot_mode:uefi'} *                                |
>> | id                         | 66a13404-4c47-4b67-b954-e3df42ae8103
>>                                                                    |
>> | name                       | my-baremetal-flavor
>>                                                                     |
>> | os-flavor-access:is_public | True
>>                                                                    |
>>
>> *| properties                 |
>> capabilities:boot_option='local,boot_mode:uefi',
>> resources:CUSTOM_BAREMETAL_RESOURCE_CLASS='1',               ||
>>                | resources:DISK_GB='0', resources:MEMORY_MB='0',
>> resources:VCPU='0'    *                                        |
>> | ram                        | 63700
>>                                                                     |
>> | rxtx_factor                | 1.0
>>                                                                     |
>> | swap                       | 0
>>                                                                     |
>> | vcpus                      | 20
>>                                                                    |
>>
>> +----------------------------+---------------------------------------------------------------------------------------------------------------+
>>
>
> However you've set your capabilities field, it is actually unable to be
> parsed. Then again, it doesn't *have* to be defined to match the baremetal
> node. The setting can still apply on the baremetal node if that is the
> operational default for the machine as defined on the machine itself.
>
> I suspect, based upon whatever the precise nova settings are, this would
> result in an inability to schedule on to the node because it would parse it
> incorrectly, possibly looking for a key value of
> "capabilities:boot_option", instead of "capabilities".
>
> (overcloud) [stack at undercloud v4]$
>>
>> Can you please check and suggest if something is missing.
>>
>> Thanks once again for your support.
>>
>> -Lokendra
>>
>>
>>
>>
>> On Thu, Feb 10, 2022 at 10:09 PM Lokendra Rathour <
>> lokendrarathour at gmail.com> wrote:
>>
>>> Hi Harald,
>>> Thanks for the response, please find my response inline:
>>>
>>>
>>> On Thu, Feb 10, 2022 at 8:24 PM Harald Jensas <hjensas at redhat.com>
>>> wrote:
>>>
>>>> On 2/10/22 14:49, Lokendra Rathour wrote:
>>>> > Hi Harald,
>>>> > Thanks once again for your support, we tried activating the
>>>> parameters:
>>>> > ServiceNetMap:
>>>> >      IronicApiNetwork: provisioning
>>>> >      IronicNetwork: provisioning
>>>> > at environments/network-environments.yaml
>>>> > image.png
>>>> > After changing these values the updated or even the fresh deployments
>>>> > are failing.
>>>> >
>>>>
>>>> How did deployment fail?
>>>>
>>>
>>> [Loke] : it failed immediately after when the IP for ctlplane network is
>>> assigned, and ssh is established and stack creation is completed, I think
>>> at the start of ansible execution.
>>>
>>> Error:
>>> "enabling ssh admin - COMPLETE.
>>> Host 10.0.1.94 not found in /home/stack/.ssh/known_hosts"
>>> Although this message is even seen when the deployment is successful. so
>>> I do not think this is the culprit.
>>>
>>>
>>>
>>>
>>>> > The command that we are using to deploy the OpenStack overcloud:
>>>> > /openstack overcloud deploy --templates \
>>>> >      -n /home/stack/templates/network_data.yaml \
>>>> >      -r /home/stack/templates/roles_data.yaml \
>>>> >      -e /home/stack/templates/node-info.yaml \
>>>> >      -e /home/stack/templates/environment.yaml \
>>>> >      -e /home/stack/templates/environments/network-isolation.yaml \
>>>> >      -e /home/stack/templates/environments/network-environment.yaml \
>>>>
>>>> What modifications did you do to network-isolation.yaml and
>>>
>>> [Loke]:
>>> *Network-isolation.yaml:*
>>>
>>> # Enable the creation of Neutron networks for isolated Overcloud
>>> # traffic and configure each role to assign ports (related
>>> # to that role) on these networks.
>>> resource_registry:
>>>   # networks as defined in network_data.yaml
>>>   OS::TripleO::Network::J3Mgmt: ../network/j3mgmt.yaml
>>>   OS::TripleO::Network::Tenant: ../network/tenant.yaml
>>>   OS::TripleO::Network::InternalApi: ../network/internal_api.yaml
>>>   OS::TripleO::Network::External: ../network/external.yaml
>>>
>>>
>>>   # Port assignments for the VIPs
>>>   OS::TripleO::Network::Ports::J3MgmtVipPort:
>>> ../network/ports/j3mgmt.yaml
>>>
>>>
>>>   OS::TripleO::Network::Ports::InternalApiVipPort:
>>> ../network/ports/internal_api.yaml
>>>   OS::TripleO::Network::Ports::ExternalVipPort:
>>> ../network/ports/external.yaml
>>>
>>>
>>>   OS::TripleO::Network::Ports::RedisVipPort: ../network/ports/vip.yaml
>>>   OS::TripleO::Network::Ports::OVNDBsVipPort: ../network/ports/vip.yaml
>>>
>>>
>>>
>>>   # Port assignments by role, edit role definition to assign networks to
>>> roles.
>>>   # Port assignments for the Controller
>>>   OS::TripleO::Controller::Ports::J3MgmtPort:
>>> ../network/ports/j3mgmt.yaml
>>>   OS::TripleO::Controller::Ports::TenantPort:
>>> ../network/ports/tenant.yaml
>>>   OS::TripleO::Controller::Ports::InternalApiPort:
>>> ../network/ports/internal_api.yaml
>>>   OS::TripleO::Controller::Ports::ExternalPort:
>>> ../network/ports/external.yaml
>>>   # Port assignments for the Compute
>>>   OS::TripleO::Compute::Ports::J3MgmtPort: ../network/ports/j3mgmt.yaml
>>>   OS::TripleO::Compute::Ports::TenantPort: ../network/ports/tenant.yaml
>>>   OS::TripleO::Compute::Ports::InternalApiPort:
>>> ../network/ports/internal_api.yaml
>>>
>>> ~
>>>
>>>
>>>>
>>>> network-environment.yaml?
>>>>
>>>
>>> resource_registry:
>>>   # Network Interface templates to use (these files must exist). You can
>>>   # override these by including one of the net-*.yaml environment files,
>>>   # such as net-bond-with-vlans.yaml, or modifying the list here.
>>>   # Port assignments for the Controller
>>>   OS::TripleO::Controller::Net::SoftwareConfig:
>>>     ../network/config/bond-with-vlans/controller.yaml
>>>   # Port assignments for the Compute
>>>   OS::TripleO::Compute::Net::SoftwareConfig:
>>>     ../network/config/bond-with-vlans/compute.yaml
>>> parameter_defaults:
>>>
>>>   J3MgmtNetCidr: '80.0.1.0/24'
>>>   J3MgmtAllocationPools: [{'start': '80.0.1.4', 'end': '80.0.1.250'}]
>>>   J3MgmtNetworkVlanID: 400
>>>
>>>   TenantNetCidr: '172.16.0.0/24'
>>>   TenantAllocationPools: [{'start': '172.16.0.4', 'end': '172.16.0.250'}]
>>>   TenantNetworkVlanID: 416
>>>   TenantNetPhysnetMtu: 1500
>>>
>>>   InternalApiNetCidr: '172.16.2.0/24'
>>>   InternalApiAllocationPools: [{'start': '172.16.2.4', 'end':
>>> '172.16.2.250'}]
>>>   InternalApiNetworkVlanID: 418
>>>
>>>   ExternalNetCidr: '10.0.1.0/24'
>>>   ExternalAllocationPools: [{'start': '10.0.1.85', 'end': '10.0.1.98'}]
>>>   ExternalNetworkVlanID: 408
>>>
>>>   DnsServers: []
>>>   NeutronNetworkType: 'geneve,vlan'
>>>   NeutronNetworkVLANRanges: 'datacentre:1:1000'
>>>   BondInterfaceOvsOptions: "bond_mode=active-backup"
>>>
>>>
>>>>
>>>> I typically use:
>>>> -e
>>>>
>>>> /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
>>>> -e
>>>>
>>>> /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml
>>>> -e /home/stack/templates/environments/network-overrides.yaml
>>>>
>>>> The network-isolation.yaml and network-environment.yaml are Jinja2
>>>> rendered based on the -n input, so too keep in sync with change in the
>>>> `-n` file reference the file in
>>>> /usr/share/opentack-tripleo-heat-templates. Then add overrides in
>>>> network-overrides.yaml as neede.
>>>>
>>>
>>> [Loke] : we are using this as like only, I do not know what you pass in
>>> network-overrides.yaml but I pass other files as per commands as below:
>>>
>>> [stack at undercloud templates]$ cat environment.yaml
>>> parameter_defaults:
>>>   ControllerCount: 3
>>>   TimeZone: 'Asia/Kolkata'
>>>   NtpServer: ['30.30.30.3']
>>>   NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
>>>   NeutronFlatNetworks: datacentre,baremetal
>>> [stack at undercloud templates]$ cat ironic-config.yaml
>>> parameter_defaults:
>>>     IronicEnabledHardwareTypes:
>>>         - ipmi
>>>         - redfish
>>>     IronicEnabledPowerInterfaces:
>>>         - ipmitool
>>>         - redfish
>>>     IronicEnabledManagementInterfaces:
>>>         - ipmitool
>>>         - redfish
>>>     IronicCleaningDiskErase: metadata
>>>     IronicIPXEEnabled: true
>>>     IronicInspectorSubnets:
>>>     - ip_range: 172.23.3.100,172.23.3.150
>>>     IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel", "
>>> http://30.30.30.1:8088/agent.ramdisk"]'
>>>     IronicInspectorInterface: 'br-baremetal'
>>> [stack at undercloud templates]$
>>> [stack at undercloud templates]$ cat node-info.yaml
>>> parameter_defaults:
>>>   OvercloudControllerFlavor: control
>>>   OvercloudComputeFlavor: compute
>>>   ControllerCount: 3
>>>   ComputeCount: 1
>>> [stack at undercloud templates]$
>>>
>>>
>>>
>>>>
>>>> >      -e
>>>> >
>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>>>>
>>>> > \
>>>> >      -e
>>>> >
>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>>>>
>>>> > \
>>>> >      -e
>>>> >
>>>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>>>>
>>>> > \
>>>> >      -e /home/stack/templates/ironic-config.yaml \
>>>> >      -e
>>>> >
>>>> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>>>> >      -e
>>>> > /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>>>> >      -e /home/stack/containers-prepare-parameter.yaml/
>>>> >
>>>> > **/home/stack/templates/ironic-config.yaml :
>>>> > (overcloud) [stack at undercloud ~]$ cat
>>>> > /home/stack/templates/ironic-config.yaml
>>>> > parameter_defaults:
>>>> >      IronicEnabledHardwareTypes:
>>>> >          - ipmi
>>>> >          - redfish
>>>> >      IronicEnabledPowerInterfaces:
>>>> >          - ipmitool
>>>> >          - redfish
>>>> >      IronicEnabledManagementInterfaces:
>>>> >          - ipmitool
>>>> >          - redfish
>>>> >      IronicCleaningDiskErase: metadata
>>>> >      IronicIPXEEnabled: true
>>>> >      IronicInspectorSubnets:
>>>> >      - ip_range: 172.23.3.100,172.23.3.150
>>>> >      IPAImageURLs: '["http://30.30.30.1:8088/agent.kernel
>>>> > <http://30.30.30.1:8088/agent.kernel>",
>>>> > "http://30.30.30.1:8088/agent.ramdisk
>>>> > <http://30.30.30.1:8088/agent.ramdisk>"] >
>>>> IronicInspectorInterface: 'br-baremetal'
>>>> >
>>>> > Also the baremetal network(provisioning)(172.23.3.x)  is  routed with
>>>> > ctlplane/admin network (30.30.30.x)
>>>> >
>>>>
>>>> Unless the network you created in the overcloud is named
>>>> `provisioning`,
>>>> these parameters may be relevant.
>>>>
>>>> IronicCleaningNetwork:
>>>>    default: 'provisioning'
>>>>    description: Name or UUID of the *overcloud* network used for
>>>> cleaning
>>>>                 bare metal nodes. The default value of "provisioning"
>>>> can be
>>>>                 left during the initial deployment (when no networks are
>>>>                 created yet) and should be changed to an actual UUID in
>>>>                 a post-deployment stack update.
>>>>    type: string
>>>>
>>>> IronicProvisioningNetwork:
>>>>    default: 'provisioning'
>>>>    description: Name or UUID of the *overcloud* network used for
>>>> provisioning
>>>>                 of bare metal nodes, if IronicDefaultNetworkInterface is
>>>>                 set to "neutron". The default value of "provisioning"
>>>> can be
>>>>                 left during the initial deployment (when no networks are
>>>>                 created yet) and should be changed to an actual UUID in
>>>>                 a post-deployment stack update.
>>>>    type: string
>>>>
>>>> IronicRescuingNetwork:
>>>>    default: 'provisioning'
>>>>    description: Name or UUID of the *overcloud* network used for
>>>> resucing
>>>>                 of bare metal nodes, if IronicDefaultRescueInterface is
>>>> not
>>>>                 set to "no-rescue". The default value of "provisioning"
>>>> can be
>>>>                 left during the initial deployment (when no networks are
>>>>                 created yet) and should be changed to an actual UUID in
>>>>                 a post-deployment stack update.
>>>>    type: string
>>>>
>>>> > *Query:*
>>>> >
>>>> >  1. any other location/way where we should add these so that they are
>>>> >     included without error.
>>>> >
>>>> >         *ServiceNetMap:*
>>>> >
>>>> >         *    IronicApiNetwork: provisioning*
>>>> >
>>>> >         *    IronicNetwork: provisioning*
>>>> >
>>>>
>>>> `provisioning` network is defined in -n
>>>> /home/stack/templates/network_data.yaml right?
>>>
>>> [Loke]: No it does not have any entry for provisioning in this file, it
>>> is network entry for J3Mgmt,Tenant,InternalApi, and External. These n/w's
>>> are added as vlan based under the br-ext bridge.
>>> provisioning network I am creating after the overcloud is deployed and
>>> before the baremetal node is provisioned.
>>> in the provisioning network, we are giving the range of the ironic
>>> network. (172.23.3.x)
>>>
>>>
>>>
>>>
>>>> And an entry in
>>>> 'networks' for the controller role in
>>>> /home/stack/templates/roles_data.yaml?
>>>>
>>> [Loke]: we also did not added a similar entry in the roles_data.yaml as
>>> well.
>>>
>>> Just to add with these two files we have rendered the remaining
>>> templates.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> >       2. Also are these commands(mentioned above) configure Baremetal
>>>> >     services are fine.
>>>> >
>>>>
>>>> Yes, what you are doing makes sense.
>>>>
>>>> I'm actually not sure why it did'nt work with your previous
>>>> configuration, it got the information about NBP file and obviously
>>>> attempted to download it from 30.30.30.220. With routing in place, that
>>>> should work.
>>>>
>>>> Changeing the ServiceNetMap to move IronicNetwork services to the
>>>> 172.23.3 would avoid the routing.
>>>>
>>> [Loke] : we can try this but are somehow not able to do so because of
>>> some weird reasons.
>>>
>>>>
>>>>
>>>> What is NeutronBridgeMappings?
>>>>   br-baremetal maps to the physical network of the overcloud
>>>> `provisioning` neutron network?
>>>>
>>>
>>>
>>>> [Loke] : yes , we create br-barmetal and then we create provisioning
>>>> network mapping it to br-baremetal.
>>>>
>>>> Also attaching the complete rendered template folder along with custom
>>> yaml files that I am using, maybe referring that you might have a more
>>> clear picture of our problem.
>>> Any clue would help.
>>> Our problem,
>>> we are not able to provision the baremetal node after the overcloud is
>>> deployed.
>>> Do we have any straight-forward documents using which we can test the
>>> baremetal provision, please provide that.
>>>
>>> Thanks once again for reading all these.
>>>
>>>
>>>
>>>
>>>> --
>>>> Harald
>>>>
>>>>
>>>
>>> -
>>> skype: lokendrarathour
>>>
>>>
>>>
>>
>> --
>>
>>
>>

-- 
~ Lokendra
www.inertiaspeaks.com
www.inertiagroups.com
skype: lokendrarathour
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/255b3659/attachment-0001.htm>

From johnsomor at gmail.com  Mon Feb 14 16:06:34 2022
From: johnsomor at gmail.com (Michael Johnson)
Date: Mon, 14 Feb 2022 08:06:34 -0800
Subject: [election][Designate][ptl] My candidacy for the "Z" release
Message-ID: <CAMH0Mg+qstr330O-z-ygFDCruFnCr2kL2xK0X2LsjEX2V0-PhQ@mail.gmail.com>

Hello OpenStack community,

I would like to announce my candidacy for PTL of Designate for the "Z"
cycle.

I would like to continue to support the Designate team for the "Z" release.
We have made good progress improving the Designate tempest tests and
documentation, but we have more work to do. The team has also been focusing
on cleaning up some of the accumulated technical debt, which I expect will
continue into the "Z" cycle.

Thank you for your support and your consideration for "Z",

Michael Johnson (johnsom)


From mahati.chamarthy at gmail.com  Mon Feb 14 16:03:55 2022
From: mahati.chamarthy at gmail.com (Mahati Chamarthy)
Date: Mon, 14 Feb 2022 21:33:55 +0530
Subject: Outreachy OpenStack Coordinator change
Message-ID: <CAPfWQspy15YXazEygz1MMMVGyQY1vCui1K=wDzWRiqYBX3efvQ@mail.gmail.com>

Hello all,

There has been a change in coordination responsibilities for Outreachy
OpenStack <https://www.outreachy.org>.

Samuel has decided to step down as a coordinator. I'd like to thank Samuel
for his time and efforts to Outreachy. He has helped onboard many new
contributors onto the Outreachy Openstack internship program. Thank you
Samuel and hope our paths cross again! Good luck.

I'd also like to welcome Dmitry Tantsur who kindly offered to coordinate
along with me for Outreachy Openstack. Dmitry has been a long time
OpenStack contributor and a core committer for the Ironic project. He has
already been an Outreachy mentor for multiple rounds. For any queries
regarding Outreachy, he can be reached at divius.inside at gmail.com (or) on
IRC: dtantsur

Welcome aboard Dmitry, thank you for stepping up!

Best,
Mahati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/d76f9217/attachment.htm>

From mahati.chamarthy at gmail.com  Mon Feb 14 16:11:42 2022
From: mahati.chamarthy at gmail.com (Mahati Chamarthy)
Date: Mon, 14 Feb 2022 21:41:42 +0530
Subject: Call for Outreachy OpenStack mentors - May 2022 round
Message-ID: <CAPfWQspy0jxFmDJQx-N00-_ahzUxgn3uV5Vt7tvS6BHPNPXyng@mail.gmail.com>

Hello!

*TL;DR OpenStack is participating in Outreachy for the upcoming round! **Please
submit projects.*

Outreachy's goal is to support people from groups underrepresented in the
technology industry. Interns will work remotely with mentors from our
community.

We are seeking mentors to propose projects that Outreachy interns can work
on during their internship. If you or your colleagues are interested in
mentoring in the next round, please submit your project proposal over here
by *March 4th, 2022:* https://www.outreachy.org/communities/cfp/openstack/

Mentors should read the mentor FAQ
https://www.outreachy.org/mentor/mentor-faq and find more details about the
Outreachy program and timeline in https://www.outreachy.org/communities/cfp/
.

If you need help crafting your project proposal or have any other queries,
please contact me Mahati Chamarthy <mahati.chamarthy at gmail.com> or Dmitry
Tantsur <divius.inside at gmail.com>

Best,
Mahati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/8984a5a1/attachment.htm>

From pierre at stackhpc.com  Mon Feb 14 16:14:33 2022
From: pierre at stackhpc.com (Pierre Riteau)
Date: Mon, 14 Feb 2022 17:14:33 +0100
Subject: [blazar][election][ptl] PTL candidacy for Z
Message-ID: <CA+ny2szEupCbyDhEFSu5QSGZ+9CGOij3kjVphhx6REfMUGVKdw@mail.gmail.com>

Hi,

I would like to self-nominate for the role of PTL of Blazar for the Z
release
cycle. I have been PTL since the Stein cycle and I am willing to continue in
this role.

We have experienced an uptick in contributions during the Yoga cycle,
merging
some long-awaited features such as a calendar view in the dashboard or
initial
support for preemptible instances. I would like to keep this momentum going,
improving Blazar for its existing users and plugging gaps preventing it from
getting adopted by more deployments.

Thank you for your support,
Pierre Riteau (priteau)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/153b88db/attachment.htm>

From openstack at nemebean.com  Mon Feb 14 16:32:23 2022
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 14 Feb 2022 10:32:23 -0600
Subject: oslo.messaging integration development
In-Reply-To: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
Message-ID: <4e20b1f1-030a-519a-aa8b-774d2d4f319d@nemebean.com>

First off I will note that we've had very bad luck in the past with 
non-rabbit drivers getting traction either with developers or operators. 
Most of them have bit-rotted and been removed at this point.

That said, we do have a list of requirements for oslo.messaging drivers 
in the documentation: 
https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html

We realize those are non-trivial to achieve for a new driver, so in 
discussions about other drivers we've pursued the option of developing 
the new driver out of tree as either a third-party library or a feature 
branch in oslo.messaging. For NATS[0] we ended up going with a feature 
branch, although to my knowledge that hasn't really gone anywhere (see 
above about having bad luck with this sort of thing).

The other unfortunate reality is that we've lost the messaging experts 
who would ideally have reviewed a new driver. Working in a feature 
branch that doesn't affect the released library mitigates this somewhat 
because issues can be worked out without affecting production 
deployments, but unfortunately it is an obstacle.

That said, if someone were to develop a new driver that would probably 
go a long way toward making them a messaging expert so this might be a 
good way to replenish our talent pool in this area. :-)

I don't want to discourage anyone from writing a new driver (I think 
everyone would love to get rid of rabbit), but before starting down that 
path I think it's important to understand that there is a lot of inertia 
behind rabbit and messaging is a complex topic. This is not a project 
that will take a few weeks. Even a few months is a stretch. You're going 
to need a rock solid driver implementation and then be able to show that 
it's enough better than rabbit to convince people to switch.

So, if after all this doom and gloom you still want to move forward, 
feel free to write up a spec similar to the NATS one and we can get you 
a feature branch or repo to work in.

0: https://review.opendev.org/c/openstack/oslo-specs/+/692784

On 2/13/22 20:54, liyang wrote:
> Hi? everyone,
>  ? ? I find Apache Pulsar is very popular in MQ area, especially in 
> clound native area. Is there any body integrate this MQ to oslo.messaging?
>  ? ? Said to the truth. RabbitMQ developed in Erlang has very little 
> source code level?material, Qpid has very little?operation practice in 
> the internet. Kafka only support notification in oslo.messaging.
>  ? ? I think the Apache Pulsar? is clound native based. It may enforece 
> the big?scale in extension about Openstack deployment.
> 
> 


From gmann at ghanshyammann.com  Mon Feb 14 17:03:39 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 14 Feb 2022 11:03:39 -0600
Subject: [all][tc] OpenStack next release name is final- "OpenStack Zed"
Message-ID: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com>

Hello Everyone,

We have the final name selected for the OpenStack next release name. Its "OpenStack Zed".

As per the release name criteria[1], selection of release name has gone through three steps:

Step1: Name nomination from community members[2].

Step2: TC voted on the nominated names[3].

Step3: Trademark checks by Foundation on winners from TC votes.
In trademark check, ?Zed? is finalized as the best bet for this release.

Thanks community members for participating in name nomination, TC to vote and Foundation for performing the
trademark checks.

[1] https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria
[2] https://wiki.openstack.org/wiki/Release_Naming/Z_Proposals
[3] https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f

-gmann	


From tkajinam at redhat.com  Mon Feb 14 17:06:17 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 15 Feb 2022 02:06:17 +0900
Subject: [puppet][tc] Propose changing the release model to cycle-with-rc
In-Reply-To: <CAL_crJRPqEp+e=qysmR8=XVq37YLWd+EaB7ChnGjkbkz9YEg7Q@mail.gmail.com>
References: <CAL_crJRPqEp+e=qysmR8=XVq37YLWd+EaB7ChnGjkbkz9YEg7Q@mail.gmail.com>
Message-ID: <CAL_crJQBL7rYnTVCvbp8vJVkLio5Ut6qc1YdsbWD9v1KUg+Z+A@mail.gmail.com>

Thank you, all, who shared your thoughts on this !

Because we haven't heard any concerns or objections, we'll move this
transition forward.
As I mentioned earlier, I'm expecting the change will be applied from the Z
release.

Thank you,
Takashi

On Mon, Jan 24, 2022 at 10:55 AM Takashi Kajinami <tkajinam at redhat.com>
wrote:

> Hello,
>
>
> I already discussed this with a few cores last year but I'm raising this
> topic
> in ML to make an official decision.
>
> Currently Puppet OpenStack is following cycle-with-intermediary and
> creates a release every milestone. However our code is tightly related
> to the actual service implementations and having only puppet releases
> is not very useful.
>
> Considering the above point, and effort required to cut off releases per
> milestone,
> I'll propose changing our release model to cycle-with-rc , and creating a
> single release.
>
> Because we already created milestone releases for Yoga, I'm thinking of
> applying
> the change from next cycle(Z).
>
> Please let me know if you have any concerns.
>
> Thank you,
> Takashi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/6423c988/attachment-0001.htm>

From gfidente at redhat.com  Mon Feb 14 17:53:04 2022
From: gfidente at redhat.com (Giulio Fidente)
Date: Mon, 14 Feb 2022 18:53:04 +0100
Subject: [all][tc] OpenStack next release name is final- "OpenStack Zed"
In-Reply-To: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com>
References: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com>
Message-ID: <450c1cc5-1154-97b4-21d3-cec769b8c869@redhat.com>

On 2/14/22 18:03, Ghanshyam Mann wrote:
> Hello Everyone,
> 
> We have the final name selected for the OpenStack next release name. Its "OpenStack Zed".
> 
> As per the release name criteria[1], selection of release name has gone through three steps:
> 
> Step1: Name nomination from community members[2].
> 
> Step2: TC voted on the nominated names[3].
> 
> Step3: Trademark checks by Foundation on winners from TC votes.
> In trademark check, ?Zed? is finalized as the best bet for this release.
> 
> Thanks community members for participating in name nomination, TC to vote and Foundation for performing the
> trademark checks.
> 
> [1] https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria
> [2] https://wiki.openstack.org/wiki/Release_Naming/Z_Proposals
> [3] https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f

hi there, thanks for the update

I have a stupid, please excuse me if it was written already in some 
previous message: the poll results at [3] suggest that most voted were:

1. Zen - after Yoga, you should get Zen)  (Not defeated in any contest 
vs. another choice)
2. Zombie - an undead
3. Zeta , loses to Zombie - an undead by 5?2
4. Zed , loses to Zombie - an undead by 4?1

did 1,2,3 fail the trademark checks?

thanks
-- 
Giulio Fidente
GPG KEY: 08D733BA



From gmann at ghanshyammann.com  Mon Feb 14 18:28:38 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 14 Feb 2022 12:28:38 -0600
Subject: [all][tc] OpenStack next release name is final- "OpenStack Zed"
In-Reply-To: <450c1cc5-1154-97b4-21d3-cec769b8c869@redhat.com>
References: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com>
 <450c1cc5-1154-97b4-21d3-cec769b8c869@redhat.com>
Message-ID: <17ef97e6b7e.fa87b530351073.1185492487506837204@ghanshyammann.com>

 ---- On Mon, 14 Feb 2022 11:53:04 -0600 Giulio Fidente <gfidente at redhat.com> wrote ----
 > On 2/14/22 18:03, Ghanshyam Mann wrote:
 > > Hello Everyone,
 > > 
 > > We have the final name selected for the OpenStack next release name. Its "OpenStack Zed".
 > > 
 > > As per the release name criteria[1], selection of release name has gone through three steps:
 > > 
 > > Step1: Name nomination from community members[2].
 > > 
 > > Step2: TC voted on the nominated names[3].
 > > 
 > > Step3: Trademark checks by Foundation on winners from TC votes.
 > > In trademark check, ?Zed? is finalized as the best bet for this release.
 > > 
 > > Thanks community members for participating in name nomination, TC to vote and Foundation for performing the
 > > trademark checks.
 > > 
 > > [1] https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria
 > > [2] https://wiki.openstack.org/wiki/Release_Naming/Z_Proposals
 > > [3] https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f
 > 
 > hi there, thanks for the update
 > 
 > I have a stupid, please excuse me if it was written already in some 
 > previous message: the poll results at [3] suggest that most voted were:
 > 
 > 1. Zen - after Yoga, you should get Zen)  (Not defeated in any contest 
 > vs. another choice)
 > 2. Zombie - an undead
 > 3. Zeta , loses to Zombie - an undead by 5?2
 > 4. Zed , loses to Zombie - an undead by 4?1
 > 
 > did 1,2,3 fail the trademark checks?

Yes, as per the trademark checks done by the Foundation, Zed is the best choice.

-gmann

 > 
 > thanks
 > -- 
 > Giulio Fidente
 > GPG KEY: 08D733BA
 > 
 > 
 > 	


From gouthampravi at gmail.com  Mon Feb 14 19:21:14 2022
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Mon, 14 Feb 2022 11:21:14 -0800
Subject: [manila][ptl] Non-candidacy for the Z cycle
Message-ID: <CAKSuTPbLB894kSUgYjta6S=3D3czBNstmsJnpn95kPP7ak4cGg@mail.gmail.com>

Hey Zorillas and other interested Stackers,

I took over as Manila PTL prior to the Ussuri cycle and have had fun
running the project for 5 cycles. The itch for change hasn't subsided.
So, I'd love to hand off the PTL baton and go back to being a
maintainer (or whatever else you'll let my pompous behind claim to
be). Despair not though, there's someone that has bright ideas and
energy to enhance this role that intends to nominate themselves to
lead us through the Zorilla (Zed) cycle!

I'm very proud that I had your encouragement and support for the past
~three years.
We innovated and incorporated some fun practices that held the
community together and grew it over time. We chipped away at tech debt
in an organized fashion, created focus teams, added half a dozen core
reviewers, mentored 20 (!) interns, squashed bugs, put together
hackfests, collaborated on reviews and somehow made the
pandemic-caused virtual project team gatherings fun as well. We will
do so much more of this with the new PTL and the hyper-charged zorilla
spirit :D So I'm very excited.

Thank you for your support!

--
Goutham Pacha Ravi


From beagles at redhat.com  Mon Feb 14 19:39:32 2022
From: beagles at redhat.com (Brent Eagles)
Date: Mon, 14 Feb 2022 16:09:32 -0330
Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer
 (upgrades-related)
In-Reply-To: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
References: <CA+YrBY55FEPJpZPRyHnjeq8t=AEjXBEQ-LjzzHMVj2zyT6P1Bw@mail.gmail.com>
Message-ID: <Ygqv9LcNwQuT5wHj@knife.localdomain>


+1

On Thu, Feb 10, 2022 at 03:35:20PM +0100, Jose Luis Franco Arza wrote:
> Hello folks,
>
> I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer on
> the TripleO repositories related to the upgrades workflow
> (openstack/tripleo-heat-templates, openstack/tripleo-ansible,
> openstack/python-tripleoclient, openstack/tripleo-ci,
> openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii
> has been working in OpenStack for the last 10 years, he is already
> core-reviewer of the tripleo-upgrade
> <https://github.com/openstack/tripleo-upgrade>repository in which he is
> providing with very valuable feedback, as well as helping getting relevant
> patches merged.
>
> His deep knowledge of the different OpenStack projects, as well as his
> involvement in the upgrades/updates workflows for the last 9 OpenStack
> releases makes him a great code reviewer, being able to catch several
> issues during the code review process.
>
> I will monitor the thread for a week and if no objections are exposed I
> will add him to the tripleo-core group.
>
> PD: Here comes the +1 from my side.
>
> Thanks.
>
> Cheers,
> Jos? Luis
>
> [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com
> [2]:
> https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolovatiuk&release=all
> [3]: Position #25 in the most active TripleO contributors list
> <https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180>

--
Brent Eagles
Principal Software Engineer
Red Hat Inc.



From frode.nordahl at canonical.com  Mon Feb 14 19:58:19 2022
From: frode.nordahl at canonical.com (Frode Nordahl)
Date: Mon, 14 Feb 2022 20:58:19 +0100
Subject: [all][tc] OpenStack next release name is final- "OpenStack Zed"
In-Reply-To: <17ef97e6b7e.fa87b530351073.1185492487506837204@ghanshyammann.com>
References: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com>
 <450c1cc5-1154-97b4-21d3-cec769b8c869@redhat.com>
 <17ef97e6b7e.fa87b530351073.1185492487506837204@ghanshyammann.com>
Message-ID: <CAKpbOATBOzCdvWVhdPOpmJJeRtHp8BQQiZkc9C5DnvU-04gFCQ@mail.gmail.com>

man. 14. feb. 2022, 19:36 skrev Ghanshyam Mann <gmann at ghanshyammann.com>:

>  ---- On Mon, 14 Feb 2022 11:53:04 -0600 Giulio Fidente <
> gfidente at redhat.com> wrote ----
>  > On 2/14/22 18:03, Ghanshyam Mann wrote:
>  > > Hello Everyone,
>  > >
>  > > We have the final name selected for the OpenStack next release name.
> Its "OpenStack Zed".
>  > >
>  > > As per the release name criteria[1], selection of release name has
> gone through three steps:
>  > >
>  > > Step1: Name nomination from community members[2].
>  > >
>  > > Step2: TC voted on the nominated names[3].
>  > >
>  > > Step3: Trademark checks by Foundation on winners from TC votes.
>  > > In trademark check, ?Zed? is finalized as the best bet for this
> release.
>  > >
>  > > Thanks community members for participating in name nomination, TC to
> vote and Foundation for performing the
>  > > trademark checks.
>  > >
>  > > [1]
> https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria
>  > > [2] https://wiki.openstack.org/wiki/Release_Naming/Z_Proposals
>  > > [3] https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f
>  >
>  > hi there, thanks for the update
>  >
>  > I have a stupid, please excuse me if it was written already in some
>  > previous message: the poll results at [3] suggest that most voted were:
>  >
>  > 1. Zen - after Yoga, you should get Zen)  (Not defeated in any contest
>  > vs. another choice)
>  > 2. Zombie - an undead
>  > 3. Zeta , loses to Zombie - an undead by 5?2
>  > 4. Zed , loses to Zombie - an undead by 4?1
>  >
>  > did 1,2,3 fail the trademark checks?
>
> Yes, as per the trademark checks done by the Foundation, Zed is the best
> choice.
>

Has this passed a cultural check as well?

YMMV, but a few generations will immediately associate this name with a not
so flattering scene [4] from the timeless classic motion picture named Pulp
Fiction.

4: https://youtu.be/5lL1ypndnWA

--
Frode Nordahl

-gmann
>
>  >
>  > thanks
>  > --
>  > Giulio Fidente
>  > GPG KEY: 08D733BA
>  >
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/88c0f0f5/attachment-0001.htm>

From openstack at a.spamming.party  Mon Feb 14 19:58:14 2022
From: openstack at a.spamming.party (JP E)
Date: Mon, 14 Feb 2022 20:58:14 +0100
Subject: [all][tc] Relmgt team position on release cadence
In-Reply-To: <20220214144447.xarnobufa43tdadq@yuggoth.org>
References: <CAF7gwdiUF2wj7RqN-LzwvwH1FQ1A7j=F-CikHKS0ct8AKNAdJg@mail.gmail.com>
 <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org>
 <CAF7gwdhnS_101_Ljf++V=-jGwKZ_NUm6gn+Jzo_N-VDwDuvayw@mail.gmail.com>
 <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com>
 <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
 <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>
 <fc5569d6-15e6-4d33-b0f4-2d619f90e732@www.fastmail.com>
 <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com>
 <17ee46051c6.12bb64653143256.163506775198229925@ghanshyammann.com>
 <830769aa-4a5a-407f-9668-7f28bf5f3bfd@www.fastmail.com>
 <20220214144447.xarnobufa43tdadq@yuggoth.org>
Message-ID: <7dc5ec59-7c0d-4e37-92a2-8f923d8679cc@www.fastmail.com>

Thanks Jeremy, that's perfect!

>From the notes, I am not sure what  "Extreme positions were expressed ("no longer do releases")" means (L28). Might be worth clarifying...

Overall, I am happy with Dan's proposal, it's a positive point to ensure in CI that we can upgrade every two releases of 6 months.

I am not sure whether this will be help us in the long run to keep a forced release every x months (rather than team autonomy + 'tag when needed' + refstack for 'coordinated release' ... especially when we'll have less contributions). However, that's not a hill I will die on, so let's move on :)

Thanks for everyone involved to make this better.

Regards,
JP


From knikolla at bu.edu  Mon Feb 14 20:28:02 2022
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Mon, 14 Feb 2022 20:28:02 +0000
Subject: [election][tc] Candidacy for TC for Z
Message-ID: <830D46BA-88A7-492A-B541-938A37E1AD5C@bu.edu>

Hi all,

I am announcing my candidacy for a position on the OpenStack Technical
Committee.

I'm a software engineer at the Mass Open Cloud[0], and the New
England Research Cloud[1], two initiatives from major universities in the
Boston area to create and operate public and open clouds that can federated
and replicated. I've been involved with OpenStack for the past 7 years as a
user, operator, and developer.

This is not my first time running, I have previously served on the Technical
Committee[2] and as Keystone PTL for 1 year during the Victoria and Wallaby
cycles[3][4].

I am passionate about open source and governance and keeping the community
healthy. My focus will be in facilitating the discussions that need to happen,
whether they are internal to a team, between project teams, or between
OpenStack and other projects.

Please allow me once again the honor of representing you, and the opportunity
to continue contributing to the community that I owe so much to and want to see
flourish.

I look forward to hopefully seeing you all very soon!

Thank you for your time and consideration,
Kristi Nikolla (he/him)

[0]. https://massopen.cloud
[1]. https://nerc.mghpcc.org
[2]. https://opendev.org/openstack/election/raw/branch/master/candidates/victoria/TC/knikolla at bu.edu
[3]. https://opendev.org/openstack/election/raw/branch/master/candidates/victoria/Keystone/knikolla at bu.edu
[4]. https://opendev.org/openstack/election/raw/branch/master/candidates/wallaby/Keystone/knikolla at bu.edu



From gmann at ghanshyammann.com  Mon Feb 14 20:33:07 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 14 Feb 2022 14:33:07 -0600
Subject: [all][tc] Relmgt team position on release cadence
In-Reply-To: <7dc5ec59-7c0d-4e37-92a2-8f923d8679cc@www.fastmail.com>
References: <CAF7gwdiUF2wj7RqN-LzwvwH1FQ1A7j=F-CikHKS0ct8AKNAdJg@mail.gmail.com>
 <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org>
 <CAF7gwdhnS_101_Ljf++V=-jGwKZ_NUm6gn+Jzo_N-VDwDuvayw@mail.gmail.com>
 <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com>
 <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com>
 <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com>
 <fc5569d6-15e6-4d33-b0f4-2d619f90e732@www.fastmail.com>
 <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com>
 <17ee46051c6.12bb64653143256.163506775198229925@ghanshyammann.com>
 <830769aa-4a5a-407f-9668-7f28bf5f3bfd@www.fastmail.com>
 <20220214144447.xarnobufa43tdadq@yuggoth.org>
 <7dc5ec59-7c0d-4e37-92a2-8f923d8679cc@www.fastmail.com>
Message-ID: <17ef9f062e3.b815765c354903.8239862322749884133@ghanshyammann.com>

 ---- On Mon, 14 Feb 2022 13:58:14 -0600 JP E <openstack at a.spamming.party> wrote ----
 > Thanks Jeremy, that's perfect!
 > 
 > From the notes, I am not sure what  "Extreme positions were expressed ("no longer do releases")" means (L28). Might be worth clarifying...
 > 
 > Overall, I am happy with Dan's proposal, it's a positive point to ensure in CI that we can upgrade every two releases of 6 months.
 > 
 > I am not sure whether this will be help us in the long run to keep a forced release every x months (rather than team autonomy + 'tag when needed' + refstack for 'coordinated release' ... especially when we'll have less contributions). However, that's not a hill I will die on, so let's move on :)
 > 
 > Thanks for everyone involved to make this better.

Thanks JP and sorry for short meeting notice. 

For long term, Dan proposal give us more flexibility and things to check for future which
we can keep improving as per the situation in future. 

-gmann

 > 
 > Regards,
 > JP
 > 
 > 


From gmann at ghanshyammann.com  Mon Feb 14 22:30:00 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 14 Feb 2022 16:30:00 -0600
Subject: [all][tc] OpenStack next release name is final- "OpenStack Zed"
In-Reply-To: <CAKpbOATBOzCdvWVhdPOpmJJeRtHp8BQQiZkc9C5DnvU-04gFCQ@mail.gmail.com>
References: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com>
 <450c1cc5-1154-97b4-21d3-cec769b8c869@redhat.com>
 <17ef97e6b7e.fa87b530351073.1185492487506837204@ghanshyammann.com>
 <CAKpbOATBOzCdvWVhdPOpmJJeRtHp8BQQiZkc9C5DnvU-04gFCQ@mail.gmail.com>
Message-ID: <17efa5b6424.1213b1869357645.2623342301875640039@ghanshyammann.com>

 ---- On Mon, 14 Feb 2022 13:58:19 -0600 Frode Nordahl <frode.nordahl at canonical.com> wrote ----
 > 
 > 
 > man. 14. feb. 2022, 19:36 skrev Ghanshyam Mann <gmann at ghanshyammann.com>:
 >  ---- On Mon, 14 Feb 2022 11:53:04 -0600 Giulio Fidente <gfidente at redhat.com> wrote ----
 >  > On 2/14/22 18:03, Ghanshyam Mann wrote:
 >  > > Hello Everyone,
 >  > > 
 >  > > We have the final name selected for the OpenStack next release name. Its "OpenStack Zed".
 >  > > 
 >  > > As per the release name criteria[1], selection of release name has gone through three steps:
 >  > > 
 >  > > Step1: Name nomination from community members[2].
 >  > > 
 >  > > Step2: TC voted on the nominated names[3].
 >  > > 
 >  > > Step3: Trademark checks by Foundation on winners from TC votes.
 >  > > In trademark check, ?Zed? is finalized as the best bet for this release.
 >  > > 
 >  > > Thanks community members for participating in name nomination, TC to vote and Foundation for performing the
 >  > > trademark checks.
 >  > > 
 >  > > [1] https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria
 >  > > [2] https://wiki.openstack.org/wiki/Release_Naming/Z_Proposals
 >  > > [3] https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f
 >  > 
 >  > hi there, thanks for the update
 >  > 
 >  > I have a stupid, please excuse me if it was written already in some 
 >  > previous message: the poll results at [3] suggest that most voted were:
 >  > 
 >  > 1. Zen - after Yoga, you should get Zen)  (Not defeated in any contest 
 >  > vs. another choice)
 >  > 2. Zombie - an undead
 >  > 3. Zeta , loses to Zombie - an undead by 5?2
 >  > 4. Zed , loses to Zombie - an undead by 4?1
 >  > 
 >  > did 1,2,3 fail the trademark checks?
 > 
 > Yes, as per the trademark checks done by the Foundation, Zed is the best choice.
 > 
 > Has this passed a cultural check as well?
 > YMMV, but a few generations will immediately associate this name with a not so flattering scene [4] from the timeless classic motion picture named Pulp Fiction.
 > 4: https://youtu.be/5lL1ypndnWA

We did check on ML and asked all the community members for the culture or historical objection on proposed names before election and it
seems no objection.

- https://lists.openstack.org/pipermail/openstack-discuss/2022-January/026868.html

-gmann

 > --Frode Nordahl
 > -gmann
 > 
 >  > 
 >  > thanks
 >  > -- 
 >  > Giulio Fidente
 >  > GPG KEY: 08D733BA
 >  > 
 >  > 
 >  >      
 > 
 > 	


From zigo at debian.org  Mon Feb 14 22:38:06 2022
From: zigo at debian.org (Thomas Goirand)
Date: Mon, 14 Feb 2022 23:38:06 +0100
Subject: [tooz] [mistral] Tenacity >= 8.0.1 issues (in Debian)
In-Reply-To: <f861039e-d0c5-6ca5-e69e-b7a969717457@debian.org>
References: <f861039e-d0c5-6ca5-e69e-b7a969717457@debian.org>
Message-ID: <c07291c2-9de2-6500-cf5d-3f7498059c8d@debian.org>

On 2/14/22 11:23, Thomas Goirand wrote:
> Hi,
> 
> It seems Tenacity has some incompatible changes leading to this:
> 
> https://bugs.debian.org/1005636 (tooz)
> https://bugs.debian.org/1005467 (mistral)
> 
> Note that both Manila and Heat were fixed already for this last version 
> of Tenacity, so these would likely be the only remaining blockers to 
> upgrade to 8.0.1.
> 
> As Tenacity 8.0.1 is already in Debian Unstable, I'd prefer if we fixed 
> these rather than pinning to a lower version.
> 
> Can anyone help?
> 
> Cheers,
> 
> Thomas Goirand (zigo)

BTW, it'd be nice if we didn't leave this kind of patch alone:
https://review.opendev.org/c/openstack/tooz/+/779161

It's ok to "unblock the gate" with this kind of patch if it's only 
temporary. But it's not ok to leave such a pinning forever: at some 
point it bites hard, which is exactly what's happening right now for me.

Cheers,

Thomas Goirand (zigo)


From ces.eduardo98 at gmail.com  Mon Feb 14 23:24:02 2022
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Mon, 14 Feb 2022 20:24:02 -0300
Subject: [manila][election][ptl] PTL Candidacy for Z
Message-ID: <CAE51gQKRV4r4YvdPs2LMfTXXjQLknA5mmoR5W13y0bt=u0BRPw@mail.gmail.com>

Hello, Zorillas and dear stackers,


I would like to submit my candidacy to be the PTL of Manila for the Z cycle.

I have been a contributor to OpenStack since the Stein release. It has been
an
awesome experience. During these years, I had the opportunity to contribute
with new features, fixes, reviews and other exciting enhancements for
Manila.
I can tell you that I've faced thrilling challenges, and I learned a lot
with
the community that made this journey enjoyable day after day. I'm
tremendously
happy to see the state Manila is at. I'd like to keep the momentum for the
project by continuing to focus in some areas we have been focusing, but also
start tackling other issues:

- Continue increasing the number of contributors and active reviewers
through
  mentoring and engaging them in the community, teaching the OpenStack way
and
  making it collaboratively as we did in the past cycles, promoting
hackatons,
  bug squashes and collaborative review sessions.


- Encouraging the involvement of Manila contributors in important
  programs/events such as GHC, Outreachy and the other opportunities we've
been
  able to contribute in the past.


- Pursue the completion of the Manila implementation on the
  openstackclient/openstacksdk;


- Continue pushing Manila to cover the tech debt areas we identified over
the
  past cycles;


- Enforcing maintainers to collaboratively cover the lack of documentation
we
  have on third party CI setups for Manila, helping potential new vendors to
  quickly setup up their CI systems;


- Continue discussing with community and making the necessary enhancements
for
  HA and Edge;

Thank you for your consideration!

Carlos da Silva
IRC: carloss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/b10fcc92/attachment-0001.htm>

From tkajinam at redhat.com  Mon Feb 14 23:43:38 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 15 Feb 2022 08:43:38 +0900
Subject: [election][storlets] PTL Candidacy for the "Z" release
Message-ID: <CAL_crJRQoSQ5Y4+evyE7mTeRtQBP4BNC9r6jhh65AXMpGLWUqQ@mail.gmail.com>

Hi All,

I'd like to announce my candidacy for PTL of Storlets for the z release
cycle,
continuing the role from past several cycles.

The biggest change we're expecting for this cycle is removal of Python 2
support, following the same in Swift, which was recently announced[1].
We don't expect any challenges at this moment as Storlets has been fully
complatble with Python 3 for several cycles, but the remaining work to clean
up items left to keep Python 2 support (Python 2 jobs, for example) is our
priority.

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026925.html

Thank you for your consideration.

Thank you,
Takashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/2fce72d1/attachment.htm>

From tkajinam at redhat.com  Mon Feb 14 23:45:41 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 15 Feb 2022 08:45:41 +0900
Subject: [election][puppet] PTL Candidacy for the "Z" release
Message-ID: <CAL_crJRKB8B_jU6Z9C4UwafB5Dk+wfirozCuO1uyPCQ3GOoFBA@mail.gmail.com>

Hello,

I'd like to announce my candidacy for the PTL role in Puppet OpenStack, for
the Z release cycle.

I've been involved in the project for a few years. I joined the core
reviewers of
the project in 2020. My contribution started with adding a few parameters
but
nowdays I'm covering literally all modules to keep these modules consistent
with the latest service implementation, as well as helping release
management.

I'll list up some important items for the upcoming Z-release, which I'd like
to prioritize.

 - Keep our implementation up to date and clean up old items to keep codes
   as simple as possible.

 - Extend support for Secure RBAC. We are adding partial support to enforce
   Secure RBAC in Keystone during Yoga.

 - Stabilize support for CentOS 9 Stream, which we are adding for Yoga.

 - Add support for the new Ubuntu LTS.

 - Improve scenario/component coverage by CI.

Finally, as we are currently a small team, we always welcome new
contributors,
reviewers or whoever interested in helping the project !

Thank you for your consideration.

Thank you,
Takashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/29c3a4ae/attachment.htm>

From gmann at ghanshyammann.com  Tue Feb 15 00:20:38 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 14 Feb 2022 18:20:38 -0600
Subject: [all][elections][ptl][tc] Combined PTL/TC Zed cycle Election
 Nominations Last Days
Message-ID: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com>

Hello Everyone,

A quick reminder that we are in the last hours for declaring PTL and
TC candidacies. Nominations are open until Feb 15, 2022 23:45 UTC.

If you want to stand for election, don't delay, follow the instructions at [1]
to make sure the community knows your intentions.

Make sure your nomination has been submitted to the openstack/election
repository and approved by election officials.

Election statistics[2]:
Nominations started       @ 2022-02-08 23:45:00 UTC
Nominations end           @ 2022-02-15 23:45:00 UTC
Nominations duration      : 7 days, 0:00:00
Nominations remaining     : 23:30:36
Nominations progress      :  86.01%
---------------------------------------------------
Projects[1]               :    49
Projects with candidates  :    19 ( 38.78%)
Projects with election    :     0 (  0.00%)
---------------------------------------------------
Need election             : 0 ()
Need appointment          : 30 (Adjutant Cloudkitty Freezer Heat Ironic Kuryr Magnum Masakari Monasca Murano OpenStackAnsible OpenStack_Charms Openstack_Chef Rally Release_Management Requirements Sahara Senlin Skyline Solum Swift Tacker Telemetry Tripleo Trove Venus Vitrage Watcher Zaqar Zun)
===================================================
Stats gathered            @ 2022-02-15 00:14:24 UTC


This means that with approximately 1 days left, 30 projects will be deemed leaderless.
In this case the TC will oversee PTL selection as described by [3].

There are also currently 3 confirmed candidates for the 5 open Technical Committee.

Thank you,

[1] https://governance.openstack.org/election/#how-to-submit-a-candidacy
[2] Any open reviews at
    https://review.openstack.org/#/q/is:open+project:openstack/election
    have not been factored into these stats.
[3] https://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html


-gmann & The OpenStack Technical Election Officials
	


From qiujunting at inspur.com  Tue Feb 15 01:37:18 2022
From: qiujunting at inspur.com (=?gb2312?B?SnVudGluZ3FpdSBRaXVqdW50aW5nICjH8b785sMp?=)
Date: Tue, 15 Feb 2022 01:37:18 +0000
Subject: [election][Sahara]PTL candidacy for Z
Message-ID: <d099b2e58a7349239f0322bc85e06c5d@inspur.com>

Hi all:

I write to submit my candidacy for the Sahara PTL position during the Z

cycle.I have been PTL for the Yoga cycle, and I would like to serve the community

for another cycle.

    In yoga cycle, we have discuss about the plugins are CDH, MapR, Storm,

Spark and Vanilla will be removed from Sahara. I will continue this work on

Z cycle. And assist the community to resolve some inappropriate issues in Yoga

about Sahara project.

    At present, the Sahara project is not very active, and welcome my dears to

actively participate in the construction of the Sahara project in Z cycle.

    Finally, expect the Sahara project to develop healthily and stably.

Best regards for you.

Fossen Qiu (fossenqiu)



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

Fossen Qiu  |  ???





CBRD  |  ??????????





T: 18249256272





E: qiujunting at inspur.com<mailto:qiujunting at inspur.com>












                ????





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/e95f6f00/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3519 bytes
Desc: image002.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/e95f6f00/attachment-0001.jpg>

From suzhengwei at inspur.com  Tue Feb 15 01:39:44 2022
From: suzhengwei at inspur.com (=?gb2312?B?U2FtIFN1ICjL1dX9zrAp?=)
Date: Tue, 15 Feb 2022 01:39:44 +0000
Subject: [elections][ptl][masakari]
Message-ID: <20d8b95b0b4e465083105e2e1fcf6a0c@inspur.com>

Hi all,

 

I write to submit my candidacy for the Masakari PTL position during the Z

cycle.

 

I took over as Masakari PTL during the Yoga cycle, and would like to serve

the community for another cycle. 

 

Right now the biggest challenge of the Masakari project is lack of activity.

We have been using Masakari in our cloud environment for years, so I want to

continue to make some little improvement as feedback.

 

Best regards for you.

-suzhengwei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/29b67e4f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3606 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/29b67e4f/attachment.bin>

From rodrigo.barbieri2010 at gmail.com  Tue Feb 15 02:09:43 2022
From: rodrigo.barbieri2010 at gmail.com (Rodrigo Barbieri)
Date: Mon, 14 Feb 2022 23:09:43 -0300
Subject: [manila][election][ptl] PTL Candidacy for Z
In-Reply-To: <CAE51gQKRV4r4YvdPs2LMfTXXjQLknA5mmoR5W13y0bt=u0BRPw@mail.gmail.com>
References: <CAE51gQKRV4r4YvdPs2LMfTXXjQLknA5mmoR5W13y0bt=u0BRPw@mail.gmail.com>
Message-ID: <CADMdNi+2AxA-aoKzmN_CLnDHWCCoW6=X4+DbAdrEZd-=cSKyag@mail.gmail.com>

+1 !

Carlos has been passionately working on manila since his first contact with
OpenStack back in 2018. It is clear to me that he has stacked up a lot of
experience to be an amazing PTL!

--
Rodrigo Barbieri
MSc Computer Scientist
OpenStack Manila Core Contributor
Federal University of S?o Carlos

On Mon, Feb 14, 2022, 20:29 Carlos Silva <ces.eduardo98 at gmail.com> wrote:

> Hello, Zorillas and dear stackers,
>
>
> I would like to submit my candidacy to be the PTL of Manila for the Z
> cycle.
>
> I have been a contributor to OpenStack since the Stein release. It has
> been an
> awesome experience. During these years, I had the opportunity to contribute
> with new features, fixes, reviews and other exciting enhancements for
> Manila.
> I can tell you that I've faced thrilling challenges, and I learned a lot
> with
> the community that made this journey enjoyable day after day. I'm
> tremendously
> happy to see the state Manila is at. I'd like to keep the momentum for the
> project by continuing to focus in some areas we have been focusing, but
> also
> start tackling other issues:
>
> - Continue increasing the number of contributors and active reviewers
> through
>   mentoring and engaging them in the community, teaching the OpenStack way
> and
>   making it collaboratively as we did in the past cycles, promoting
> hackatons,
>   bug squashes and collaborative review sessions.
>
>
> - Encouraging the involvement of Manila contributors in important
>   programs/events such as GHC, Outreachy and the other opportunities we've
> been
>   able to contribute in the past.
>
>
> - Pursue the completion of the Manila implementation on the
>   openstackclient/openstacksdk;
>
>
> - Continue pushing Manila to cover the tech debt areas we identified over
> the
>   past cycles;
>
>
> - Enforcing maintainers to collaboratively cover the lack of documentation
> we
>   have on third party CI setups for Manila, helping potential new vendors
> to
>   quickly setup up their CI systems;
>
>
> - Continue discussing with community and making the necessary enhancements
> for
>   HA and Edge;
>
> Thank you for your consideration!
>
> Carlos da Silva
> IRC: carloss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220214/92563e5d/attachment.htm>

From flux.adam at gmail.com  Tue Feb 15 02:51:07 2022
From: flux.adam at gmail.com (Adam Harwell)
Date: Tue, 15 Feb 2022 11:51:07 +0900
Subject: oslo.messaging integration development
In-Reply-To: <4e20b1f1-030a-519a-aa8b-774d2d4f319d@nemebean.com>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
 <4e20b1f1-030a-519a-aa8b-774d2d4f319d@nemebean.com>
Message-ID: <CAHxXnhdycw9bAzhnFte_U1vCLohgeN-5kkhF9FqLgAmeieYWbA@mail.gmail.com>

I think that would apply if there was actually code being written, but it
sounds like this would be a drop in, if Pulsar is able to use an AMQP
compatibility plugin and essentially act as though it was RMQ. I?m curious
to see if that works as expected.
If not, then I agree it is a very complex thing to build a new messaging
interface, and that is why I had previously expressed caution to our team
when it was brought up as an option. I?m only cautiously optimistic now
that someone else has broached the subject, and we do have at least some
interest still in assisting. I?d just like to see if the ?free? approach
will bear fruit before starting down that treacherous path. ?

On Tue, Feb 15, 2022 at 1:36 Ben Nemec <openstack at nemebean.com> wrote:

> First off I will note that we've had very bad luck in the past with
> non-rabbit drivers getting traction either with developers or operators.
> Most of them have bit-rotted and been removed at this point.
>
> That said, we do have a list of requirements for oslo.messaging drivers
> in the documentation:
>
> https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html
>
> We realize those are non-trivial to achieve for a new driver, so in
> discussions about other drivers we've pursued the option of developing
> the new driver out of tree as either a third-party library or a feature
> branch in oslo.messaging. For NATS[0] we ended up going with a feature
> branch, although to my knowledge that hasn't really gone anywhere (see
> above about having bad luck with this sort of thing).
>
> The other unfortunate reality is that we've lost the messaging experts
> who would ideally have reviewed a new driver. Working in a feature
> branch that doesn't affect the released library mitigates this somewhat
> because issues can be worked out without affecting production
> deployments, but unfortunately it is an obstacle.
>
> That said, if someone were to develop a new driver that would probably
> go a long way toward making them a messaging expert so this might be a
> good way to replenish our talent pool in this area. :-)
>
> I don't want to discourage anyone from writing a new driver (I think
> everyone would love to get rid of rabbit), but before starting down that
> path I think it's important to understand that there is a lot of inertia
> behind rabbit and messaging is a complex topic. This is not a project
> that will take a few weeks. Even a few months is a stretch. You're going
> to need a rock solid driver implementation and then be able to show that
> it's enough better than rabbit to convince people to switch.
>
> So, if after all this doom and gloom you still want to move forward,
> feel free to write up a spec similar to the NATS one and we can get you
> a feature branch or repo to work in.
>
> 0: https://review.opendev.org/c/openstack/oslo-specs/+/692784
>
> On 2/13/22 20:54, liyang wrote:
> > Hi  everyone,
> >      I find Apache Pulsar is very popular in MQ area, especially in
> > clound native area. Is there any body integrate this MQ to
> oslo.messaging?
> >      Said to the truth. RabbitMQ developed in Erlang has very little
> > source code level material, Qpid has very little operation practice in
> > the internet. Kafka only support notification in oslo.messaging.
> >      I think the Apache Pulsar  is clound native based. It may enforece
> > the big scale in extension about Openstack deployment.
> >
> >
>
> --
Thanks,
    --Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/c78a2b0f/attachment-0001.htm>

From iurygregory at gmail.com  Tue Feb 15 03:17:02 2022
From: iurygregory at gmail.com (Iury Gregory)
Date: Tue, 15 Feb 2022 00:17:02 -0300
Subject: [ironic][election][ptl] PTL Candidacy for Zed Cycle
Message-ID: <CAJqPaj_EzGs-ej4PZ7jZpbdP02H-K5tPA0JmivkZ=N7XO8PONA@mail.gmail.com>

Hello, Ironicers and stackers!

I would like to submit my candidacy to continue serving as Ironic PTL for
the Zed cycle.

In the Yoga cycle, we are adding features to facilitate the cloud
operator's life (e.g., Ironic now can calculate the default value for any
enabled interface based on the `enabled_hardware_type`, verify steps). We
fixed bugs related to SW Raid, virtual media deployments, and many
others!

Let's continue working together so we can take over the world! =)

Best regards,
Iury Gregory Melo Ferreira

IRC: iurygregory
-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the ironic-core and puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/e3751c5f/attachment.htm>

From tpb at dyncloud.net  Tue Feb 15 03:46:49 2022
From: tpb at dyncloud.net (Tom Barron)
Date: Mon, 14 Feb 2022 22:46:49 -0500
Subject: [manila][ptl] Non-candidacy for the Z cycle
In-Reply-To: <CAKSuTPbLB894kSUgYjta6S=3D3czBNstmsJnpn95kPP7ak4cGg@mail.gmail.com>
References: <CAKSuTPbLB894kSUgYjta6S=3D3czBNstmsJnpn95kPP7ak4cGg@mail.gmail.com>
Message-ID: <20220215034649.2rk4r4kp56tb42em@barron.net>

On 14/02/22 11:21 -0800, Goutham Pacha Ravi wrote:
>Hey Zorillas and other interested Stackers,
>
>I took over as Manila PTL prior to the Ussuri cycle and have had fun
>running the project for 5 cycles. The itch for change hasn't subsided.
>So, I'd love to hand off the PTL baton and go back to being a
>maintainer (or whatever else you'll let my pompous behind claim to
>be). Despair not though, there's someone that has bright ideas and
>energy to enhance this role that intends to nominate themselves to
>lead us through the Zorilla (Zed) cycle!
>
>I'm very proud that I had your encouragement and support for the past
>~three years.
>We innovated and incorporated some fun practices that held the
>community together and grew it over time. We chipped away at tech debt
>in an organized fashion, created focus teams, added half a dozen core
>reviewers, mentored 20 (!) interns, squashed bugs, put together
>hackfests, collaborated on reviews and somehow made the
>pandemic-caused virtual project team gatherings fun as well. We will
>do so much more of this with the new PTL and the hyper-charged zorilla
>spirit :D So I'm very excited.
>
>Thank you for your support!
>
>--
>Goutham Pacha Ravi
>

Goutham,

I can't thank you enough for taking the helm as Manila PTL when I 
stepped down.  You accelerated whatever modest trajectory we had up to 
that point and showed us all how this project could truly excel.  As a 
"manager" you set up reliable processes and systems to organize our 
work and to organize sub-teams to focus on bug-squashing, the UI, 
tempest tests, and so on.  You recruited leaders in each of these 
areas, and delegated and empowered while maintaining the highest 
standards for the project.  With Victoria Martinez de la Cruz, you 
went out of your way to mentor and to mentor the mentors for our 
remarkable crop of interns in the last few years.  And indeed, you 
made the Manila community a fun place for folks from all over the 
world to work together.

You have left the project in great shape for the next PTL.

I know you have your own technical vision and your own particular 
development passions, so it will be fun both to watch others build on 
your accomplishments as a leader and to see what you propose and drive 
as a contributor to Manila and to OpenStack going forwards!

-- Tom Barron



From tpb at dyncloud.net  Tue Feb 15 03:57:02 2022
From: tpb at dyncloud.net (Tom Barron)
Date: Mon, 14 Feb 2022 22:57:02 -0500
Subject: [manila][election][ptl] PTL Candidacy for Z
In-Reply-To: <CAE51gQKRV4r4YvdPs2LMfTXXjQLknA5mmoR5W13y0bt=u0BRPw@mail.gmail.com>
References: <CAE51gQKRV4r4YvdPs2LMfTXXjQLknA5mmoR5W13y0bt=u0BRPw@mail.gmail.com>
Message-ID: <20220215035702.2glwd4otmuf6kvaf@barron.net>

On 14/02/22 20:24 -0300, Carlos Silva wrote:
>Hello, Zorillas and dear stackers,
>
>
>I would like to submit my candidacy to be the PTL of Manila for the Z cycle.
>
>I have been a contributor to OpenStack since the Stein release. It has been
>an
>awesome experience. During these years, I had the opportunity to contribute
>with new features, fixes, reviews and other exciting enhancements for
>Manila.
>I can tell you that I've faced thrilling challenges, and I learned a lot
>with
>the community that made this journey enjoyable day after day. I'm
>tremendously
>happy to see the state Manila is at. I'd like to keep the momentum for the
>project by continuing to focus in some areas we have been focusing, but also
>start tackling other issues:
>
>- Continue increasing the number of contributors and active reviewers
>through
>  mentoring and engaging them in the community, teaching the OpenStack way
>and
>  making it collaboratively as we did in the past cycles, promoting
>hackatons,
>  bug squashes and collaborative review sessions.
>
>
>- Encouraging the involvement of Manila contributors in important
>  programs/events such as GHC, Outreachy and the other opportunities we've
>been
>  able to contribute in the past.
>
>
>- Pursue the completion of the Manila implementation on the
>  openstackclient/openstacksdk;
>
>
>- Continue pushing Manila to cover the tech debt areas we identified over
>the
>  past cycles;
>
>
>- Enforcing maintainers to collaboratively cover the lack of documentation
>we
>  have on third party CI setups for Manila, helping potential new vendors to
>  quickly setup up their CI systems;
>
>
>- Continue discussing with community and making the necessary enhancements
>for
>  HA and Edge;
>
>Thank you for your consideration!
>
>Carlos da Silva
>IRC: carloss

Carlos,

I doubt you can see me right now, but I have a very big smile on my 
face.

I remember you first from gerrit - high quality submissions and 
reviews.  Then there was the Shanghai PTG, where I saw you help make 
everyone welcome, help ensure that everyone got heard, and fill in 
with tasks to help out with the group when there were gaps.  That's 
when I knew you'd be a great leader.

Thanks for "stepping up."

-- Tom Barron



From yasufum.o at gmail.com  Tue Feb 15 07:39:09 2022
From: yasufum.o at gmail.com (Yasufumi Ogawa)
Date: Tue, 15 Feb 2022 16:39:09 +0900
Subject: [election][tacker][ptl] PTL candidacy for Z
Message-ID: <15057893-9aeb-9aee-32cc-79a9833036ff@gmail.com>

Hi,

I'd like to propose my candidacy for Tacker PTL in Z cycle.

I have been a PTL from Victoria and made an effort to implement the latest
ETSI-NVF standard features to enable operators to deploy their services. 
In Yoga
release, we are going to provide several container supports for 
deploying CNFs,
multi-version APIs for mixed environment of legacy and cutting edge-products
provided by several vendors and more. We also had several collaborative 
sessions
with ETSI NFV for accelerating each activity of standardization and 
deployment
of required features.

In Z release, I would like to expand our target to VNFs for network 
acceleration
other than proceed to implement VM/container management features which 
has been
introduced in the previous releases. It has became one of the key 
requirements
of the recent commercial use cases such as 5GC.

Best regards,
Yasufumi (yasufum)


From radoslaw.piliszek at gmail.com  Tue Feb 15 08:07:01 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Tue, 15 Feb 2022 09:07:01 +0100
Subject: [tc][release] Removing TC tags framework - next steps for release
 notes
In-Reply-To: <cc65fbdd-c1f5-6539-0382-607de45439eb@est.tech>
References: <CAKZ_x795heRnzJuFRXGLBC7jE5kuwHoDjvDD5zBa+k9xYSUeCw@mail.gmail.com>
 <cc65fbdd-c1f5-6539-0382-607de45439eb@est.tech>
Message-ID: <CAKZ_x7_f00CvB28qQCz9yFy2H1PiA3C0fvQAVh9v6-3nAruzuQ@mail.gmail.com>

Thanks, El?d, for starting this!

I have replied on the change - for the tags framework removal to
succeed without breaking the scripts we also need to remove other
references to tags.
The banner was the most obvious usage but the tags are still used for
(likely even less used/useful) other purposes.

Kind regards,
-yoctozepto

On Mon, 14 Feb 2022 at 12:40, El?d Ill?s <elod.illes at est.tech> wrote:
>
> Hi,
>
> As far as I know the 'follows-stable-policy' tag is now works as kind of
> a reminder for release management team that the given deliverables needs
> some extra attention that it does not violate the stable policy. Though
> for example I always try to review the release content in this respect.
> For me this was a good indicator, but on the other hand, maybe it is not
> that relevant for the release team nowadays. If the TC decided that tags
> will be removed, I'm not against it. So I think it's OK to drop it.
>
> Regarding what needs to be done in release repository: I proposed a
> simple clean up script [1]. I think there is nothing else to do.
>
> @Release Management Team: let me know if you see something else that i
> might missed.
>
> [1] https://review.opendev.org/c/openstack/releases/+/829014
>
> Cheers,
>
> El?d
> (irc: elodilles @ #openstack-release)
>
>
> On 2022. 02. 13. 21:14, Rados?aw Piliszek wrote:
> > Hello Release Team,
> >
> > As you might have heard, the TC is removing the TC tags framework. [1]
> > The first step has already been proposed and is being voted on. [2]
> >
> > The removal of certain parts seems to be affecting the release team
> > tooling, especially with the usage of the stable:follows-policy tag to
> > show a relevant banner. [3]
> > The proposed change purposely avoids breaking the releases repo and
> > awaits a "part 2" which cleans up everything
> > TC-tags-framework-related.
> >
> > Thus, I am asking for your help to remove this dependency on the tags framework.
> > I understand there might be several approaches to this and need your
> > assistance to continue.
> > The simplest approach is to drop the relevant code - assuming it is
> > not actively used for release process purposes.
> > Obviously, for anything else I need your input on what the options are.
> > It is also possible that you would prefer to port this tag to your
> > internal metadata.
> > I am open to ideas and will help enact the changes.
> >
> > [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.html
> > [2] https://review.opendev.org/c/openstack/governance/+/822900
> > [3] https://opendev.org/openstack/releases/src/commit/768a12e233c23999db18c807c228b6ec0b042eea/openstack_releases/cmds/list_changes.py#L303
> >
> > Kind regards,
> > -yoctozepto
> >


From skaplons at redhat.com  Tue Feb 15 09:37:48 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 15 Feb 2022 10:37:48 +0100
Subject: Masquerading VM works 99%
In-Reply-To: <CAOAKi8wMGa0FRgT4SjTb85e8AkNUwfjyZ2XQZu35fusai5dreA@mail.gmail.com>
References: <46615849.557895.1644509565653.ref@mail.yahoo.com>
 <46615849.557895.1644509565653@mail.yahoo.com>
 <CAOAKi8wMGa0FRgT4SjTb85e8AkNUwfjyZ2XQZu35fusai5dreA@mail.gmail.com>
Message-ID: <5801622.lOV4Wx5bFT@p1>

Hi,

On pi?tek, 11 lutego 2022 20:31:24 CET Laurent Dumont wrote:
> You might want to look at port-security if you are using an Openstack VM as
> more of a router. By default, it will permit only it's own mac-address +
> ip-address from exiting the interface.
> 
> You can fully disable it to see if it's the root cause.
> 
>    1. Remove allowed-address-pairs.
>    2. Remove security-groups
>    3. Disable port-security.

It is very likely that the issue is caused by the port security on the 
internal interface of the external vm (where packets are dropped).

> 
> 
> On Thu, Feb 10, 2022 at 11:17 AM Derek O keeffe <derekokeeffe85 at yahoo.ie>
> 
> wrote:
> > Hi all,
> > 
> > We have an openstack cluster with one controller and 4 computes (Victoria)
> > we have set it up using vlan provider networks with linuxbridge agent,
> > distributed routing & ml2 (I am only partly on the networking so there
> > could be more to that which I can find out if needed)

ML2/Linuxbridge don't supports distributed routing (DVR) at all. What do You 
mean by "distributed routing" here?

> > 
> > So I was tasked with creating two Instances, one (lets call it the
> > external vm) with an external interface 10.55.9.67 and internal interface
> > 192.168.1.2. A second instance (lets call it the internal vm) would then 
be
> > placed on the 192.168.1.0 network.
> > 
> > I configured masquerading on the "external vm" and tried to ping the
> > outside world from the "internal" vm as per something like this
> > https://kifarunix.com/configure-ubuntu-20-04-as-linux-router/?unapproved=49
> > 571&moderation-hash=b5168c04420557dcdc088994ffa4bdbb#comment-49571
> > 
> > 
> > Both VM's were instantiated on the same compute host (I've tried it with
> > them on separate hosts as well).
> > 
> > I can see the ping leave using tcpdumps along the way and it makes it all
> > the way back to the internal interface on the external machine. It just
> > fails on the last hop to the internal machine. I've tried everything in my
> > power to find why this won't work so I would be grateful for any advice at
> > all. I have added the below to show how I followed the ping manually and
> > where it went and when it failed. Thank you in advance.
> > 
> > Following the ping from source to destination and back:
> > Generated on the private VM
> > sent to the internal interface on the external vm
> > sent to the external interface on the external vm
> > sent to the tap interface on the compute
> > sent to the physical nic on the compute
> > sent to the nic on the network device out to the internet
> > 
> > received on nic on the network devicefrom the internet
> > received on physical nic on the compute
> > received on tap interface on compute
> > received on external interface on the external vm
> > received on the internal interface on the external vm
> > NEVER gets to last step on the internal vm
> > 
> > Regards,
> > Derek



-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/697c9680/attachment-0001.sig>

From skaplons at redhat.com  Tue Feb 15 10:46:34 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 15 Feb 2022 11:46:34 +0100
Subject: [neutron][ci] Agenda for the CI meeting - Tuesday 15.02.2022
Message-ID: <2235533.ElGaqSPkdT@p1>

Hi,

Agenda for today's CI meeting is at [1]. Please remember that our today's 
meeting will be video meeting on [2].
See You there at 1500 UTC today.

[1] https://etherpad.opendev.org/p/neutron-ci-meetings
[2] https://meetpad.opendev.org/neutron-ci-meetings

-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/739b486f/attachment.sig>

From rigault.francois at gmail.com  Tue Feb 15 10:49:30 2022
From: rigault.francois at gmail.com (Francois)
Date: Tue, 15 Feb 2022 11:49:30 +0100
Subject: [keystone] anyone using OpenID with Keystone?
Message-ID: <CAMc2VtR1ZU0W3qhxymoQCJZKZWnRxpcqbgj-CsGduZMUgVoVjA@mail.gmail.com>

Hi Keystone users!
I am wondering if anyone has experience with keystone openid integration.
Initially I was using Keystone LDAP backend (using tripleo
KeystoneLDAPDomainEnable and KeystoneLDAPBackendConfigs parameters)
and it works! Users are able to log in through Horizon or through the
cli, roles can be given per LDAP group, and you can click in Horizon
and download a working openrc or clouds.yaml file (minus the root CA
that has to be added) to authenticate with the cli (and your password
ends as an OS_PASSWORD variable in your environment).

I am now trying the Keystone Openid backend (using the
enable-federation-openidc.yaml provided by tripleo -
https://github.com/openstack/tripleo-heat-templates/blob/master/environments/enable-federation-openidc.yaml)
with a mapping like this:

    [{"local":[{"user":{"name":"{0}"},"group":{"domain":{"name":"Default"},"name":"federated_users"}}],"remote":[{"type":"HTTP_OIDC_EMAIL"}]}]

The SSO works superb with Horizon, however
- logging with the cli seems impractical. I see some doc here:
https://docs.ukcloud.com/articles/openstack/ostack-how-use-api-sso.html
where you need to provide a secret, I am skeptical I  want to do that.
The openrc file downloaded from Horizon is not usable as is and needs
some tuning. And there is no SSO, and the password still ends up in
the environment...
- I don't see how I can grant roles to groups anymore. It seems I need
an extra mechanism to grant permissions (as I used to do that using
LDAP groups).


I am wondering if anyone is willing to share their experience dealing
with Keystone and OpenID.

Thanks!
Francois (frigo)


From jonathan.rosser at rd.bbc.co.uk  Tue Feb 15 10:59:45 2022
From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser)
Date: Tue, 15 Feb 2022 10:59:45 +0000
Subject: [keystone] anyone using OpenID with Keystone?
In-Reply-To: <CAMc2VtR1ZU0W3qhxymoQCJZKZWnRxpcqbgj-CsGduZMUgVoVjA@mail.gmail.com>
References: <CAMc2VtR1ZU0W3qhxymoQCJZKZWnRxpcqbgj-CsGduZMUgVoVjA@mail.gmail.com>
Message-ID: <b98f47ed-0f08-2191-9ea5-0f632a507ba6@rd.bbc.co.uk>

We have patched a keystoneauth plugin to support PKCE which does not 
require a client secret.

It requires your identity provider to support PKCE, keycloak in our case.

https://github.com/bbc/keystoneauth-oidc

Hope this is useful,
Jonathan.

On 15/02/2022 10:49, Francois wrote:
> Hi Keystone users!
> I am wondering if anyone has experience with keystone openid integration.
> Initially I was using Keystone LDAP backend (using tripleo
> KeystoneLDAPDomainEnable and KeystoneLDAPBackendConfigs parameters)
> and it works! Users are able to log in through Horizon or through the
> cli, roles can be given per LDAP group, and you can click in Horizon
> and download a working openrc or clouds.yaml file (minus the root CA
> that has to be added) to authenticate with the cli (and your password
> ends as an OS_PASSWORD variable in your environment).
>
> I am now trying the Keystone Openid backend (using the
> enable-federation-openidc.yaml provided by tripleo -
> https://github.com/openstack/tripleo-heat-templates/blob/master/environments/enable-federation-openidc.yaml)
> with a mapping like this:
>
>      [{"local":[{"user":{"name":"{0}"},"group":{"domain":{"name":"Default"},"name":"federated_users"}}],"remote":[{"type":"HTTP_OIDC_EMAIL"}]}]
>
> The SSO works superb with Horizon, however
> - logging with the cli seems impractical. I see some doc here:
> https://docs.ukcloud.com/articles/openstack/ostack-how-use-api-sso.html
> where you need to provide a secret, I am skeptical I  want to do that.
> The openrc file downloaded from Horizon is not usable as is and needs
> some tuning. And there is no SSO, and the password still ends up in
> the environment...
> - I don't see how I can grant roles to groups anymore. It seems I need
> an extra mechanism to grant permissions (as I used to do that using
> LDAP groups).
>
>
> I am wondering if anyone is willing to share their experience dealing
> with Keystone and OpenID.
>
> Thanks!
> Francois (frigo)
>
>


From rafaelweingartner at gmail.com  Tue Feb 15 11:33:41 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Tue, 15 Feb 2022 08:33:41 -0300
Subject: [election][cloudkitty] PTL candidacy for Zed
Message-ID: <CAG97raczPR=X-29kuOvt1bGG9cuxA-YnbhMjP=R8jATmvd7XLA@mail.gmail.com>

Hello guys,
I would like to self-nominate for the role of PTL of CloudKitty for the Zed
release cycle. I am the current PTL for the Xena cycle and I am willing to
continue in this role.
I will keep working with existing contributors to maintain CloudKitty for
their use cases and encourage the addition of new functionalities.

Thank you for your support,
-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/90eec9aa/attachment.htm>

From smooney at redhat.com  Tue Feb 15 12:27:03 2022
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 15 Feb 2022 12:27:03 +0000
Subject: oslo.messaging integration development
In-Reply-To: <4e20b1f1-030a-519a-aa8b-774d2d4f319d@nemebean.com>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
 <4e20b1f1-030a-519a-aa8b-774d2d4f319d@nemebean.com>
Message-ID: <97d0f2521e8fd991b5a1ff90a6eb66b4f60dd603.camel@redhat.com>

On Mon, 2022-02-14 at 10:32 -0600, Ben Nemec wrote:
> First off I will note that we've had very bad luck in the past with 
> non-rabbit drivers getting traction either with developers or operators. 
> Most of them have bit-rotted and been removed at this point.
> 
> That said, we do have a list of requirements for oslo.messaging drivers 
> in the documentation: 
> https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html
> 
> We realize those are non-trivial to achieve for a new driver, so in 
> discussions about other drivers we've pursued the option of developing 
> the new driver out of tree as either a third-party library or a feature 
> branch in oslo.messaging. For NATS[0] we ended up going with a feature 
> branch, although to my knowledge that hasn't really gone anywhere (see 
> above about having bad luck with this sort of thing).
> 
> The other unfortunate reality is that we've lost the messaging experts 
> who would ideally have reviewed a new driver. Working in a feature 
> branch that doesn't affect the released library mitigates this somewhat 
> because issues can be worked out without affecting production 
> deployments, but unfortunately it is an obstacle.
> 
> That said, if someone were to develop a new driver that would probably 
> go a long way toward making them a messaging expert so this might be a 
> good way to replenish our talent pool in this area. :-)
> 
> I don't want to discourage anyone from writing a new driver (I think 
> everyone would love to get rid of rabbit), but before starting down that 
> path I think it's important to understand that there is a lot of inertia 
> behind rabbit and messaging is a complex topic. This is not a project 
> that will take a few weeks. Even a few months is a stretch. You're going 
> to need a rock solid driver implementation and then be able to show that 
> it's enough better than rabbit to convince people to switch.
> 
> So, if after all this doom and gloom you still want to move forward, 
> feel free to write up a spec similar to the NATS one and we can get you 
> a feature branch or repo to work in.
> 
> 0: https://review.opendev.org/c/openstack/oslo-specs/+/692784
speaking of the NATS on is that actully moving forward.
i had high hopes that NATS could be a scalable cloud native replecement for rabit
im not familar with Apache Pulsar?https://pulsar.apache.org/ perhaps it has a similar feature set to NATS?https://nats.io/.
lookign at it however Apache Pulsar seams to be written in java. not to be language
snob but that might prove to be a barrier for deployment. that was an issue for monasca
in the past. addign another language runtime to the requirement to you cluster like
erlang is added by rabbit and java would be added by pulsar to me is a dissadvantage
as it increase the treath domain form a secuirty perspecitve.
https://github.com/apache/pulsar

NATS being written in go and therefor deployed a a single staticly linked binsary with no
runtime deps is one of the advantages it brings https://github.com/nats-io/nats-server

is apache/pulsar somthign that you specificly have exprenice with or wanted to use or just the first
non rabit solution that seamed to fit the requireemtns that you came across.
if so i think it would be worth your time asseing NATS too and perhaps collaberate with teh previous effort
or take it over if you find it equally suitable.
> 
> On 2/13/22 20:54, liyang wrote:
> > Hi? everyone,
> >  ? ? I find Apache Pulsar is very popular in MQ area, especially in 
> > clound native area. Is there any body integrate this MQ to oslo.messaging?
> >  ? ? Said to the truth. RabbitMQ developed in Erlang has very little 
> > source code level?material, Qpid has very little?operation practice in 
> > the internet. Kafka only support notification in oslo.messaging.
> >  ? ? I think the Apache Pulsar? is clound native based. It may enforece 
> > the big?scale in extension about Openstack deployment.
> > 
> > 
> 



From smooney at redhat.com  Tue Feb 15 12:45:05 2022
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 15 Feb 2022 12:45:05 +0000
Subject: [all][tc] OpenStack next release name is final- "OpenStack Zed"
In-Reply-To: <17efa5b6424.1213b1869357645.2623342301875640039@ghanshyammann.com>
References: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com>
 <450c1cc5-1154-97b4-21d3-cec769b8c869@redhat.com>
 <17ef97e6b7e.fa87b530351073.1185492487506837204@ghanshyammann.com>
 <CAKpbOATBOzCdvWVhdPOpmJJeRtHp8BQQiZkc9C5DnvU-04gFCQ@mail.gmail.com>
 <17efa5b6424.1213b1869357645.2623342301875640039@ghanshyammann.com>
Message-ID: <9f99d0403d671de7dcab8e1f58d6fb82fcff1af9.camel@redhat.com>

On Mon, 2022-02-14 at 16:30 -0600, Ghanshyam Mann wrote:
>  ---- On Mon, 14 Feb 2022 13:58:19 -0600 Frode Nordahl <frode.nordahl at canonical.com> wrote ----
>  > 
>  > 
>  > man. 14. feb. 2022, 19:36 skrev Ghanshyam Mann <gmann at ghanshyammann.com>:
>  >  ---- On Mon, 14 Feb 2022 11:53:04 -0600 Giulio Fidente <gfidente at redhat.com> wrote ----
>  >  > On 2/14/22 18:03, Ghanshyam Mann wrote:
>  >  > > Hello Everyone,
>  >  > > 
>  >  > > We have the final name selected for the OpenStack next release name. Its "OpenStack Zed".
>  >  > > 
>  >  > > As per the release name criteria[1], selection of release name has gone through three steps:
>  >  > > 
>  >  > > Step1: Name nomination from community members[2].
>  >  > > 
>  >  > > Step2: TC voted on the nominated names[3].
>  >  > > 
>  >  > > Step3: Trademark checks by Foundation on winners from TC votes.
>  >  > > In trademark check, ?Zed? is finalized as the best bet for this release.
>  >  > > 
>  >  > > Thanks community members for participating in name nomination, TC to vote and Foundation for performing the
>  >  > > trademark checks.
>  >  > > 
>  >  > > [1] https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria
>  >  > > [2] https://wiki.openstack.org/wiki/Release_Naming/Z_Proposals
>  >  > > [3] https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f
>  >  > 
>  >  > hi there, thanks for the update
>  >  > 
>  >  > I have a stupid, please excuse me if it was written already in some 
>  >  > previous message: the poll results at [3] suggest that most voted were:
>  >  > 
>  >  > 1. Zen - after Yoga, you should get Zen)  (Not defeated in any contest 
>  >  > vs. another choice)
>  >  > 2. Zombie - an undead
>  >  > 3. Zeta , loses to Zombie - an undead by 5?2
>  >  > 4. Zed , loses to Zombie - an undead by 4?1
>  >  > 
>  >  > did 1,2,3 fail the trademark checks?
>  > 
>  > Yes, as per the trademark checks done by the Foundation, Zed is the best choice.
>  > 
>  > Has this passed a cultural check as well?
>  > YMMV, but a few generations will immediately associate this name with a not so flattering scene [4] from the timeless classic motion picture named Pulp Fiction.
>  > 4: https://youtu.be/5lL1ypndnWA
> 
> We did check on ML and asked all the community members for the culture or historical objection on proposed names before election and it
> seems no objection.
> 
> - https://lists.openstack.org/pipermail/openstack-discuss/2022-January/026868.html
since one has been raised now is the TC goingt to revaulate the name in there next meeting?
i am proably on the border of getting the refernce being born in 1989 i have seen pulp fiction 3 or 4 times but ill
admit the name did not ring a bell or make a connection to the zed charicter. while zed is proably my least prefered choice
from the 4 option that were trade mark checked( im not going to actully express my prefernce to avoid biasing this dicsuction)
 part of me does like the irony of the Z release being zed in the same as homer j simpsoncs middel name is jay but that pun
only works if you pernouch "Z" as zed and not "zee". that is the primary asscation that think of when i here zed for Z.
The TC shoudl proably at least discuss it in the next meeting an reaffirm there previous decsion or revaulate.
> 
> -gmann
> 
>  > --Frode Nordahl
>  > -gmann
>  > 
>  >  > 
>  >  > thanks
>  >  > -- 
>  >  > Giulio Fidente
>  >  > GPG KEY: 08D733BA
>  >  > 
>  >  > 
>  >  >      
>  > 
>  > 	
> 



From fernandoperches at gmail.com  Tue Feb 15 13:52:32 2022
From: fernandoperches at gmail.com (Fernando Ferraz)
Date: Tue, 15 Feb 2022 10:52:32 -0300
Subject: [manila][election][ptl] PTL Candidacy for Z
In-Reply-To: <CAE51gQKRV4r4YvdPs2LMfTXXjQLknA5mmoR5W13y0bt=u0BRPw@mail.gmail.com>
References: <CAE51gQKRV4r4YvdPs2LMfTXXjQLknA5mmoR5W13y0bt=u0BRPw@mail.gmail.com>
Message-ID: <CAGO9e9vb3gwq1ADQ1gWBHYnhTn8Ep9SLNxO7X65TiwpuK2fY1w@mail.gmail.com>

Carlos is the most dedicated and talented professional I had the
opportunity to work with as a teammate and he is fully committed to the
OpenStack community. I believe he is definitely up to the task.
I'm not a core but would like to leave a +1 here as well. :)

Fernando

Em seg., 14 de fev. de 2022 ?s 20:29, Carlos Silva <ces.eduardo98 at gmail.com>
escreveu:

> Hello, Zorillas and dear stackers,
>
>
> I would like to submit my candidacy to be the PTL of Manila for the Z
> cycle.
>
> I have been a contributor to OpenStack since the Stein release. It has
> been an
> awesome experience. During these years, I had the opportunity to contribute
> with new features, fixes, reviews and other exciting enhancements for
> Manila.
> I can tell you that I've faced thrilling challenges, and I learned a lot
> with
> the community that made this journey enjoyable day after day. I'm
> tremendously
> happy to see the state Manila is at. I'd like to keep the momentum for the
> project by continuing to focus in some areas we have been focusing, but
> also
> start tackling other issues:
>
> - Continue increasing the number of contributors and active reviewers
> through
>   mentoring and engaging them in the community, teaching the OpenStack way
> and
>   making it collaboratively as we did in the past cycles, promoting
> hackatons,
>   bug squashes and collaborative review sessions.
>
>
> - Encouraging the involvement of Manila contributors in important
>   programs/events such as GHC, Outreachy and the other opportunities we've
> been
>   able to contribute in the past.
>
>
> - Pursue the completion of the Manila implementation on the
>   openstackclient/openstacksdk;
>
>
> - Continue pushing Manila to cover the tech debt areas we identified over
> the
>   past cycles;
>
>
> - Enforcing maintainers to collaboratively cover the lack of documentation
> we
>   have on third party CI setups for Manila, helping potential new vendors
> to
>   quickly setup up their CI systems;
>
>
> - Continue discussing with community and making the necessary enhancements
> for
>   HA and Edge;
>
> Thank you for your consideration!
>
> Carlos da Silva
> IRC: carloss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/70e421d4/attachment.htm>

From rosmaita.fossdev at gmail.com  Tue Feb 15 14:17:41 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Tue, 15 Feb 2022 09:17:41 -0500
Subject: [election][tc] TC candidacy for Z
Message-ID: <4d806935-2bcf-5de8-3710-8f1a45c8c674@gmail.com>

Hello Everyone,

I am declaring my candidacy for the Technical Committee.

I've been involved in OpenStack for a while now (my first commit
was into Folsom).  I've been a very active member of the community
as a core member of the Glance, Cinder, and Searchlight teams.  I've
attended many PTGs and presented at many Summits.  I've also served
as PTL for Glance (Ocata through Queens) and Cinder (Ussuri through
Yoga).  You may have seen my clever irc nick, 'rosmaita', mostly in
#openstack-cinder and #openstack-glance, but occasionally making a
pest of myself in other channels.

The TC is tasked with providing technical leadership for OpenStack
as a whole and enforcing the OpenStack ideals (the Four Opens [0],
the Guiding Principles [1]).  While the TC's primary mission is to
provide technical leadership, promoting the ideals calls for a
broader membership than just technical people actively developing
OpenStack.  So I think it's appropriate that TC membership includes
operators, distributors, and cultural members of the OpenStack
community.  But it's also important that the TC include highly
technical people who contribute to the projects it oversees [2].  I
believe that I'm well-suited to represent that constituency.

I don't have an agenda other than to represent active contributors
and participate in the TC in a manner consistent with its
charter [3].  If you ask people who've worked with me, you'll find
that I'm good about making sure discussions are done in the open,
and that all parties concerned are listened to.  I'll bring these
qualities to the TC.

Finally, I should probably mention who pays my bills.  I'm a
Principal Software Engineer at Red Hat.  As you're hopefully aware,
Red Hat has an "upstream first" philosophy [4], which is pretty
evident when you look at code contributions to OpenStack, but which
also extends to the company encouraging us, when participating in an
open source community, to make decisions based on the needs and goals
of the community rather than those of Red Hat.  (That sounds very
noble, but the idea is that a strong community benefits Red Hat in
the long run.  My key point here, though, is that I'm empowered to
represent the OpenStack community's interest, not Red Hat's, if I'm
elected to the TC.)

Thanks for reading this far, and thank you for considering my
candidacy for the OpenStack Technical Committee.

- Brian Rosmaita (rosmaita)


[0] https://governance.openstack.org/tc/reference/opens.html
[1] https://governance.openstack.org/tc/reference/principles.html
[2] I appropriated this line from Dan Smith.
[3] https://governance.openstack.org/tc/reference/charter.html
[4] 
https://opensource.com/article/16/12/why-red-hat-takes-upstream-first-approach


From flux.adam at gmail.com  Tue Feb 15 14:44:27 2022
From: flux.adam at gmail.com (Adam Harwell)
Date: Tue, 15 Feb 2022 23:44:27 +0900
Subject: oslo.messaging integration development
In-Reply-To: <97d0f2521e8fd991b5a1ff90a6eb66b4f60dd603.camel@redhat.com>
References: <f76c6fe.c20.17ef6277719.Coremail.ly2008080808@yeah.net>
 <4e20b1f1-030a-519a-aa8b-774d2d4f319d@nemebean.com>
 <97d0f2521e8fd991b5a1ff90a6eb66b4f60dd603.camel@redhat.com>
Message-ID: <CAHxXnhew+648RY_NxyqqQ8EY2nbepivAn2qib+60FvDNHK59vQ@mail.gmail.com>

At  least in our case, Pulsar was developed in house here at Yahoo
originally and we have very large deployments and many experts (most
original major contributors) available directly. So, I?m a little biased. :D

On Tue, Feb 15, 2022 at 21:31 Sean Mooney <smooney at redhat.com> wrote:

> On Mon, 2022-02-14 at 10:32 -0600, Ben Nemec wrote:
> > First off I will note that we've had very bad luck in the past with
> > non-rabbit drivers getting traction either with developers or operators.
> > Most of them have bit-rotted and been removed at this point.
> >
> > That said, we do have a list of requirements for oslo.messaging drivers
> > in the documentation:
> >
> https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html
> >
> > We realize those are non-trivial to achieve for a new driver, so in
> > discussions about other drivers we've pursued the option of developing
> > the new driver out of tree as either a third-party library or a feature
> > branch in oslo.messaging. For NATS[0] we ended up going with a feature
> > branch, although to my knowledge that hasn't really gone anywhere (see
> > above about having bad luck with this sort of thing).
> >
> > The other unfortunate reality is that we've lost the messaging experts
> > who would ideally have reviewed a new driver. Working in a feature
> > branch that doesn't affect the released library mitigates this somewhat
> > because issues can be worked out without affecting production
> > deployments, but unfortunately it is an obstacle.
> >
> > That said, if someone were to develop a new driver that would probably
> > go a long way toward making them a messaging expert so this might be a
> > good way to replenish our talent pool in this area. :-)
> >
> > I don't want to discourage anyone from writing a new driver (I think
> > everyone would love to get rid of rabbit), but before starting down that
> > path I think it's important to understand that there is a lot of inertia
> > behind rabbit and messaging is a complex topic. This is not a project
> > that will take a few weeks. Even a few months is a stretch. You're going
> > to need a rock solid driver implementation and then be able to show that
> > it's enough better than rabbit to convince people to switch.
> >
> > So, if after all this doom and gloom you still want to move forward,
> > feel free to write up a spec similar to the NATS one and we can get you
> > a feature branch or repo to work in.
> >
> > 0: https://review.opendev.org/c/openstack/oslo-specs/+/692784
> speaking of the NATS on is that actully moving forward.
> i had high hopes that NATS could be a scalable cloud native replecement
> for rabit
> im not familar with Apache Pulsar https://pulsar.apache.org/ perhaps it
> has a similar feature set to NATS https://nats.io/.
> lookign at it however Apache Pulsar seams to be written in java. not to be
> language
> snob but that might prove to be a barrier for deployment. that was an
> issue for monasca
> in the past. addign another language runtime to the requirement to you
> cluster like
> erlang is added by rabbit and java would be added by pulsar to me is a
> dissadvantage
> as it increase the treath domain form a secuirty perspecitve.
> https://github.com/apache/pulsar
>
> NATS being written in go and therefor deployed a a single staticly linked
> binsary with no
> runtime deps is one of the advantages it brings
> https://github.com/nats-io/nats-server
>
> is apache/pulsar somthign that you specificly have exprenice with or
> wanted to use or just the first
> non rabit solution that seamed to fit the requireemtns that you came
> across.
> if so i think it would be worth your time asseing NATS too and perhaps
> collaberate with teh previous effort
> or take it over if you find it equally suitable.
> >
> > On 2/13/22 20:54, liyang wrote:
> > > Hi  everyone,
> > >      I find Apache Pulsar is very popular in MQ area, especially in
> > > clound native area. Is there any body integrate this MQ to
> oslo.messaging?
> > >      Said to the truth. RabbitMQ developed in Erlang has very little
> > > source code level material, Qpid has very little operation practice in
> > > the internet. Kafka only support notification in oslo.messaging.
> > >      I think the Apache Pulsar  is clound native based. It may
> enforece
> > > the big scale in extension about Openstack deployment.
> > >
> > >
> >
>
>
> --
Thanks,
    --Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/b9dd349c/attachment.htm>

From akekane at redhat.com  Tue Feb 15 14:47:41 2022
From: akekane at redhat.com (Abhishek Kekane)
Date: Tue, 15 Feb 2022 20:17:41 +0530
Subject: [glance] Zed PTG Planning
Message-ID: <CALOt+STNgu2bKB7raG585DMbPJhm0MnH91h-xav8qGfgSM+Yqg@mail.gmail.com>

Hello Everyone!!!

As you are already aware that Zed virtual PTG will be held between April
4th to 8th [1].

Please use below etherpad to add the topics you would like to discuss
during PTG.
https://etherpad.opendev.org/p/zed-ptg-glance-planning
<https://etherpad.opendev.org/p/yoga-ptg-glance-planning>

[1] https://openinfra-ptg.eventbrite.com/

Thanks & Best Regards,

Abhishek Kekane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/b3614e37/attachment.htm>

From adivya1.singh at gmail.com  Tue Feb 15 15:26:07 2022
From: adivya1.singh at gmail.com (Adivya Singh)
Date: Tue, 15 Feb 2022 20:56:07 +0530
Subject: Create Image in queue State in XENA Version
Message-ID: <CA+ykd604jf=tbSmgLBb7PDdAeSjYbg+OmDgJBgmL3bCcbprdUQ@mail.gmail.com>

Hi Team,

We have lately upgraded to Xena , but when users trying to upload any
image, it is always in queue state, i did not see any error regarding any
issue with glance configuration file.

Any thoughts on this

Regards
Adivya Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/5ac85c24/attachment.htm>

From arne.wiebalck at cern.ch  Tue Feb 15 15:42:26 2022
From: arne.wiebalck at cern.ch (Arne Wiebalck)
Date: Tue, 15 Feb 2022 16:42:26 +0100
Subject: [election][tc] TC candidacy for Z release
Message-ID: <c26fd139-d587-c58e-42d0-e4fc7c1b5c7e@cern.ch>

Hello Everyone!

I would like to declare my candidacy for the Technical Committee.

I joined the CERN OpenStack team in 2014, initially to help with
the operations of the storage components (Cinder, later Manila),
and since 2016 I am looking after the overall operations of our
cloud infrastructure service here at CERN.

As part of this operational role, I have contributed upstream to
several projects [1], recently mostly to Ironic which I help as a
core member since about three years. I chair the Bare Metal SIG [2]
since its inception, and together with other community members I am
trying to establish it as a forum to promote the use of OpenStack
for bare metal use cases [3] and to help new users to get started.
Presentations at several summits [4] and regular blog posts [5] are
examples of how I share the operational challenges and the solutions
we apply in our cloud, in the hope these are helpful to other deployers
in the same way we profit from them sharing their experiences.

The combination of running an in-production OpenStack deployment
downstream while interacting with core developers and the overall
community upstream is something that I've enjoyed _a lot_ since
several years now. I see how real-life input can be essential for
upstream projects to move forward, set priorities, or maintain
momentum.  Equally, interaction with a responsive community where
feedback is turned into tangible improvements is a valuable asset
for any deployment.

This positive experience of being an operator/developer hybrid in
the OpenStack community is something I would like to bring to the
TC, assisting with the ongoing (but continuous) effort to engage
operators and help when global technical issues need to be sorted.

I am sure being a member of the TC and helping with its work comes
with a learning curve, but I'd be happy to contribute where I can.

Thanks for reading and your consideration!

Arne Wiebalck
IRC (OFTC): arne_wiebalck


[1] 
https://www.stackalytics.io/?metric=commits&release=all&user_id=arne-wiebalck
[2] https://etherpad.opendev.org/p/bare-metal-sig
[3] https://www.youtube.com/playlist?list=PLKqaoAnDyfgoBFAjUvZGjKXQjogWZBLL_
[4] https://www.openstack.org/videos/search?search=wiebalck
[5] https://techblog.web.cern.ch/techblog/


From laurentfdumont at gmail.com  Tue Feb 15 05:39:49 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Tue, 15 Feb 2022 00:39:49 -0500
Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud
In-Reply-To: <CAJm6b-6s-Ohrj7yykjZ67Ksv_sy+6hm8hBN2WiG-y=ik-6cd-w@mail.gmail.com>
References: <CAKxkTi0dx-vAhhk_BJMTRsKYiNSS-J6cjA5K8XiLQgaEvJmE5g@mail.gmail.com>
 <CAF7gwdhM6ypQgzHB-hWnbkvXW1exqeNYCpzzENyuq3so=awehw@mail.gmail.com>
 <CAKxkTi37dLsQvAiaanEtKDrFXzEk1R5bxSyp6m0jbdZJeRNMYg@mail.gmail.com>
 <CAF7gwdj-Dgfqwi-6o-zYjaTnn3ts3J9LmK7gQQwnOxE-WcUJbQ@mail.gmail.com>
 <CAKxkTi1gtZ7LBVus2=skpqg12BxB+UWgtT1HxbThf1xBrnD=UA@mail.gmail.com>
 <CAF7gwdgxe=HOp8fVHMpKCcTBvRmW2jzsSNnjhmuXN_bt+GZpwA@mail.gmail.com>
 <CAKxkTi1qioQBWLnSOpYot9_raC+RkNKrizkXUv9gsix0Cqw6mw@mail.gmail.com>
 <CAKxkTi2xa4BQhe5_v2_KrdTwxLNupeM69j1hTdBUg+tr_jfxTw@mail.gmail.com>
 <fae06776-7f28-6096-1bf3-8ce9f42eefa1@redhat.com>
 <CAJm6b-7gfbYz5_gbqq8fjJDuiVf2H+9wUS=tOq_qO9QS=WuGMA@mail.gmail.com>
 <dc1844d4-ca11-c783-4990-8280b3a305aa@redhat.com>
 <CAJm6b-4+z67on3D94k02m5yN79Yr91TdFyN=vntKmSQNBBK+pQ@mail.gmail.com>
 <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com>
 <CAJm6b-6PYvKPW4AVd19uTmRk=j2Uw-Gh6fjNjDhBOvB0zyMGpg@mail.gmail.com>
 <CAJm6b-5+6=sWB2yXf8-mToBKdA53paSxRiP0WQ9Bqi+Dfnn84w@mail.gmail.com>
 <CAF7gwditOunfQH-Whc1rY8M9bbH52d2xOJK06oeroUCaV-4-cg@mail.gmail.com>
 <CAJm6b-6s-Ohrj7yykjZ67Ksv_sy+6hm8hBN2WiG-y=ik-6cd-w@mail.gmail.com>
Message-ID: <CAOAKi8wQZLPyf8GHiOj1px_ROS_nVBccL2qzsSSaBOGshzKjXw@mail.gmail.com>

>From what I understand of baremetal nodes, they will show up as hypervisors
from the Nova perspective.

Can you try "openstack hypervisor list"

>From the doc

Each bare metal node becomes a separate hypervisor in Nova. The hypervisor
host name always matches the associated node UUID.

On Mon, Feb 14, 2022 at 10:03 AM Lokendra Rathour <lokendrarathour at gmail.com>
wrote:

> Hi Julia,
> Thanks once again. we got your point and understood the issue, but we
> still are facing the same issue on our TRIPLEO Train HA Setup, even if the
> settings are done as per your recommendations.
>
> The error that we are seeing is  again "*No valid host was found"*
>
> (overcloud) [stack at undercloud v4]$ openstack server show bm-server
> --fit-width
>
> +-------------------------------------+----------------------------------------------------------------------------------------+
> | Field                               | Value
>                                                      |
>
> +-------------------------------------+----------------------------------------------------------------------------------------+
> | OS-DCF:diskConfig                   | MANUAL
>                                                     |
> | OS-EXT-AZ:availability_zone         |
>                                                      |
> | OS-EXT-SRV-ATTR:host                | None
>                                                     |
> | OS-EXT-SRV-ATTR:hostname            | bm-server
>                                                      |
> | OS-EXT-SRV-ATTR:hypervisor_hostname | None
>                                                     |
> | OS-EXT-SRV-ATTR:instance_name       | instance-00000014
>                                                      |
> | OS-EXT-SRV-ATTR:kernel_id           |
>                                                      |
> | OS-EXT-SRV-ATTR:launch_index        | 0
>                                                      |
> | OS-EXT-SRV-ATTR:ramdisk_id          |
>                                                      |
> | OS-EXT-SRV-ATTR:reservation_id      | r-npd6m9ah
>                                                     |
> | OS-EXT-SRV-ATTR:root_device_name    | None
>                                                     |
> | OS-EXT-SRV-ATTR:user_data           |
> I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnBhc3N3b3JkOiBoc2MzMjEKc3NoX3B3YXV0aDogdH
> |
> |                                     |
> J1ZQptYW5hZ2VfZXRjX2hvc3RzOiB0cnVlCmNocGFzc3dkOiB7ZXhwaXJlOiBmYWxzZSB9Cg==
>             |
> | OS-EXT-STS:power_state              | NOSTATE
>                                                      |
> | OS-EXT-STS:task_state               | None
>                                                     |
> | OS-EXT-STS:vm_state                 | error
>                                                      |
> | OS-SRV-USG:launched_at              | None
>                                                     |
> | OS-SRV-USG:terminated_at            | None
>                                                     |
> | accessIPv4                          |
>                                                      |
> | accessIPv6                          |
>                                                      |
> | addresses                           |
>                                                      |
> | config_drive                        | True
>                                                     |
> | created                             | 2022-02-14T10:20:48Z
>                                                     |
> | description                         | None
>                                                     |
> | fault                               | {'code': 500, 'created':
> '2022-02-14T10:20:49Z', 'message': 'No valid host was found.  |
> |                                     | There are not enough hosts
> available.', 'details': 'Traceback (most recent call        |
> |                                     | last):\n  File
> "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line      |
> |                                     | 1379, in
> schedule_and_build_instances\n    instance_uuids, return_alternates=True)\n
>   |
> |                                     | File
> "/usr/lib/python3.6/site-packages/nova/conductor/manager.py", line 839, in
>        |
> |                                     | _schedule_instances\n
>  return_alternates=return_alternates)\n  File                  |
> |                                     |
> "/usr/lib/python3.6/site-packages/nova/scheduler/client/query.py", line 42,
> in         |
> |                                     | select_destinations\n
>  instance_uuids, return_objects, return_alternates)\n  File    |
> |                                     |
> "/usr/lib/python3.6/site-packages/nova/scheduler/rpcapi.py", line 160, in
>            |
> |                                     | select_destinations\n    return
> cctxt.call(ctxt, \'select_destinations\',              |
> |                                     | **msg_args)\n  File
> "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/client.py",   |
> |                                     | line 181, in call\n
>  transport_options=self.transport_options)\n  File               |
> |                                     |
> "/usr/lib/python3.6/site-packages/oslo_messaging/transport.py", line 129,
> in _send\n   |
> |                                     |
> transport_options=transport_options)\n  File "/usr/lib/python3.6/site-
>             |
> |                                     |
> packages/oslo_messaging/_drivers/amqpdriver.py", line 674, in send\n
>             |
> |                                     |
> transport_options=transport_options)\n  File "/usr/lib/python3.6/site-
>             |
> |                                     |
> packages/oslo_messaging/_drivers/amqpdriver.py", line 664, in _send\n
>  raise         |
> |                                     |
> result\nnova.exception_Remote.NoValidHost_Remote: No valid host was found.
> There are   |
> |                                     | not enough hosts
> available.\nTraceback (most recent call last):\n\n  File              |
> |                                     |
> "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 235,
> in inner\n  |
> |                                     | return func(*args, **kwargs)\n\n
>  File "/usr/lib/python3.6/site-                       |
> |                                     |
> packages/nova/scheduler/manager.py", line 214, in select_destinations\n
>            |
> |                                     | allocation_request_version,
> return_alternates)\n\n  File "/usr/lib/python3.6/site-     |
> |                                     |
> packages/nova/scheduler/filter_scheduler.py", line 96, in
> select_destinations\n        |
> |                                     | allocation_request_version,
> return_alternates)\n\n  File "/usr/lib/python3.6/site-     |
> |                                     |
> packages/nova/scheduler/filter_scheduler.py", line 265, in _schedule\n
>             |
> |                                     | claimed_instance_uuids)\n\n  File
> "/usr/lib/python3.6/site-                            |
> |                                     |
> packages/nova/scheduler/filter_scheduler.py", line 302, in
> _ensure_sufficient_hosts\n  |
> |                                     | raise
> exception.NoValidHost(reason=reason)\n\nnova.exception.NoValidHost: No
> valid     |
> |                                     | host was found. There are not
> enough hosts available.\n\n'}                            |
> | flavor                              | disk='470', ephemeral='0',
>                                                     |
> |                                     |
> extra_specs.capabilities='boot_mode:uefi,boot_option:local',
>             |
> |                                     |
> extra_specs.resources:CUSTOM_BAREMETAL_RESOURCE_CLASS='1',
>             |
> |                                     | extra_specs.resources:DISK_GB='0',
> extra_specs.resources:MEMORY_MB='0',                |
> |                                     | extra_specs.resources:VCPU='0',
> original_name='bm-flavor', ram='63700', swap='0',      |
> |                                     | vcpus='20'
>                                                     |
> | hostId                              |
>                                                      |
> | host_status                         |
>                                                      |
> | id                                  |
> 49944a1f-7758-4522-9ef1-867ede44b3fc
>             |
> | image                               | whole-disk-centos
> (80724772-c760-4136-b453-754456d7c549)                               |
> | key_name                            | None
>                                                     |
> | locked                              | False
>                                                      |
> | locked_reason                       | None
>                                                     |
> | name                                | bm-server
>                                                      |
> | project_id                          | 8dde31e24eba41bfb7212ae154d61268
>                                                     |
> | properties                          |
>                                                      |
> | server_groups                       | []
>                                                     |
> | status                              | ERROR
>                                                      |
> | tags                                | []
>                                                     |
> | trusted_image_certificates          | None
>                                                     |
> | updated                             | 2022-02-14T10:20:49Z
>                                                     |
> | user_id                             | f689d147221549f1a6cbd1310078127d
>                                                     |
> | volumes_attached                    |
>                                                      |
>
> +-------------------------------------+----------------------------------------------------------------------------------------+
> (overcloud) [stack at undercloud v4]$
> (overcloud) [stack at undercloud v4]$
>
>  For your reference our update flavor and baremetal node properties are as
> below:
>
> (overcloud) [stack at undercloud v4]$ *openstack flavor show bm-flavor
> --fit-width*
>
> +----------------------------+-------------------------------------------------------------------------------------------------+
> | Field                      | Value
>                                                     |
>
> +----------------------------+-------------------------------------------------------------------------------------------------+
> | OS-FLV-DISABLED:disabled   | False
>                                                     |
> | OS-FLV-EXT-DATA:ephemeral  | 0
>                                                     |
> | access_project_ids         | None
>                                                      |
> | description                | None
>                                                      |
> | disk                       | 470
>                                                     |
> | extra_specs                |
> {'resources:CUSTOM_BAREMETAL_RESOURCE_CLASS': '1', 'resources:VCPU': '0',
>                     |
> |                            | 'resources:MEMORY_MB': '0',
> 'resources:DISK_GB': '0', 'capabilities':                           |
> |                            | 'boot_mode:uefi,boot_option:local'}
>                                                     |
> | id                         | 021c3021-56ec-4eba-bf57-c516ee9b2ee3
>                                                      |
> | name                       | bm-flavor
>                                                     |
> | os-flavor-access:is_public | True
>                                                      |
> | properties                 |*
> capabilities='boot_mode:uefi,boot_option:local',
> resources:CUSTOM_BAREMETAL_RESOURCE_CLASS='1', |*
> |                            | resources:DISK_GB='0',
> resources:MEMORY_MB='0', resources:VCPU='0'                              |
> | ram                        | 63700
>                                                     |
> | rxtx_factor                | 1.0
>                                                     |
> | swap                       | 0
>                                                     |
> | vcpus                      | 20
>                                                      |
>
> +----------------------------+-------------------------------------------------------------------------------------------------+
> (overcloud) [stack at undercloud v4]$
>
> (overcloud) [stack at undercloud v4]$
>
> (overcloud) [stack at undercloud v4]$* openstack baremetal node show
> baremetal-node --fit-width*
>
> +------------------------+-----------------------------------------------------------------------------------------------------+
> | Field                  | Value
>                                                     |
>
> +------------------------+-----------------------------------------------------------------------------------------------------+
> | allocation_uuid        | None
>                                                      |
> | automated_clean        | None
>                                                      |
> | bios_interface         | no-bios
>                                                     |
> | boot_interface         | ipxe
>                                                      |
> | chassis_uuid           | None
>                                                      |
> | clean_step             | {}
>                                                      |
> | conductor              | overcloud-controller-0.localdomain
>                                                      |
> | conductor_group        |
>                                                     |
> | console_enabled        | False
>                                                     |
> | console_interface      | ipmitool-socat
>                                                      |
> | created_at             | 2022-02-14T10:05:32+00:00
>                                                     |
> | deploy_interface       | iscsi
>                                                     |
> | deploy_step            | {}
>                                                      |
> | description            | None
>                                                      |
> | driver                 | ipmi
>                                                      |
> | driver_info            | {'ipmi_port': 623, 'ipmi_username': 'hsc',
> 'ipmi_password': '******', 'ipmi_address': '10.0.1.183', |
> |                        | 'deploy_kernel':
> '95a5b644-c04e-4a66-8f2b-e1e9806bed6e', 'deploy_ramdisk':
>        |
> |                        | '17644220-e623-4981-ae77-d789657851ba'}
>                                                     |
> | driver_internal_info   | {'agent_erase_devices_iterations': 1,
> 'agent_erase_devices_zeroize': True,                          |
> |                        | 'agent_continue_if_ata_erase_failed': False,
> 'agent_enable_ata_secure_erase': True,                 |
> |                        | 'disk_erasure_concurrency': 1,
> 'last_power_state_change': '2022-02-14T10:15:05.062161',             |
> |                        | 'agent_version': '5.0.5.dev25',
> 'agent_last_heartbeat': '2022-02-14T10:14:59.666025',               |
> |                        | 'hardware_manager_version':
> {'generic_hardware_manager': '1.1'}, 'agent_cached_clean_steps':        |
> |                        | {'deploy': [{'step': 'erase_devices',
> 'priority': 10, 'interface': 'deploy', 'reboot_requested':    |
> |                        | False, 'abortable': True}, {'step':
> 'erase_devices_metadata', 'priority': 99, 'interface':          |
> |                        | 'deploy', 'reboot_requested': False,
> 'abortable': True}], 'raid': [{'step': 'delete_configuration', |
> |                        | 'priority': 0, 'interface': 'raid',
> 'reboot_requested': False, 'abortable': True}, {'step':         |
> |                        | 'create_configuration', 'priority': 0,
> 'interface': 'raid', 'reboot_requested': False, 'abortable': |
> |                        | True}]}, 'agent_cached_clean_steps_refreshed':
> '2022-02-14 10:14:58.093777', 'clean_steps': None}   |
> | extra                  | {}
>                                                      |
> | fault                  | None
>                                                      |
> | inspect_interface      | inspector
>                                                     |
> | inspection_finished_at | None
>                                                      |
> | inspection_started_at  | None
>                                                      |
> | instance_info          | {}
>                                                      |
> | instance_uuid          | None
>                                                      |
> | last_error             | None
>                                                      |
> | maintenance            | False
>                                                     |
> | maintenance_reason     | None
>                                                      |
> | management_interface   | ipmitool
>                                                      |
> | name                   | baremetal-node
>                                                      |
> | network_interface      | flat
>                                                      |
> | owner                  | None
>                                                      |
> | power_interface        | ipmitool
>                                                      |
> | power_state            | power off
>                                                     |
> |
> *properties             | {'cpus': 20, 'memory_mb': 63700, 'local_gb':
> 470, 'cpu_arch': 'x86_64', 'capabilities':             ||
>      | 'boot_mode:uefi,boot_option:local', 'vendor': 'hewlett-packard'}
>    *                            |
> | protected              | False
>                                                     |
> | protected_reason       | None
>                                                      |
> | provision_state        | available
>                                                     |
> | provision_updated_at   | 2022-02-14T10:15:27+00:00
>                                                     |
> | raid_config            | {}
>                                                      |
> | raid_interface         | no-raid
>                                                     |
> | rescue_interface       | agent
>                                                     |
> | reservation            | None
>                                                      |
> | resource_class         | baremetal-resource-class
>                                                      |
> | storage_interface      | noop
>                                                      |
> | target_power_state     | None
>                                                      |
> | target_provision_state | None
>                                                      |
> | target_raid_config     | {}
>                                                      |
> | traits                 | []
>                                                      |
> | updated_at             | 2022-02-14T10:15:27+00:00
>                                                     |
> | uuid                   | cd021878-40eb-407c-87c5-ce6ef92d29eb
>                                                      |
> | vendor_interface       | ipmitool
>                                                      |
>
> +------------------------+-----------------------------------------------------------------------------------------------------+
> (overcloud) [stack at undercloud v4]$,
>
> On further debugging, we found that in the nova-scheduler logs :
>
>
> *2022-02-14 12:58:22.830 7 WARNING keystoneauth.discover [-] Failed to
> contact the endpoint at http://172.16.2.224:8778/placement
> <http://172.16.2.224:8778/placement> for discovery. Fallback to using that
> endpoint as the base url.2022-02-14 12:58:23.438 7 WARNING
> keystoneauth.discover [req-ad5801e4-efd7-4159-a601-68e72c0d651f - - - - -]
> Failed to contact the endpoint at http://172.16.2.224:8778/placement
> <http://172.16.2.224:8778/placement> for discovery. Fallback to using that
> endpoint as the base url.*
>
> where 172.16.2.224 is the internal IP.
>
> going by document :
> Bare Metal Instances in Overcloud ? TripleO 3.0.0 documentation
> (openstack.org)
> <https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/baremetal_overcloud.html>
>
> it is given as below for commands:
>
> (overcloud) [root at overcloud-controller-0 ~]# endpoint=
> http://172.16.2.224:8778/placement
> (overcloud) [root at overcloud-controller-0 ~]# token=$(openstack token
> issue -f value -c id)
> (overcloud) [root at overcloud-controller-0 ~]# curl -sH "X-Auth-Token:
> $token" $endpoint/resource_providers/<node id> | jq .inventories
> *null*
>
> result is the same even if we run the curl command on public endpoint.
>
> Please advice.
>
>
>
> On Sat, Feb 12, 2022 at 12:45 AM Julia Kreger <juliaashleykreger at gmail.com>
> wrote:
>
>>
>>
>> On Fri, Feb 11, 2022 at 6:32 AM Lokendra Rathour <
>> lokendrarathour at gmail.com> wrote:
>>
>>> Hi Harald/ Openstack Team,
>>> Thank you again for your support.
>>>
>>> we have successfully provisioned the baremetal node as per the inputs
>>> shared by you. The only change that we did was to add an entry for the
>>> ServiceNetmap.
>>>
>>> Further, we were trying to launch the baremetal node instance  in which
>>> we are facing ISSUE as mentioned below:
>>>
>>>
>>> [trim'ed picture because of message size]
>>
>>>
>>> *"2022-02-11 18:13:45.840 7 ERROR nova.compute.manager
>>> [req-aafdea4d-815f-4504-b7d7-4fd95d1e083e - - - - -] Error updating
>>> resources for node 9560bc2d-5f94-4ba0-9711-340cb8ad7d8a.:
>>> nova.exception.NoResourceClass: Resource class not found for Ironic node
>>> 9560bc2d-5f94-4ba0-9711-340cb8ad7d8a.*
>>>
>>> *2022-02-11 18:13:45.840 7 ERROR nova.compute.manager Traceback (most
>>> recent call last):2022-02-11 18:13:45.840 7 ERROR nova.compute.manager
>>> File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 8894,
>>> in _update_available_resource_for_node*
>>> "
>>>
>>
>> So this exception can only be raised if the resource_class field is just
>> not populated for the node. It is a required field for nova/ironic
>> integration. Also, Interestingly enough, this UUID in the error doesn't
>> match the baremetal node below. I don't know if that is intentional?
>>
>>
>>> for your reference please refer following details:
>>> (overcloud) [stack at undercloud v4]$ openstack baremetal node show
>>> baremetal-node --fit-width
>>>
>>> +------------------------+-------------------------------------------------------------------------------------------------------------------+
>>> | Field                  | Value
>>>                                                                     |
>>>
>>> +------------------------+-------------------------------------------------------------------------------------------------------------------+
>>> | allocation_uuid        | None
>>>                                                                      |
>>> | automated_clean        | None
>>>                                                                      |
>>> | bios_interface         | no-bios
>>>                                                                     |
>>> | boot_interface         | ipxe
>>>                                                                      |
>>> | chassis_uuid           | None
>>>                                                                      |
>>> | clean_step             | {}
>>>                                                                      |
>>> | conductor              | overcloud-controller-0.localdomain
>>>                                                                      |
>>> | conductor_group        |
>>>                                                                     |
>>> | console_enabled        | False
>>>                                                                     |
>>> | console_interface      | ipmitool-socat
>>>                                                                      |
>>> | created_at             | 2022-02-11T13:02:40+00:00
>>>                                                                     |
>>> | deploy_interface       | iscsi
>>>                                                                     |
>>> | deploy_step            | {}
>>>                                                                      |
>>> | description            | None
>>>                                                                      |
>>> | driver                 | ipmi
>>>                                                                      |
>>> | driver_info            | {'ipmi_port': 623, 'ipmi_username': 'hsc',
>>> 'ipmi_password': '******', 'ipmi_address': '10.0.1.183',               |
>>> |                        | 'deploy_kernel':
>>> 'bc62f3dc-d091-4dbd-b730-cf7b6cb48625', 'deploy_ramdisk':
>>>                      |
>>> |                        | 'd58bcc08-cb7c-4f21-8158-0a5ed4198108'}
>>>                                                                     |
>>> | driver_internal_info   | {'agent_erase_devices_iterations': 1,
>>> 'agent_erase_devices_zeroize': True, 'agent_continue_if_ata_erase_failed':
>>>  |
>>> |                        | False, 'agent_enable_ata_secure_erase': True,
>>> 'disk_erasure_concurrency': 1, 'last_power_state_change':           |
>>> |                        | '2022-02-11T13:14:29.581361',
>>> 'agent_version': '5.0.5.dev25', 'agent_last_heartbeat':
>>>         |
>>> |                        | '2022-02-11T13:14:24.151928',
>>> 'hardware_manager_version': {'generic_hardware_manager': '1.1'},
>>>          |
>>> |                        | 'agent_cached_clean_steps': {'deploy':
>>> [{'step': 'erase_devices', 'priority': 10, 'interface': 'deploy',          |
>>> |                        | 'reboot_requested': False, 'abortable':
>>> True}, {'step': 'erase_devices_metadata', 'priority': 99, 'interface':    |
>>> |                        | 'deploy', 'reboot_requested': False,
>>> 'abortable': True}], 'raid': [{'step': 'delete_configuration', 'priority':
>>>   |
>>> |                        | 0, 'interface': 'raid', 'reboot_requested':
>>> False, 'abortable': True}, {'step': 'create_configuration',           |
>>> |                        | 'priority': 0, 'interface': 'raid',
>>> 'reboot_requested': False, 'abortable': True}]},
>>>    |
>>> |                        | 'agent_cached_clean_steps_refreshed':
>>> '2022-02-11 13:14:22.580729', 'clean_steps': None}
>>>  |
>>> | extra                  | {}
>>>                                                                      |
>>> | fault                  | None
>>>                                                                      |
>>> | inspect_interface      | inspector
>>>                                                                     |
>>> | inspection_finished_at | None
>>>                                                                      |
>>> | inspection_started_at  | None
>>>                                                                      |
>>> | instance_info          | {}
>>>                                                                      |
>>> | instance_uuid          | None
>>>                                                                      |
>>> | last_error             | None
>>>                                                                      |
>>> | maintenance