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> <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org> Message-ID: 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 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 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 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 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: References: Message-ID: 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 >> 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 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 >>> 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: 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> <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org> Message-ID: 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 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 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 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: 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: <20220130190744.hru7khru534cqhbi@yuggoth.org> Message-ID: On Sun, Jan 30, 2022 at 8:09 PM Jeremy Stanley 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: References: Message-ID: On Mon, Jan 31, 2022 at 3:50 PM Ronelle Landy wrote: > Hello All, > > We have an issue with tripleo-ci-centos-8-content-provider > 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: 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: 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: 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: References: <20220130190744.hru7khru534cqhbi@yuggoth.org> 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: 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: References: <54D2CC84-6134-4B62-801D-3C6CB93CBC79@openstack.org> <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org> 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 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 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 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: 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: 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: 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: References: Message-ID: On Tue, Feb 1 2022 at 11:50:28 AM +0100, 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? 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: References: Message-ID: 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 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: 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: References: Message-ID: 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 > 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: References: Message-ID: On Tue, Feb 1 2022 at 11:07:07 AM -0600, Ben Nemec 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 >>  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: References: Message-ID: 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 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: 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: <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> <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org> Message-ID: 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 > . > > > Thanks! > > -James > > > >> On Jan 28, 2022, at 12:20 PM, James Cole 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 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> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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> <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com> <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org> <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 wrote ---- > ---- On Wed, 01 Dec 2021 16:43:32 -0600 Jean-Philippe Evrard 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: 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: 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: 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: References: Message-ID: On Tue, Feb 1, 2022 at 7:00 AM Ronelle Landy wrote: > > > On Mon, Jan 31, 2022 at 3:50 PM Ronelle Landy wrote: > >> Hello All, >> >> We have an issue with tripleo-ci-centos-8-content-provider >> 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: 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: References: Message-ID: 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 > > 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 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: References: 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: 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: <2919487.mvXUDI8C0e@p1> Message-ID: 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 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: 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: References: 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 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 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: 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: <20220130190744.hru7khru534cqhbi@yuggoth.org> <20220201141354.er742obifv4pzvp3@yuggoth.org> Message-ID: On Tue, Feb 1, 2022 at 3:16 PM Jeremy Stanley 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: 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: 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: References: <0670B960225633449A24709C291A525251E75023@COM03.performair.local> 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 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: <243F84E8-F0D7-4FFC-9BC5-1DC05BCF704D@gmail.com> Message-ID: 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 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 > 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 > 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: 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: <0670B960225633449A24709C291A525251E75023@COM03.performair.local> <0670B960225633449A24709C291A525251E757F3@COM03.performair.local> Message-ID: 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 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 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: 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: References: 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: 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: <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 Sent: mercredi, 2 f?vrier 2022 18:08 To: openstack-discuss Cc: Michael STFC 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: 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: <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: <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 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: <9E76A521-0833-4121-A13D-7671D764701C@gmail.com> <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com> <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr> Message-ID: 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 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: <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: 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: References: <9E76A521-0833-4121-A13D-7671D764701C@gmail.com> <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com> <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr> 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: 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> <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com> <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org> <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com> <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com> <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com> Message-ID: 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: <9E76A521-0833-4121-A13D-7671D764701C@gmail.com> <14b8805e40d95f37f04b2acf7da86cc22738fe3c.camel@redhat.com> <0AD7A0DA-2C53-4DCF-9FEA-98B29C4840F1@cnrs.fr> <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: 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: 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: References: 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: 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: References: Message-ID: 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 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: <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: 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: References: 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: 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: 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: References: Message-ID: <20220203101221.yygkfeo5prrx63oh@localhost> On 01/02, Balazs Gibizer wrote: > > > On Tue, Feb 1 2022 at 11:07:07 AM -0600, Ben Nemec > 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 > > >  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: References: Message-ID: 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 [-] "GET / HTTP/1.1" status: 200 len: 115 time: 0.0016830 2022-02-03 11:09:46.108 11383 INFO eventlet.wsgi.server [-] "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 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: 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: <20220203095319.7pezolzhq3glfpky@localhost> Message-ID: On Thu, 3 Feb 2022 at 10:53, Gorka Eguileor 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: <20220203101221.yygkfeo5prrx63oh@localhost> Message-ID: Thank you also for all these clarifications. Cheers, -yoctozepto On Thu, 3 Feb 2022 at 11:12, Gorka Eguileor wrote: > > On 01/02, Balazs Gibizer wrote: > > > > > > On Tue, Feb 1 2022 at 11:07:07 AM -0600, Ben Nemec > > 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 > > > > 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: <20220202220941.2i4eu7aouqc4lvji@yuggoth.org> Message-ID: 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: References: Message-ID: On Tue, Feb 1, 2022 at 11:38 AM Lajos Katona 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 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: 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: References: 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: 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: 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: 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: 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: 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: 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: 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: 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: References: Message-ID: The fix hasn?t landed yet since then. On Fri, Feb 4, 2022 at 8:38 AM Adivya Singh 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 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 >> 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: 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: 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: 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: 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: References: Message-ID: 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 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: 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: References: Message-ID: 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 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 > 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 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: 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: 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 ', 'ramdisk': 'http://myip:8080/RHEL7/initrd.img ', 'image_source': 'http://myip:8080/RHEL7/initrd.img ', 'stage2': 'http://myip:8080/RHEL7/squashfs.img ', 'ks_cfg': 'http://myip:8080/RHEL7/ks.cfg.template ', 'ks_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: 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: References: Message-ID: 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, 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 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 >> 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 >>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: 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: References: Message-ID: On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta 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, > 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 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 >>> 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 >>>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: 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: References: Message-ID: 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, wrote: > > > On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta 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, >> 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 >>> 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 >>>>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: 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: 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: - 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: 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: 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: References: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr> 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 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 > 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: 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> <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr> Message-ID: - 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 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: 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: References: <8A270086-6A3F-4FAA-B9E9-9895A191F631@univ-grenoble-alpes.fr> <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr> 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 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 > 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 > 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 > 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: 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: References: Message-ID: On Mon, Jan 24, 2022 at 2:59 AM Takashi Kajinami 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: 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> <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr> <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 : > 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 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 >> > > 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 >> > 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 >>> >> > 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: 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 failed to associate with server 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: 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: References: Message-ID: 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 wrote: > > The fix hasn?t landed yet since then. > > On Fri, Feb 4, 2022 at 8:38 AM Adivya Singh 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 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 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: 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: 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: 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: 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: 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: References: Message-ID: 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: 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: References: Message-ID: 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 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 > ', 'ramdisk': > 'http://myip:8080/RHEL7/initrd.img ', > 'image_source': 'http://myip:8080/RHEL7/initrd.img > ', 'stage2': > 'http://myip:8080/RHEL7/squashfs.img > ', 'ks_cfg': > 'http://myip:8080/RHEL7/ks.cfg.template > ', 'ks_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: 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: References: Message-ID: 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 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: 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: References: Message-ID: <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com> ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto 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 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 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: References: Message-ID: 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 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: <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com> Message-ID: <17ed53b5743.dee52ed373697.6491334868007810351@ghanshyammann.com> ---- On Mon, 07 Feb 2022 11:10:37 -0600 Ghanshyam Mann wrote ---- > ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto 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 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 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: <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 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 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 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> <9127BDED-5CC8-45BA-B82C-DACC0E7C9703@univ-grenoble-alpes.fr> <2143074A-B762-4455-ADD4-86A001919D8D@univ-grenoble-alpes.fr> <20220207095528.Horde.TLJ23YmLfAbOaPxt2gc-22M@webmail.nde.ag> Message-ID: 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 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 : > >> 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 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 > 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 > 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 > 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: 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: <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com> <4a85184cc9a5044a81df2d1f4c41793380cc1cfd.camel@redhat.com> Message-ID: 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 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 > 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: 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: References: <17ed52a79eb.f46d017b72529.3416669804897783292@ghanshyammann.com> <4a85184cc9a5044a81df2d1f4c41793380cc1cfd.camel@redhat.com> Message-ID: <17ed5840b1d.d942645878061.3862190353728356128@ghanshyammann.com> ---- On Mon, 07 Feb 2022 12:08:36 -0600 Massimo Sgaravatto 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 wrote: > On Mon, 2022-02-07 at 11:10 -0600, Ghanshyam Mann wrote: > > ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto 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 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 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: References: Message-ID: On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard 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' = . Eg: "openstack baremetal node set --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 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 >> 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 >>> ', 'ramdisk': >>> 'http://myip:8080/RHEL7/initrd.img ', >>> 'image_source': 'http://myip:8080/RHEL7/initrd.img >>> ', 'stage2': >>> 'http://myip:8080/RHEL7/squashfs.img >>> ', 'ks_cfg': >>> 'http://myip:8080/RHEL7/ks.cfg.template >>> ', 'ks_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: 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: References: Message-ID: On Mon, Feb 7, 2022 at 12:21 PM Ruby Loo wrote: > > > > On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard 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' = . Eg: "openstack baremetal node set --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 Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: 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 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, > wrote: > >> >> >> On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta 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, >>> 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 >>>> 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 >>>>>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 215792 bytes Desc: not available URL: 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: References: Message-ID: On Mon, Feb 7, 2022 at 4:47 AM 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: 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 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, >> wrote: >> >>> >>> >>> On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta >>> 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, >>>> 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 >>>>> 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 >>>>>>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 47711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 215792 bytes Desc: not available URL: 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: References: Message-ID: 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 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 > 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 >> ', 'ramdisk': >> 'http://myip:8080/RHEL7/initrd.img ', >> 'image_source': 'http://myip:8080/RHEL7/initrd.img >> ', 'stage2': >> 'http://myip:8080/RHEL7/squashfs.img >> ', 'ks_cfg': >> 'http://myip:8080/RHEL7/ks.cfg.template >> ', 'ks_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: 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: 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: 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: 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: 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: 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: References: Message-ID: 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: 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: References: Message-ID: On Tue, 8 Feb 2022 at 09:15, Dmitry Tantsur wrote: > > Hi! > > On Mon, Feb 7, 2022 at 4:50 PM Rados?aw Piliszek 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: References: Message-ID: On Mon, 7 Feb 2022 at 15:11, Satish Patel 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: References: Message-ID: 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 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: 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: References: Message-ID: On Tue, 8 Feb 2022 at 11:26, Dmitry Tantsur wrote: > > > > On Tue, Feb 8, 2022 at 9:29 AM Rados?aw Piliszek wrote: >> >> On Tue, 8 Feb 2022 at 09:15, Dmitry Tantsur wrote: >> > >> > Hi! >> > >> > On Mon, Feb 7, 2022 at 4:50 PM Rados?aw Piliszek 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: 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 [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: 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: References: Message-ID: Thanks Brian for all your work and efforts to make cinder better! On Tue, Feb 8, 2022 at 5:36 AM 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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: References: Message-ID: 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 ` 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 > > > 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 > 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 > > > > Looking forward for your valuable feedback/response. > > Regards > Anirudh Gupta > > > On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta > 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, > > > wrote: > > > > On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta > > 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, > > 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 > > 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 > > 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 > > 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.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: 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: 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: References: 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: <7d8471ee-f608-950e-4bf7-4b3606238fb2@gmail.com> Message-ID: Thanks Brian for your service to the community. On Tue, Feb 8, 2022 at 7:52 AM Jay Bryant 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: 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: References: 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: 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: 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: References: Message-ID: 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 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: 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// (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: References: 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 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: References: 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 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: References: 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 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: References: Message-ID: 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 > 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: 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: References: Message-ID: 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 wrote: > > On Mon, 7 Feb 2022 at 15:11, Satish Patel 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: References: Message-ID: 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 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: 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 [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: -------------- 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: -------------- 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: -------------- 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: 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: References: Message-ID: 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 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: 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: 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: 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: References: Message-ID: On Mon, Feb 7, 2022 at 3:30 PM Julia Kreger wrote: > On Mon, Feb 7, 2022 at 12:21 PM Ruby Loo wrote: > > > > > > > > On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard > 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' = . Eg: "openstack baremetal node set > --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. > > 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: 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: References: Message-ID: On Tue, Feb 8, 2022 at 4:52 PM Gregory Thiemonge 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 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: 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: 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 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 > [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: 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: References: Message-ID: Hi, On Mon, Feb 7, 2022 at 7:17 PM Lajos Katona 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 > failed to associate with server 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: 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 : > 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 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 : >> >>> 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 >>>> 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 >>>> >>> > 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 >>>>> > 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 >>>>> >>>> > 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: References: Message-ID: 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 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 wrote: > > > > On Mon, 7 Feb 2022 at 15:11, Satish Patel 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: 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: 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: References: Message-ID: 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 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 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 wrote: >>> >>> On Mon, 7 Feb 2022 at 15:11, Satish Patel 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: 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 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 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> <4a74f5c6-5da3-d756-1bd2-5b7fa67ce11a@pawsey.org.au> <89b0b5ba-1449-1533-a9dc-d5aa7aa3d283@pawsey.org.au> Message-ID: On Mon, 17 Jan 2022 at 02:19, Gregory Orange wrote: > On 13/1/22 5:06 pm, Mark Goddard wrote: > > On Thu, 13 Jan 2022 at 05:19, Gregory Orange > > 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/. > > > > 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: 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: 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: 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: 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: 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: References: Message-ID: 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 ` 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 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 ` > > 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 > > 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, > > > > > wrote: > > > > > > > > On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta > > > 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, > > > > 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 > > > > 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 > > > > 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 > > > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 138084 bytes Desc: not available URL: 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: References: <1d26f9142927f518c3de872e764803db2b9e3a7c.camel@quadrivium.com> Message-ID: 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 [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 To: Joshua Crawford 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 > [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: -------------- 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: -------------- 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: -------------- 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: 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: 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: 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: References: <1d26f9142927f518c3de872e764803db2b9e3a7c.camel@quadrivium.com> Message-ID: 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 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 > [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 > To: Joshua Crawford > 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 > > [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: 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: References: <40f6f51b-6903-1afe-7318-0689b2af482d@openstack.org> <8301ef05-4011-43e9-beec-66f6aeeb00f9@www.fastmail.com> <20211129130957.3poysdeqsufkp3pg@yuggoth.org> <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com> <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org> <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com> <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com> <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com> Message-ID: <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com> ---- On Wed, 02 Feb 2022 13:17:19 -0600 Jean-Philippe Evrard 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: References: 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 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: References: Message-ID: 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 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: References: <54D2CC84-6134-4B62-801D-3C6CB93CBC79@openstack.org> <04C42DAB-48E0-4D52-91C3-7FC30532C863@openstack.org> 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/ 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 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 . >> >> Thanks! >> >> -James >> >> >> >> >>> On Jan 28, 2022, at 12:20 PM, James Cole > 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 > 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> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: 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 > ? ? ? ? ? ? ? ? ? ? ? | > | 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.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 ` > 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 > 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 ` > > 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 > > > > > > > > > > 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 > > > > ?> > > 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 > > > > ?> > > > > > > Looking forward for your valuable feedback/response. > > > > Regards > > Anirudh Gupta > > > > > > On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta > > >> 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, > >? ? ? > >> > >? ? ?wrote: > > > > > > > >? ? ? ? ?On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta > >? ? ? ? ? > >> 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, > >? ? ? ? ? ? ? > >? ? ? ? ? ? ? >> 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 > >? ? ? ? ? ? ? ? ? > >> 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 > >? ? ? ? ? ? ? ? ? ? ? > >? ? ? ? ? ? ? ? ? ? ? >> 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 > >? ? ? ? ? ? ? ? ? ? ? ? ? > >? ? ? ? ? ? ? ? ? ? ? ? ? >> 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.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: References: 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: 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 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: 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: References: <67a46fab-a685-d591-1122-05296d2ecd79@cirrax.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 > 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: References: Message-ID: 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: 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: 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: 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: References: Message-ID: <17ee122855b.ca10488e79864.8737427503451386666@ghanshyammann.com> ---- On Wed, 09 Feb 2022 17:46:31 -0600 Martin Kopec 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: 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 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: 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: 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: <17ee122855b.ca10488e79864.8737427503451386666@ghanshyammann.com> Message-ID: +1 On Thu, Feb 10, 2022, 01:58 Ghanshyam Mann wrote: > ---- On Wed, 09 Feb 2022 17:46:31 -0600 Martin Kopec > 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: 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: References: Message-ID: 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: References: Message-ID: 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 ?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: References: 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: References: 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 ?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: References: 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: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: +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: 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: References: Message-ID: No objection from Glance as well. Thanks & Best Regards, Abhishek Kekane On Thu, Feb 10, 2022 at 9:21 AM 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: 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.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: References: Message-ID: On Thu, Feb 10, 2022 at 9:37 AM 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 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: <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch> Message-ID: 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 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 ?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: References: Message-ID: +1 On Thu, Feb 10, 2022 at 4:12 PM John Fulton wrote: > On Thu, Feb 10, 2022 at 9:37 AM 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 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: 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: References: Message-ID: +1 as well DVD On Thu, Feb 10, 2022 at 10:09 AM John Fulton wrote: > On Thu, Feb 10, 2022 at 9:37 AM 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 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: 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: References: Message-ID: +1 On Thu, Feb 10, 2022 at 4:44 PM 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 > 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 > > -- Best regards Sagi Shnaidman -------------- next part -------------- An HTML attachment was scrubbed... URL: 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> <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com> <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org> <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com> <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com> <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.com> <17edf7ffb3f.e748817b67580.8197309833989629340@ghanshyammann.com> Message-ID: <17ee46051c6.12bb64653143256.163506775198229925@ghanshyammann.com> ---- On Wed, 09 Feb 2022 11:20:13 -0600 Ghanshyam Mann wrote ---- > ---- On Wed, 02 Feb 2022 13:17:19 -0600 Jean-Philippe Evrard 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: References: 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 > > 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 > 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 > > > > > -- > 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: 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: 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: References: Message-ID: 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: ????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: 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: 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: References: Message-ID: 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 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 > > | > > | 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.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 ` > > 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 > > 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 ` > > > > 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 > > > > >> 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, > > > > > > > >> > > > wrote: > > > > > > > > > > > > On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta > > > > > >> 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, > > > > > > > > >> 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 > > > > > >> 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 > > > > > > > > >> 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 > > > > > > > > >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 265303 bytes Desc: not available URL: 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: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com> Message-ID: Hi Harald, Thanks for the response, please find my response inline: On Thu, Feb 10, 2022 at 8:24 PM Harald Jensas 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.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: -------------- next part -------------- A non-text attachment was scrubbed... Name: overcloud_baremetal.zip Type: application/x-zip-compressed Size: 128512 bytes Desc: not available URL: 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: 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: 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: <76d16ee9-8dfc-246f-134f-162b20652c1f@redhat.com> Message-ID: +1 On Thu, Feb 10, 2022 at 11:11 AM Bogdan Dobrelya 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 > > > 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 > > 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 > > < > 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: 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: References: Message-ID: +1 On Thu, Feb 10, 2022, 20:07 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 > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: +1 On Thu, Feb 10, 2022 at 4:40 PM 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 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: Message-ID: <20220211103532.Horde.-qNZf0SqwPEuQdODYH3QSFn@webmail.nde.ag> What do the rabbit logs reveal? Zitat von Satish Patel : > 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: References: Message-ID: +1 On Thu, Feb 10, 2022 at 3:43 PM 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 > 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 > > -- Francesco Pantano GPG KEY: F41BD75C -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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: 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: 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 wrote: > > ?What do the rabbit logs reveal? > > > Zitat von Satish Patel : > >> 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: 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: References: <20220211103532.Horde.-qNZf0SqwPEuQdODYH3QSFn@webmail.nde.ag> 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 : > 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 wrote: >> >> ?What do the rabbit logs reveal? >> >> >> Zitat von Satish Patel : >> >>> 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: References: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com> Message-ID: 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 wrote: > Hi Harald, > Thanks for the response, please find my response inline: > > > On Thu, Feb 10, 2022 at 8:24 PM Harald Jensas 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.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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 173439 bytes Desc: not available URL: 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: 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: 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: 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: 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: 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: References: Message-ID: On Fri, Feb 11, 2022 at 11:06 AM Fernando Ferraz 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: 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 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: 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: References: Message-ID: 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 > 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: 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: References: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com> Message-ID: On Fri, Feb 11, 2022 at 6:32 AM Lokendra Rathour 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 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.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: 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: 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: References: 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 > 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 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: 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 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: 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: References: Message-ID: 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 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 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: 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 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 : > >> 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 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 : >>> >>>> 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 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 > 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 > 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 > 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: 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 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 : > >> 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 wrote: >>> >>> ?What do the rabbit logs reveal? >>> >>> >>> Zitat von Satish Patel : >>> >>>> 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: <8b8ea100-7119-eb46-0156-0e069fe3a131@redhat.com> Message-ID: +1 On Sat, 12 Feb, 2022, 7:37 AM Harald Jensas, 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 > > 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 > > < > 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: 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: 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: 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: 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: References: <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch> Message-ID: 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 : 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 ?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 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 ?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: 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: 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: References: Message-ID: 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 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: 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: References: 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" ??? 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 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: 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: <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" ??? 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" ??? 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 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: 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: <107e6cd3.1227.17ef718cf82.Coremail.ly2008080808@yeah.net> <3dbed8c4.1241.17ef71ae627.Coremail.ly2008080808@yeah.net> Message-ID: 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 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" ??? > > 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" ??? > > 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 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: 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> <17d72ae5ee2.b80bfd38119150.5945079300853303270@ghanshyammann.com> <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org> <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com> <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com> <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.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: References: <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch> Message-ID: 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 > 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 ?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 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 ?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: 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: 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: 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: 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: References: Message-ID: 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: 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: References: Message-ID: 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: References: Message-ID: 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/ 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/ 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 : > 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 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 : >> >>> 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 wrote: >>>> >>>> ?What do the rabbit logs reveal? >>>> >>>> >>>> Zitat von Satish Patel : >>>> >>>>> 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 : > 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 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 : >> >>> 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 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 : >>>> >>>>> 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 >>>>>> 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 >>>>>> >>>>> > 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 >>>>>>> > 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 >>>>>>> >>>>>> > 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: 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: 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: References: Message-ID: 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 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: <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org> <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com> <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com> <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.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: 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: References: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com> Message-ID: 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 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 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) 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/ | 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 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 >>> 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.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: 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: 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: Hello all, There has been a change in coordination responsibilities for Outreachy OpenStack . 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: 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: 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 or Dmitry Tantsur Best, Mahati -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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: 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: References: 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: References: Message-ID: 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 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: 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 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: 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: References: Message-ID: +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 > 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 > -- 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: man. 14. feb. 2022, 19:36 skrev Ghanshyam Mann : > ---- 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: 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: <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org> <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com> <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com> <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.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: <20211130220913.ydk5zhyvkdl7g7zc@yuggoth.org> <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com> <17ea383e2ff.bb8539c4105974.6110586469358586536@ghanshyammann.com> <17eb75aa262.b06fe4d3326925.5958522478246421517@ghanshyammann.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 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: References: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com> <450c1cc5-1154-97b4-21d3-cec769b8c869@redhat.com> <17ef97e6b7e.fa87b530351073.1185492487506837204@ghanshyammann.com> Message-ID: <17efa5b6424.1213b1869357645.2623342301875640039@ghanshyammann.com> ---- On Mon, 14 Feb 2022 13:58:19 -0600 Frode Nordahl wrote ---- > > > man. 14. feb. 2022, 19:36 skrev Ghanshyam Mann : > ---- On Mon, 14 Feb 2022 11:53:04 -0600 Giulio Fidente 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: References: Message-ID: 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: 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: 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: 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: 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: 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: 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: 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 ???? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3519 bytes Desc: image002.jpg URL: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3606 bytes Desc: not available URL: 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: References: Message-ID: +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 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: 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: <4e20b1f1-030a-519a-aa8b-774d2d4f319d@nemebean.com> Message-ID: 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 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: 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: 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: 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: References: 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: References: Message-ID: 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 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: References: <46615849.557895.1644509565653.ref@mail.yahoo.com> <46615849.557895.1644509565653@mail.yahoo.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 > > 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: 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: 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: 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: References: Message-ID: 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: 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: 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: <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> <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 wrote ---- > > > > > > man. 14. feb. 2022, 19:36 skrev Ghanshyam Mann : > > ---- On Mon, 14 Feb 2022 11:53:04 -0600 Giulio Fidente 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: References: Message-ID: 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 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: 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: <4e20b1f1-030a-519a-aa8b-774d2d4f319d@nemebean.com> <97d0f2521e8fd991b5a1ff90a6eb66b4f60dd603.camel@redhat.com> Message-ID: 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 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: 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: 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 [1] https://openinfra-ptg.eventbrite.com/ Thanks & Best Regards, Abhishek Kekane -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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: 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: 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: References: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com> Message-ID: >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 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 > 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 > 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) > > > 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/ | 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 > 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 >>>> 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.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: From allison at openinfra.dev Tue Feb 15 15:31:19 2022 From: allison at openinfra.dev (Allison Price) Date: Tue, 15 Feb 2022 09:31:19 -0600 Subject: OpenInfra Live - February 17 at 1500 UTC Message-ID: <259DE0C9-4B1B-4F71-8FD8-896D571B7446@openinfra.dev> Hi everyone, This week?s OpenInfra Live episode is brought to you by the OpenInfra Foundation. Organizations like AT&T, CERN, China Mobile, China Telecom, Verizon, Vodafone, and Yahoo have adopted the OpenInfra Standard and run it in production today. Similar to how LAMP stack became the standard for deploying web applications, LOKI helps operators identify successful patterns and combinations of technologies to build production infrastructure. This OpenInfra Live episode will discuss this emerging standard and why organizations have adopted these open source technologies together. Episode: Linux OpenStack Kubernetes Infrastructure: The OpenInfra Standard Date and time: Thursday, February 17 at 9am CT (1500 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=pnYB7eYYiPg LinkedIn: https://www.linkedin.com/video/event/urn:li:ugcPost:6899060799814418432/ Facebook: https://www.facebook.com/104139126308032/posts/4852599164795314/ WeChat: recording will be posted on OpenStack WeChat after the live stream Participants: Host: Mark Collier, COO at the OpenInfra Foundation Maria Bracho, Manager Product Management at Red Hat Philip Williams, Product Leader at Canonical Have an idea for a future episode? Share it now at ideas.openinfra.live . Thanks, Allison -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Feb 15 15:48:31 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 15 Feb 2022 16:48:31 +0100 Subject: [election][tc] TC candidacy for Z release Message-ID: <1807684.tdWV9SEqCh@p1> Hi, I want to propose my candidacy for the Technical Committee. I have been an OpenStack contributor since around 2015. For most of that time I have contributed to the Neutron project where I am core reviewer and member of the Neutron drivers team, which is the subset of the Neutron core team for steering the Neutron project. I also served as the Neutron PTL for 4 cycles. Currently I work for Red Hat as software engineer and OpenStack Neutron developer and I would like to bring that developer?s perspective to the TC. Before I joined Red Hat, I worked in the OVH which is a Public Cloud provider. That gave me experience as an OpenStack operator as well. I have experience with the Neutron CI and I would like to expand it wider, for OpenStack as a whole. In the past I cooperated with TC members to reduce CI resources usage by the Neutron project and we made great improvements there. I understand that this new role will require a lot of learning and I will be very happy to have that opportunity. I?m willing to learn and contribute to the TC as much as possible. -- 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: From franck.vedel at univ-grenoble-alpes.fr Tue Feb 15 16:10:34 2022 From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL) Date: Tue, 15 Feb 2022 17:10:34 +0100 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers Message-ID: Hello, I seem to have a problem that I hadn't seen. I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? Thanks in advance if you can help me. Franck VEDEL -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im1.png Type: image/png Size: 100474 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture d?e?cran 2022-02-15 a? 16.55.13.png Type: image/png Size: 92774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im3.png Type: image/png Size: 124170 bytes Desc: not available URL: From jasonanderson at uchicago.edu Tue Feb 15 16:31:50 2022 From: jasonanderson at uchicago.edu (Jason Anderson) Date: Tue, 15 Feb 2022 16:31:50 +0000 Subject: [keystone] anyone using OpenID with Keystone? In-Reply-To: References: Message-ID: > On Feb 15, 2022, at 4:59 AM, Jonathan Rosser wrote: > > We have patched a keystoneauth plugin to support PKCE which does not require a client secret. It is not strictly required to use PKCE if you want public access grants, it depends on your threat model. As I understand, PKCE adds additional security on top of the implicit authentication flow. If your IdP supports public access method and it is enabled, you can set OS_CLIENT_SECRET to any value, e.g., ?none?. I think it has to be non-empty though for the keystoneauth library to accept it. > It requires your identity provider to support PKCE, keycloak in our case. > > https://github.com/bbc/keystoneauth-oidc Very cool! > 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... For CLI, one thing you can also do is support the v3oidcpassword grant type. This relies on a password the user sets in the IdP, similar in some ways to an ?application password? sometimes used for e.g., setting up mail clients. In Horizon you can override the default OpenRC template so that it is preconfigured to authenticate using OIDC: https://docs.openstack.org/horizon/latest/configuration/settings.html#openrc-custom-template >> - 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). You?re right, I?m not sure this is possible. You can assign user project memberships but not group project memberships as far as I can tell. Some other notes on our journey around this, we had additional patches to get things working w/ our model, maybe it can help guide you: https://diurnal.st/2021/07/17/openstack-keystone-federation-part-1.html >> >> >> I am wondering if anyone is willing to share their experience dealing >> with Keystone and OpenID. >> >> Thanks! >> Francois (frigo) >> >> > From mdemaced at redhat.com Tue Feb 15 16:50:31 2022 From: mdemaced at redhat.com (Maysa De Macedo Souza) Date: Tue, 15 Feb 2022 17:50:31 +0100 Subject: [election][Kuryr] PTL candidacy for the Z cycle Message-ID: Hello OpenStack community, I would like to announce my candidacy for the Z cycle. I have been serving as Kuryr PTL since the Wallaby and I would like to continue doing that. In the Yoga cycle we have achieved the following: * Extended features and improvements: addition of events to Kubernetes resources, reduction on the workload Kuryr puts on Neutron, limiting the number of Neutron Ports creation happening in parallel, continuation on the load-balancer resources reconciliation with k8s Services, and many more. * CI improvements: Made Devstack installations to use CRI-O and improved some tempest tests. For the next cycle, I propose the following goals to Kuryr: * Continue improvements for Kuryr scalability with Neutron, OpenStack resources reconciliation with Kubernetes and Kuryr controller health checks. Thanks for your consideration. Best regards, Maysa Macedo. IRC: maysams -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Feb 15 16:55:10 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 15 Feb 2022 10:55:10 -0600 Subject: [all][tc] OpenStack next release name is final- "OpenStack Zed" In-Reply-To: <9f99d0403d671de7dcab8e1f58d6fb82fcff1af9.camel@redhat.com> References: <17ef9309add.ce4b1a4d345648.5514314003312030284@ghanshyammann.com> <450c1cc5-1154-97b4-21d3-cec769b8c869@redhat.com> <17ef97e6b7e.fa87b530351073.1185492487506837204@ghanshyammann.com> <17efa5b6424.1213b1869357645.2623342301875640039@ghanshyammann.com> <9f99d0403d671de7dcab8e1f58d6fb82fcff1af9.camel@redhat.com> Message-ID: <17efe4f3340.e67163c0428434.8973525985664802123@ghanshyammann.com> ---- On Tue, 15 Feb 2022 06:45:05 -0600 Sean Mooney wrote ---- > On Mon, 2022-02-14 at 16:30 -0600, Ghanshyam Mann wrote: > > ---- On Mon, 14 Feb 2022 13:58:19 -0600 Frode Nordahl wrote ---- > > > > > > > > > man. 14. feb. 2022, 19:36 skrev Ghanshyam Mann : > > > ---- On Mon, 14 Feb 2022 11:53:04 -0600 Giulio Fidente 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. Thanks for raising concern. IMO, we had gone through the complete process including an extra checks of cultural/historic objection on Z names before election start and that is maximum we can do. I do not think we will find any name without any objection :), nothing is perfect. With trademark check cost, time constraints etc we need to go with the 'Zed' as final name for Z. And for future improvement, definitely TC has action item to discuss on different naming approach for after Z release. Let's wait for the proposal and there we can discuss about best possible approach for future naming. -gmann > > > > -gmann > > > > > --Frode Nordahl > > > -gmann > > > > > > > > > > > thanks > > > > -- > > > > Giulio Fidente > > > > GPG KEY: 08D733BA > > > > > > > > > > > > > > > > > > > > > > > From jonathan.rosser at rd.bbc.co.uk Tue Feb 15 16:57:04 2022 From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser) Date: Tue, 15 Feb 2022 16:57:04 +0000 Subject: [keystone] anyone using OpenID with Keystone? In-Reply-To: References: Message-ID: <3d3f1fd2-ec35-ae67-5a12-66fc5225f69a@rd.bbc.co.uk> In our case implicit flow was not available so we had to use auth code flow - PKCE was the place to go from there for CLI. I would like to see some of this functionality integrated into the existing CLI tools, requiring an external auth plugin is currently not great user experience. Jonathan. On 15/02/2022 16:31, Jason Anderson wrote: >> On Feb 15, 2022, at 4:59 AM, Jonathan Rosser wrote: >> >> We have patched a keystoneauth plugin to support PKCE which does not require a client secret. > It is not strictly required to use PKCE if you want public access grants, it depends on your threat model. As I understand, PKCE adds additional security on top of the implicit authentication flow. > > If your IdP supports public access method and it is enabled, you can set OS_CLIENT_SECRET to any value, e.g., ?none?. I think it has to be non-empty though for the keystoneauth library to accept it. > >> It requires your identity provider to support PKCE, keycloak in our case. >> >> https://github.com/bbc/keystoneauth-oidc > Very cool! > >> 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... > For CLI, one thing you can also do is support the v3oidcpassword grant type. This relies on a password the user sets in the IdP, similar in some ways to an ?application password? sometimes used for e.g., setting up mail clients. > > In Horizon you can override the default OpenRC template so that it is preconfigured to authenticate using OIDC: > https://docs.openstack.org/horizon/latest/configuration/settings.html#openrc-custom-template > >>> - 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). > You?re right, I?m not sure this is possible. You can assign user project memberships but not group project memberships as far as I can tell. > > Some other notes on our journey around this, we had additional patches to get things working w/ our model, maybe it can help guide you: https://diurnal.st/2021/07/17/openstack-keystone-federation-part-1.html > >>> >>> I am wondering if anyone is willing to share their experience dealing >>> with Keystone and OpenID. >>> >>> Thanks! >>> Francois (frigo) >>> >>> From sbauza at redhat.com Tue Feb 15 17:01:46 2022 From: sbauza at redhat.com (Sylvain Bauza) Date: Tue, 15 Feb 2022 18:01:46 +0100 Subject: [nova][placement] Implementation review day on Thursday Fev 17 Message-ID: Hey folks, Last minute item, but we agreed during today's meeting to run a feature review day on Thursday February the 17th. If you're one of the owners of the blueprints that are marked in [1], you're eligible to ensure that this etherpad is up to date based on your last efforts and that you're somehow around either on IRC or asynchronously through Gerrit on that day to answer comments and questions about your patches. Cores, I'd appreciate if you can dedicate this Thursday to feature reviews as we still have a large set of blueprints that aren't merged yet. Thanks, -Sylvain [1] https://etherpad.opendev.org/p/nova-yoga-blueprint-status -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Feb 15 19:07:36 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 15 Feb 2022 13:07:36 -0600 Subject: [all][elections][ptl][tc] Combined PTL/TC Zed cycle Election Nominations Last Days In-Reply-To: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com> References: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com> Message-ID: <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> Hello Everyone, Less than 5 hours left for nomination end and we still need nominations for 21 projects (Zun and Masakari nomination are there but not passed the validation): - Adjutant Freezer Heat Magnum Masakari Monasca Murano OpenStack_Charms Openstack_Chef Release_Management Requirements Senlin Skyline Solum Swift Tripleo Trove Venus Watcher Zaqar Zun If you are maintainer of above projects, please do not delay the nomination or motivate the one you think should add nomination. -gmann & The OpenStack Technical Election Officials ---- On Mon, 14 Feb 2022 18:20:38 -0600 Ghanshyam Mann wrote ---- > 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 elod.illes at est.tech Tue Feb 15 20:12:43 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Tue, 15 Feb 2022 21:12:43 +0100 Subject: [election][Release_Management] PTL candidacy for Z cycle Message-ID: Hello OpenStack Community, I would like to announce my candidacy for the PTL role of the Release Management team for the Z cycle. I am core member in the Release Management team since Wallaby, but I followed the team's work even before that, and I also have been the PTL of the team for Yoga cycle for some months now. (Though, from release management perspective this is not a long period, since the most laborous part will only start in the coming weeks ;)) Furthermore, as in the past, beside release management duties, my focus is still on stable maintenance as well, since I am stable-maint-core member, too. The next cycle's challenges will be to prepare our tooling to alphabet roll-over after the Z cycle and to adjust to any other changes in our processes. And of course, parallel to this, to release OpenStack Z :) Thanks for your consideration, El?d Ill?s (elodilles) From tburke at nvidia.com Tue Feb 15 20:13:19 2022 From: tburke at nvidia.com (Timothy Burke) Date: Tue, 15 Feb 2022 20:13:19 +0000 Subject: [election][swift] PTL candidacy for Zed Message-ID: I intend to continue serving as Swift PTL for the Zed cycle. We have seen Swift scale in spectacular ways. Hard drives have grown from 2-4 terabytes when Swift was started to 10-20T. The idea of a "large cluster" has gone from dozens of petabytes across hundreds of nodes to hundreds of petabytes across thousands of nodes. We will continue to see (and address) new challenges in scaling Swift. We anticipate hitting the bounds of our current ring format. We see operators struggle to balance the prioritization of cluster expansion and data durability. We see the need to improve sharding, so that clients are less impacted by what's going on in the backend. All of these have seen progress in the last cycle, and will continue to be advanced in the next. Just as important as scaling the core storage platform, however, is building up the ecosystem of ancillary services that users have come to expect out of their object storage. When a container grows to have billions of objects, it is impractical to perform thousands of listing requests to analyze its contents; instead, users expect a periodic inventory that's easy to pull into their existing data pipelines. Users should be able to examine their own access logs rather than needing to involve operators. Users want to manage their data movement and retention en masse rather than object-by-object. I look forward to seeing the balance we strike between enhancing the core storage platform and building out the data services surrounding it over the coming years. Tim Burke -------------- next part -------------- An HTML attachment was scrubbed... URL: From mthode at mthode.org Tue Feb 15 20:41:53 2022 From: mthode at mthode.org (Matthew Thode) Date: Tue, 15 Feb 2022 14:41:53 -0600 Subject: [election][Requirements] PTL candidacy for Zed Message-ID: <20220215204153.j277dlo2adwxmdiz@mthode.org> I would like to announce my candidacy for PTL of the Requirements project for the Zed cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like prettytable). 3. Fix some automation of generate contstraints (pkg-resources being added and setuptools being dropped) 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. 5. introduce better python version range support into constraints. I look forward to continue working with you in this cycle, as your PTL or not. Thanks for your time, -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laurentfdumont at gmail.com Tue Feb 15 20:54:41 2022 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Tue, 15 Feb 2022 15:54:41 -0500 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: References: Message-ID: There are two settings we've tweaked in the past in Nova. shuffle_best_same_weighed_hosts --> Allow more spreading in the case of computes with the exact same specs/weights. host_subset_size --> Helps with concurrent requests to get different hosts Before that, we saw the same behavior with Openstack stacking VM on single computes. It still respects anti-affinity, but I don't see a good reason to not spread as a default. Changing these two was enough to allow our spread to get a little better. On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL < franck.vedel at univ-grenoble-alpes.fr> wrote: > Hello, > I seem to have a problem that I hadn't seen. > I have 3 servers for my openstack, built with Kolla-ansible, I'm in > Victoria version. > I had simply put the 3 servers in the [compute] part of the multinode > file, at first it worked, but for some time all the VMs are placed on > server 1. > > The 3 servers are operational, identical. here are 3 screenshots to show > it. (on the images, the instances on servers 2 and 3 are present because it > worked correctly, but no more instances are created on these servers now) > > > I tried to understand how the instances are distributed on the servers, > but in my case, I don't understand why none are assigned to the 2nd and 3rd > server. > How to find the problem? It should be nova-scheduler . Do you have to do > anything special? Go see if a parameter has a bad value? > > > Thanks in advance if you can help me. > > Franck VEDEL > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im1.png Type: image/png Size: 100474 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture d?e?cran 2022-02-15 a? 16.55.13.png Type: image/png Size: 92774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im3.png Type: image/png Size: 124170 bytes Desc: not available URL: From abraden at verisign.com Tue Feb 15 21:31:51 2022 From: abraden at verisign.com (Braden, Albert) Date: Tue, 15 Feb 2022 21:31:51 +0000 Subject: [all][elections][ptl][tc] Combined PTL/TC Zed cycle Election Nominations Last Days In-Reply-To: <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> References: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com> <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> Message-ID: I hope to volunteer for Adjutant one day. Unfortunately my employer is still trying to decide whether they will allow it. -----Original Message----- From: Ghanshyam Mann Sent: Tuesday, February 15, 2022 2:08 PM To: openstack-discuss Subject: [EXTERNAL] Re: [all][elections][ptl][tc] Combined PTL/TC Zed cycle Election Nominations Last Days Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello Everyone, Less than 5 hours left for nomination end and we still need nominations for 21 projects (Zun and Masakari nomination are there but not passed the validation): - Adjutant Freezer Heat Magnum Masakari Monasca Murano OpenStack_Charms Openstack_Chef Release_Management Requirements Senlin Skyline Solum Swift Tripleo Trove Venus Watcher Zaqar Zun If you are maintainer of above projects, please do not delay the nomination or motivate the one you think should add nomination. -gmann & The OpenStack Technical Election Officials ---- On Mon, 14 Feb 2022 18:20:38 -0600 Ghanshyam Mann wrote ---- > 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://secure-web.cisco.com/19Ftn0DM5Q47vuwPBjz89xDeLEY5Zlv5CjOH-SFcYZvyOlrYGy_4MDLN6jKWTyElNRbcs5M1ns1UEHyi0e82EGrg_xNfQu6GEup5XW_LSVaSxj6OmZCp0F8NMc9wERWsniQv7SowpJtcrkfxjIv4y9nTT0aat-HZkxcnn-CRiWZcqiIq09-HwR6YWtXlOq04GUw5g4w6oGOdel11sz6gqZpOPTWkMzcbiUnbgAfDFqVLRIA5HNYAj_48-xK6tvs4s/https%3A%2F%2Fgovernance.openstack.org%2Felection%2F%23how-to-submit-a-candidacy > [2] Any open reviews at > https://secure-web.cisco.com/1PpiMtNptDrcQD3G_EMxBciekvlxcdsnX-qwlVh73rHi3mYuAEXFMe7faW7-OleZFSNVfwGzimrgnVfi--ibB4VN2QeljQ3LhQZLlgCj_mOVtihUEeIRG4JjRfbDV1likZUlqDv22ZtssKUw4iDdn3CUr_afYZ3eHsZ5kkVTTwUBrA5luWNZLi_pNeJGFyc_qr5F5QIyO-I2l-11n97MQ34BOA5qswNOn7ttzqIbNgY9mc-Qrxd2NqcPyIod64ROv/https%3A%2F%2Freview.openstack.org%2F%23%2Fq%2Fis%3Aopen%2Bproject%3Aopenstack%2Felection > have not been factored into these stats. > [3] https://secure-web.cisco.com/19yElnIM8fntimQ7N71FdZx7UIMKcF6ELdy9ZhUfh3V1hbcgmgtgbCTehBdOsx-fbymZevZoZ8dWSp1baF4WQscDtmlhfda6F5CCf644kTcTT29VtZAnyJ8gIPXSzTMPfZBIbXj5ncnSCywtESBiw6P2o-_OzmleJtb_tsKwpQJ6G-nh43k68pZ6jFjAW4pgZ-ztOvCObjtS4l34qVdmcCcm-H6C2d4fZ87BfS4Ry5SLedAmuSou7EDNLjsGSUXSn/https%3A%2F%2Fgovernance.openstack.org%2Fresolutions%2F20141128-elections-process-for-leaderless-programs.html > > > -gmann & The OpenStack Technical Election Officials > > > From gmann at ghanshyammann.com Tue Feb 15 21:42:46 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 15 Feb 2022 15:42:46 -0600 Subject: [all][tc] Technical Committee next weekly meeting on Feb 17th at 1500 UTC Message-ID: <17eff5682c4.bd4b3d9f7304.5686127029797830923@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Feb 17th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Feb 16th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From rosmaita.fossdev at gmail.com Tue Feb 15 22:35:40 2022 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 15 Feb 2022 17:35:40 -0500 Subject: [cinder] final reviews needed for os-brick yoga release In-Reply-To: <4580dbb3-cabf-c4e5-ce11-4f0d764b714e@gmail.com> References: <4580dbb3-cabf-c4e5-ce11-4f0d764b714e@gmail.com> Message-ID: On 2/12/22 2:38 PM, Brian Rosmaita wrote: > Hello Argonauts, > > We are now aiming to release on Tuesday 15 Feb at 20:00 UTC. Would you believe Thursday 17 Feb? (In other words, we'll be releasing on the regularly scheduled day. My nefarious scheme for us to release os-brick a week early has come to naught.) > The list of patches needing review and some comments on their status is > here: > ? https://etherpad.opendev.org/p/os-brick-yoga-release Here's a quick summary. There are 2 patches still being worked on: 1. 823654: nvmeof.py - in case of missing "show-hostnqn" command - https://review.opendev.org/c/openstack/os-brick/+/823654 - this one is really close, small revision requested - need to get this in because the version of nvme-cli shipped with kolla/focus doesn't have the show-hostnqn command 2. 811718: nvmeof connector check controller already connected - https://review.opendev.org/c/openstack/os-brick/+/811718 - Gorka had a question about a possible race condition; while looking at it again he came across a different bug - we'll have to discuss this in the Wednesday cinder meeting; in the meantime, feel free to review and leave comments > > 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 gmann at ghanshyammann.com Tue Feb 15 22:39:17 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 15 Feb 2022 16:39:17 -0600 Subject: [all][elections][ptl][tc][Adjutant][Freezer][Heat][Magnum][Masakari][Monasca][Murano][OpenStack_Charms][Openstack_Chef][Senlin][Skyline][Solum][Trove][Venus][Watcher][Zaqar][Zun][Combined PTL/TC Zed cycle Election Nominations Last Days In-Reply-To: <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> References: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com> <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> Message-ID: <17eff8a3ff3.d7c839108685.7403613792495141625@ghanshyammann.com> Hello Everyone, ~1 hr left for nomination close, I am tagging the 17 projects in ML subject which left with the nomination. -gmann ---- On Tue, 15 Feb 2022 13:07:36 -0600 Ghanshyam Mann wrote ---- > Hello Everyone, > > Less than 5 hours left for nomination end and we still need nominations for 21 projects (Zun and Masakari nomination are there but not passed the validation): > > - Adjutant Freezer Heat Magnum Masakari Monasca Murano OpenStack_Charms Openstack_Chef Release_Management Requirements Senlin Skyline Solum Swift Tripleo Trove Venus Watcher Zaqar Zun > > If you are maintainer of above projects, please do not delay the nomination or motivate the one you think should add nomination. > > -gmann & The OpenStack Technical Election Officials > > ---- On Mon, 14 Feb 2022 18:20:38 -0600 Ghanshyam Mann wrote ---- > > 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 tobias.urdin at binero.com Tue Feb 15 22:47:35 2022 From: tobias.urdin at binero.com (Tobias Urdin) Date: Tue, 15 Feb 2022 22:47:35 +0000 Subject: [tooz] [mistral] Tenacity >= 8.0.1 issues (in Debian) In-Reply-To: References: , Message-ID: Hello, I actually intended to look at this for Gnocchi and since it depends on tooz I?ve pushed patches for both. I will just need to make sure it gets green and doesn?t break any usage of older versions (changes should have been in tenacity for years now but maybe we need to bump lower-constraint somewhere?) Best regards > On 14 Feb 2022, at 23:43, Thomas Goirand wrote: > > ?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 berndbausch at gmail.com Wed Feb 16 00:53:48 2022 From: berndbausch at gmail.com (Bernd Bausch) Date: Wed, 16 Feb 2022 09:53:48 +0900 Subject: Create Image in queue State in XENA Version In-Reply-To: References: Message-ID: <5b16908f-d87b-6bb2-5343-2a9a520eeec0@gmail.com> Your question does not provide any details about the context. How was your cloud set up, what Glance store(s) are configured, how are images uploaded etc. I suppose it is possible to download images, correct? You need to check the Glance API log, in particular for warning and error messages. My first idea would be to confirm whether the Glance store is accessible for writing. Also use the command line for adding an image and set the debug option: openstack --debug image create ... This may give you information about an upload failure. At a minimum, it will tell you the request ID of the failing API request, which you can use for more effective log analysis. You say that nothing is wrong in the Glance configuration files. Are you certain that your settings are still correct at Xena? Use the Xena release notes to confirm, but also earlier release notes that might announce deprecation of some settings/features. Glance may issue useful log messages about configuration issues when starting up. Bernd Bausch On 2022/02/16 12:26 AM, Adivya Singh wrote: > 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 From laurentfdumont at gmail.com Wed Feb 16 01:00:14 2022 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Tue, 15 Feb 2022 20:00:14 -0500 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: References: Message-ID: In a healthy setup, should build_failure_weight_multiplier be triggered? >From the doc, tweaking this might mean you try to schedule and built instances on computes that are not healthy. On Tue, Feb 15, 2022 at 6:38 PM Tony Liu wrote: > Enable debug logging on nova-scheduler, you will see how the winner is > picked. > I had the same issue before, caused by the build-failure weigher enabled > by default. > setting build_failure_weight_multiplier to 0 resolved issue for me. > Instances are > balanced by weighers (compute and memory) as expected. > shuffle_best_same_weighed_hosts and host_subset_size are not necessary, > unless > it's required by certain cases. > > Tony > ________________________________________ > From: Laurent Dumont > Sent: February 15, 2022 12:54 PM > To: Franck VEDEL > Cc: openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on > servers > > There are two settings we've tweaked in the past in Nova. > > shuffle_best_same_weighed_hosts --> Allow more spreading in the case of > computes with the exact same specs/weights. > host_subset_size --> Helps with concurrent requests to get different hosts > > Before that, we saw the same behavior with Openstack stacking VM on single > computes. It still respects anti-affinity, but I don't see a good reason to > not spread as a default. Changing these two was enough to allow our spread > to get a little better. > > On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL < > franck.vedel at univ-grenoble-alpes.fr franck.vedel at univ-grenoble-alpes.fr>> wrote: > Hello, > I seem to have a problem that I hadn't seen. > I have 3 servers for my openstack, built with Kolla-ansible, I'm in > Victoria version. > I had simply put the 3 servers in the [compute] part of the multinode > file, at first it worked, but for some time all the VMs are placed on > server 1. > > The 3 servers are operational, identical. here are 3 screenshots to show > it. (on the images, the instances on servers 2 and 3 are present because it > worked correctly, but no more instances are created on these servers now) > [cid:17eff2778356f37a4481] > [cid:17eff277835e47aa83c2] > [cid:17eff2778356f53d34a3] > > > I tried to understand how the instances are distributed on the servers, > but in my case, I don't understand why none are assigned to the 2nd and 3rd > server. > How to find the problem? It should be nova-scheduler . Do you have to do > anything special? Go see if a parameter has a bad value? > > > Thanks in advance if you can help me. > > Franck VEDEL > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Feb 16 01:15:37 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 15 Feb 2022 19:15:37 -0600 Subject: [all][elections][ptl][tc] Combined PTL/TC Zed cycle Election Nominations End Message-ID: <17f00196182.df06661110696.2428183964789914937@ghanshyammann.com> Hello Everyone, The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 17 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant, Freezer, Heat, Magnum, Masakari, Monasca, Murano, OpenStack_Charms, Openstack_Chef, Senlin, Skyline, Solum, Trove, Venus, Watcher, Zaqar, Zun There are 0 projects that will have elections. -- TC Election Details -- The 5 seats were filled and no runoff is required. Now begins the campaigning period where candidates and electorate may debate their statements. Thank you, [0] https://governance.openstack.org/election/#z-ptl-candidates [1] https://governance.openstack.org/election/#z-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html -gmann & The OpenStack Technical Election Officials From tonyliu0592 at hotmail.com Wed Feb 16 02:35:00 2022 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Wed, 16 Feb 2022 02:35:00 +0000 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: References: Message-ID: Build failure could be caused by different things, networking, storage, hypervisor, etc. For example, failure caused by Neutron service, that doesn't mean this hypervisor is not healthy, but because of that weigher, even Neutron service is recovered, this hypervisor is still excluded from holding instance. This doesn't make sense. I wouldn't enable this weigher until it's smart enough to know the failure is caused by hypervisor itself, but not anywhere else. Tony ________________________________________ From: Laurent Dumont Sent: February 15, 2022 05:00 PM To: Tony Liu Cc: Franck VEDEL; openstack-discuss Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers In a healthy setup, should build_failure_weight_multiplier be triggered? >From the doc, tweaking this might mean you try to schedule and built instances on computes that are not healthy. On Tue, Feb 15, 2022 at 6:38 PM Tony Liu > wrote: Enable debug logging on nova-scheduler, you will see how the winner is picked. I had the same issue before, caused by the build-failure weigher enabled by default. setting build_failure_weight_multiplier to 0 resolved issue for me. Instances are balanced by weighers (compute and memory) as expected. shuffle_best_same_weighed_hosts and host_subset_size are not necessary, unless it's required by certain cases. Tony ________________________________________ From: Laurent Dumont > Sent: February 15, 2022 12:54 PM To: Franck VEDEL Cc: openstack-discuss Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers There are two settings we've tweaked in the past in Nova. shuffle_best_same_weighed_hosts --> Allow more spreading in the case of computes with the exact same specs/weights. host_subset_size --> Helps with concurrent requests to get different hosts Before that, we saw the same behavior with Openstack stacking VM on single computes. It still respects anti-affinity, but I don't see a good reason to not spread as a default. Changing these two was enough to allow our spread to get a little better. On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL >> wrote: Hello, I seem to have a problem that I hadn't seen. I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) [cid:17eff2778356f37a4481] [cid:17eff277835e47aa83c2] [cid:17eff2778356f53d34a3] I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? Thanks in advance if you can help me. Franck VEDEL From bxzhu_5355 at 163.com Wed Feb 16 04:04:17 2022 From: bxzhu_5355 at 163.com (Boxiang Zhu) Date: Wed, 16 Feb 2022 12:04:17 +0800 (GMT+08:00) Subject: [kolla-ansible][manila]Permission denied when using cephfs nfs Message-ID: Hi all, I have met an issue when I use manila with cephfs nfs backend. Environment Information: - OS: ubuntu 18.04 - OpenStack Version: Train - Kolla-ansible Version: 9.3.2 I used kolla-ansible to deploy my OpenStack environment AIO. Here is the info of my globals.yml as followed: --- kolla_base_distro: "ubuntu" kolla_install_type: "source" openstack_release: "train" kolla_internal_vip_address: "172.16.150.67" network_interface: "ens3" neutron_external_interface: "ens4" enable_haproxy: "no" enable_ceph: "yes" enable_ceph_mds: "yes" enable_ceph_rgw: "yes" enable_ceph_nfs: "yes" enable_cinder: "yes" enable_manila: "yes" enable_manila_backend_cephfs_nfs: "yes" enable_ceph_rgw_keystone: "yes" ceph_osd_store_type: "filestore" I try to use cephfs nfs backend for manila. All containers are running and the services of manila is good. +----+------------------+-------------------+------+---------+-------+----------------------------+ | Id | Binary | Host | Zone | Status | State | Updated_at | +----+------------------+-------------------+------+---------+-------+----------------------------+ | 1 | manila-data | manila | nova | enabled | up | 2022-02-16T03:25:34.000000 | | 2 | manila-scheduler | manila | nova | enabled | up | 2022-02-16T03:25:35.000000 | | 3 | manila-share | manila at cephfsnfs1 | nova | enabled | up | 2022-02-16T03:25:40.000000 | +----+------------------+-------------------+------+---------+-------+----------------------------+ Here is my share type: +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ | ID | Name | visibility | is_default | required_extra_specs | optional_extra_specs | Description | +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ | 265a6637-0322-4c4a-9185-f30f01b96d12 | default_share_type | public | - | driver_handles_share_servers : False | | None | +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ When I create a share, error information appears in manila-share.log file: 2022-02-16 09:30:04.615 20 INFO manila.share.manager [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share status 2022-02-16 09:30:04.616 20 DEBUG manila.share.driver [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share stats. _update_share_stats /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/driver.py:1232 2022-02-16 09:30:54.675 20 DEBUG manila.share.drivers.cephfs.driver [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] create_share CEPHFSNFS1 name=449a52a4-f19c-4d1b-b437-7dc2443e040c size=1 share_group_id=None create_share /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py:262 2022-02-16 09:30:54.682 20 INFO ceph_volume_client [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] create_volume: /volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c2022-02-16 09:30:54.927 20 ERROR manila.share.manager [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] Share instance 449a52a4-f19c-4d1b-b437-7dc2443e040c failed on creation.: cephfs.OSError: error in mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission denied [Errno 13] 2022-02-16 09:30:54.929 20 WARNING manila.share.manager [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] Share instance information in exception can not be written to db because it contains {} and it is not a dictionary.: cephfs.OSError: error in mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission denied [Errno 13] 2022-02-16 09:30:54.955 20 INFO manila.message.api [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] Creating message record for request_id = req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] Exception during message handling: cephfs.OSError: error in mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission denied [Errno 13] 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 656, in _mkdir_p 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server self.fs.stat(subpath) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "cephfs.pyx", line 1257, in cephfs.LibCephFS.stat 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server cephfs.ObjectNotFound: error in stat: volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: No such file or directory [Errno 2] 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server During handling of the above exception, another exception occurred: 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 274, in dispatch 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", line 187, in wrapped 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server return f(self, *args, **kwargs) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/utils.py", line 568, in wrapper 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server return func(self, *args, **kwargs) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", line 1790, in create_share_instance 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server exception=e) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server self.force_reraise() 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/six.py", line 693, in reraise 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server raise value 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", line 1753, in create_share_instance 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server context, share_instance, share_server=share_server) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py", line 272, in create_share 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server mode=self._cephfs_volume_mode) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 677, in create_volume 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server self._mkdir_p(path, mode) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 658, in _mkdir_p 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server self.fs.mkdir(subpath, mode) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "cephfs.pyx", line 887, in cephfs.LibCephFS.mkdir 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server cephfs.OSError: error in mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission denied [Errno 13] 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Wed Feb 16 04:31:00 2022 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 15 Feb 2022 23:31:00 -0500 Subject: Openstack HPC Infiniband question Message-ID: Hi all, I am playing with HPC on openstack cloud deployment and I have a Mellanox infiniband nic card. I have a couple of deployment questions regarding the infiniband network. I am new to ib so excuse me if i ask noob questions. I have configured Mellanox for sriov and created a flavor with the property pci_passthrough:alias='mlx5-sriov-ib:1' to expose VF to my instance. so far so good and i am able to see the ib interface inside my vm and its active. (I am running SM inside infiniband HW switch) root at ib-vm:~# ethtool -i ibs5 driver: mlx5_core[ib_ipoib] version: 5.5-1.0.3 firmware-version: 20.28.1002 (MT_0000000222) expansion-rom-version: bus-info: 0000:00:05.0 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: no supports-priv-flags: yes I didn't configure any ipaddr on the ibs5 interface etc. For testing purposes I have compiled mpirun hello world program to POC my infiniband network between two instances and I am able to successfully run the mpi sample program. Somewhere i read about neutron-mellanox agent to setup IPoIB for segmentation etc but not very sure that how complex it and what are the advantage here over just using simple passthru of SR-IOV Is this the correct way to set up an HPC cluster using openstack or is there a better way to design HPC on openstack? From franck.vedel at univ-grenoble-alpes.fr Wed Feb 16 09:52:35 2022 From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL) Date: Wed, 16 Feb 2022 10:52:35 +0100 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: References: Message-ID: <512CF6F4-BC22-486D-B28F-3CD57E2CE479@univ-grenoble-alpes.fr> Thank?s a lot ! I changed the settings and indeed, it seems to work. This distribution of instances is really interesting. I learn a lot. Question: is it possible to view the calculated weight when choosing a server? Otherwise, thanks again, really Franck > Le 16 f?vr. 2022 ? 03:35, Tony Liu a ?crit : > > Build failure could be caused by different things, networking, storage, hypervisor, etc. > For example, failure caused by Neutron service, that doesn't mean this hypervisor is > not healthy, but because of that weigher, even Neutron service is recovered, this > hypervisor is still excluded from holding instance. This doesn't make sense. > I wouldn't enable this weigher until it's smart enough to know the failure is caused > by hypervisor itself, but not anywhere else. > > Tony > ________________________________________ > From: Laurent Dumont > Sent: February 15, 2022 05:00 PM > To: Tony Liu > Cc: Franck VEDEL; openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers > > In a healthy setup, should build_failure_weight_multiplier be triggered? > > From the doc, tweaking this might mean you try to schedule and built instances on computes that are not healthy. > > On Tue, Feb 15, 2022 at 6:38 PM Tony Liu > wrote: > Enable debug logging on nova-scheduler, you will see how the winner is picked. > I had the same issue before, caused by the build-failure weigher enabled by default. > setting build_failure_weight_multiplier to 0 resolved issue for me. Instances are > balanced by weighers (compute and memory) as expected. > shuffle_best_same_weighed_hosts and host_subset_size are not necessary, unless > it's required by certain cases. > > Tony > ________________________________________ > From: Laurent Dumont > > Sent: February 15, 2022 12:54 PM > To: Franck VEDEL > Cc: openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers > > There are two settings we've tweaked in the past in Nova. > > shuffle_best_same_weighed_hosts --> Allow more spreading in the case of computes with the exact same specs/weights. > host_subset_size --> Helps with concurrent requests to get different hosts > > Before that, we saw the same behavior with Openstack stacking VM on single computes. It still respects anti-affinity, but I don't see a good reason to not spread as a default. Changing these two was enough to allow our spread to get a little better. > > On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL >> wrote: > Hello, > I seem to have a problem that I hadn't seen. > I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. > I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. > > The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) > [cid:17eff2778356f37a4481] > [cid:17eff277835e47aa83c2] > [cid:17eff2778356f53d34a3] > > > I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. > How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? > > > Thanks in advance if you can help me. > > Franck VEDEL > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahendra.paipuri at cnrs.fr Wed Feb 16 10:20:03 2022 From: mahendra.paipuri at cnrs.fr (Mahendra Paipuri) Date: Wed, 16 Feb 2022 11:20:03 +0100 Subject: Openstack HPC Infiniband question In-Reply-To: References: Message-ID: <45a0a5e2-b3d9-bb83-7756-97e3920ccbd0@cnrs.fr> Hello, I have worked on IB before although not on the top of Openstack. As primary purpose of IB is to use RDMA, you should check if it is working on your instances. I am not quite sure if a simple hello world code is sufficient to test RDMA functionality. Because, if there is any issue with IB stack, MPI implementations tend to fallback to TCP for communications. One thing you can do is install linux rdma-core [1] (if you have not already done it) and use `ibstat` command to check if your IB ports are up and running. Then you can build OpenMPI with UCX [2] and do a PingPong test [3] to see if you are getting proper bandwidth according to your ConnectX card type. If you are planning to do more HPC tests on Openstack cloud, I suggest you look into HPC package managers like Spack [4] or EasyBuild [5] to build HPC related stack easily. StackHPC has been working on HPC over Openstack clouds and they developed some tools [6] which might of interest to you.? I hope that helps!! - Mahendra [1] https://github.com/linux-rdma/rdma-core [2] https://openucx.readthedocs.io/en/master/running.html#openmpi-with-ucx [3] https://www.intel.com/content/www/us/en/develop/documentation/imb-user-guide/top/mpi-1-benchmarks/imb-p2p-benchmarks/pingpong.html [4] https://spack-tutorial.readthedocs.io/en/latest/ [5] https://docs.easybuild.io/ [6] https://github.com/stackhpc On 16/02/2022 05:31, Satish Patel wrote: > Hi all, > > I am playing with HPC on openstack cloud deployment and I have a > Mellanox infiniband nic card. I have a couple of deployment questions > regarding the infiniband network. I am new to ib so excuse me if i ask > noob questions. > > I have configured Mellanox for sriov and created a flavor with the > property pci_passthrough:alias='mlx5-sriov-ib:1' to expose VF to my > instance. so far so good and i am able to see the ib interface inside > my vm and its active. (I am running SM inside infiniband HW switch) > > root at ib-vm:~# ethtool -i ibs5 > driver: mlx5_core[ib_ipoib] > version: 5.5-1.0.3 > firmware-version: 20.28.1002 (MT_0000000222) > expansion-rom-version: > bus-info: 0000:00:05.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: no > supports-register-dump: no > supports-priv-flags: yes > > I didn't configure any ipaddr on the ibs5 interface etc. For testing > purposes I have compiled mpirun hello world program to POC my > infiniband network between two instances and I am able to successfully > run the mpi sample program. > > Somewhere i read about neutron-mellanox agent to setup IPoIB for > segmentation etc but not very sure that how complex it and what are > the advantage here over just using simple passthru of SR-IOV > > Is this the correct way to set up an HPC cluster using openstack or is > there a better way to design HPC on openstack? > From smooney at redhat.com Wed Feb 16 12:45:11 2022 From: smooney at redhat.com (Sean Mooney) Date: Wed, 16 Feb 2022 12:45:11 +0000 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: References: Message-ID: <10a704d1461a0a78bbe898d0ca11372b7b9f1288.camel@redhat.com> On Wed, 2022-02-16 at 02:35 +0000, Tony Liu wrote: > Build failure could be caused by different things, networking, storage, hypervisor, etc. > For example, failure caused by Neutron service, that doesn't mean this hypervisor is > not healthy, but because of that weigher, even Neutron service is recovered, this > hypervisor is still excluded from holding instance. This doesn't make sense. > I wouldn't enable this weigher until it's smart enough to know the failure is caused > by hypervisor itself, but not anywhere else. this is enabled by default on all deployments and has been for many years at this point. we stongly recommend that it is used. you can elect to disable it but if you do you can end up with vms constantly being sechdluled to the same set of broken hosts this become more apprent as the deployment get more full. while you coudl reduce the weight of this filter it high multipler was conse so that it coudl override the votes of the other weighers. we likely could imporve the weigher perhaps have it age our the failed builds to account for traisient failures or provide a nova-manage command to allow operators to reset the value for a host or soemthign like that but in a healthy cloud you should not get failed builds that land on a host rater then cell0 you can get failed builds where there is no host avaiable but those will land in cell0 and not affect the host failure count. you can also get failed builds due to quota ectra but that is validated in the api before we try to build the instance so if you are getting failed builds it shoudl be an indication that you have at least a trasient problem with your deployment that shoudl be fixed. > > Tony > ________________________________________ > From: Laurent Dumont > Sent: February 15, 2022 05:00 PM > To: Tony Liu > Cc: Franck VEDEL; openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers > > In a healthy setup, should build_failure_weight_multiplier be triggered? > > From the doc, tweaking this might mean you try to schedule and built instances on computes that are not healthy. > > On Tue, Feb 15, 2022 at 6:38 PM Tony Liu > wrote: > Enable debug logging on nova-scheduler, you will see how the winner is picked. > I had the same issue before, caused by the build-failure weigher enabled by default. > setting build_failure_weight_multiplier to 0 resolved issue for me. Instances are > balanced by weighers (compute and memory) as expected. > shuffle_best_same_weighed_hosts and host_subset_size are not necessary, unless > it's required by certain cases. > > Tony > ________________________________________ > From: Laurent Dumont > > Sent: February 15, 2022 12:54 PM > To: Franck VEDEL > Cc: openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers > > There are two settings we've tweaked in the past in Nova. > > shuffle_best_same_weighed_hosts --> Allow more spreading in the case of computes with the exact same specs/weights. > host_subset_size --> Helps with concurrent requests to get different hosts > > Before that, we saw the same behavior with Openstack stacking VM on single computes. It still respects anti-affinity, but I don't see a good reason to not spread as a default. Changing these two was enough to allow our spread to get a little better. > > On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL >> wrote: > Hello, > I seem to have a problem that I hadn't seen. > I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. > I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. > > The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) > [cid:17eff2778356f37a4481] > [cid:17eff277835e47aa83c2] > [cid:17eff2778356f53d34a3] > > > I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. > How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? > > > Thanks in advance if you can help me. > > Franck VEDEL > > > From smooney at redhat.com Wed Feb 16 12:45:50 2022 From: smooney at redhat.com (Sean Mooney) Date: Wed, 16 Feb 2022 12:45:50 +0000 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: <512CF6F4-BC22-486D-B28F-3CD57E2CE479@univ-grenoble-alpes.fr> References: <512CF6F4-BC22-486D-B28F-3CD57E2CE479@univ-grenoble-alpes.fr> Message-ID: <315f6246b9aafc18e1976d7e271848bef5691764.camel@redhat.com> On Wed, 2022-02-16 at 10:52 +0100, Franck VEDEL wrote: > Thank?s a lot ! > I changed the settings and indeed, it seems to work. This distribution of instances is really interesting. I learn a lot. > Question: is it possible to view the calculated weight when choosing a server? > Otherwise, thanks again, really yes this is logged in the schduler at debug level > > Franck > > > Le 16 f?vr. 2022 ? 03:35, Tony Liu a ?crit : > > > > Build failure could be caused by different things, networking, storage, hypervisor, etc. > > For example, failure caused by Neutron service, that doesn't mean this hypervisor is > > not healthy, but because of that weigher, even Neutron service is recovered, this > > hypervisor is still excluded from holding instance. This doesn't make sense. > > I wouldn't enable this weigher until it's smart enough to know the failure is caused > > by hypervisor itself, but not anywhere else. > > > > Tony > > ________________________________________ > > From: Laurent Dumont > > Sent: February 15, 2022 05:00 PM > > To: Tony Liu > > Cc: Franck VEDEL; openstack-discuss > > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers > > > > In a healthy setup, should build_failure_weight_multiplier be triggered? > > > > From the doc, tweaking this might mean you try to schedule and built instances on computes that are not healthy. > > > > On Tue, Feb 15, 2022 at 6:38 PM Tony Liu > wrote: > > Enable debug logging on nova-scheduler, you will see how the winner is picked. > > I had the same issue before, caused by the build-failure weigher enabled by default. > > setting build_failure_weight_multiplier to 0 resolved issue for me. Instances are > > balanced by weighers (compute and memory) as expected. > > shuffle_best_same_weighed_hosts and host_subset_size are not necessary, unless > > it's required by certain cases. > > > > Tony > > ________________________________________ > > From: Laurent Dumont > > > Sent: February 15, 2022 12:54 PM > > To: Franck VEDEL > > Cc: openstack-discuss > > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers > > > > There are two settings we've tweaked in the past in Nova. > > > > shuffle_best_same_weighed_hosts --> Allow more spreading in the case of computes with the exact same specs/weights. > > host_subset_size --> Helps with concurrent requests to get different hosts > > > > Before that, we saw the same behavior with Openstack stacking VM on single computes. It still respects anti-affinity, but I don't see a good reason to not spread as a default. Changing these two was enough to allow our spread to get a little better. > > > > On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL >> wrote: > > Hello, > > I seem to have a problem that I hadn't seen. > > I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. > > I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. > > > > The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) > > [cid:17eff2778356f37a4481] > > [cid:17eff277835e47aa83c2] > > [cid:17eff2778356f53d34a3] > > > > > > I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. > > How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? > > > > > > Thanks in advance if you can help me. > > > > Franck VEDEL > > > From eblock at nde.ag Wed Feb 16 13:41:15 2022 From: eblock at nde.ag (Eugen Block) Date: Wed, 16 Feb 2022 13:41:15 +0000 Subject: [kolla-ansible][manila]Permission denied when using cephfs nfs In-Reply-To: Message-ID: <20220216134115.Horde.qEmiPZOnsxvbkcw0OCUN8ly@webmail.nde.ag> This sounds a lot like this bug: https://bugs.launchpad.net/charm-manila-ganesha/+bug/1901570 What are your ceph auth caps for the required pool(s)? I'm not familiar with Manila or Kolla, but maybe as a workaround you can change the directory permissions as described in the report. Zitat von Boxiang Zhu : > Hi all, > > > I have met an issue when I use manila with cephfs nfs backend. > > > Environment Information: > - OS: ubuntu 18.04 > - OpenStack Version: Train > - Kolla-ansible Version: 9.3.2 > > > I used kolla-ansible to deploy my OpenStack environment AIO. > > > Here is the info of my globals.yml as followed: > --- > kolla_base_distro: "ubuntu" > kolla_install_type: "source" > openstack_release: "train" > kolla_internal_vip_address: "172.16.150.67" > network_interface: "ens3" > neutron_external_interface: "ens4" > enable_haproxy: "no" > enable_ceph: "yes" > enable_ceph_mds: "yes" > enable_ceph_rgw: "yes" > enable_ceph_nfs: "yes" > enable_cinder: "yes" > enable_manila: "yes" > enable_manila_backend_cephfs_nfs: "yes" > enable_ceph_rgw_keystone: "yes" > ceph_osd_store_type: "filestore" > > > I try to use cephfs nfs backend for manila. > All containers are running and the services of manila is good. > +----+------------------+-------------------+------+---------+-------+----------------------------+ > | Id | Binary | Host | Zone | Status | State | Updated_at | > +----+------------------+-------------------+------+---------+-------+----------------------------+ > | 1 | manila-data | manila | nova | enabled | up | > 2022-02-16T03:25:34.000000 | > | 2 | manila-scheduler | manila | nova | enabled | up | > 2022-02-16T03:25:35.000000 | > | 3 | manila-share | manila at cephfsnfs1 | nova | enabled | up | > 2022-02-16T03:25:40.000000 | > +----+------------------+-------------------+------+---------+-------+----------------------------+ > > > Here is my share type: > +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ > | ID | Name | > visibility | is_default | required_extra_specs | > optional_extra_specs | Description | > +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ > | 265a6637-0322-4c4a-9185-f30f01b96d12 | default_share_type | public > | - | driver_handles_share_servers : False | > | None | > +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ > > > When I create a share, error information appears in manila-share.log file: > > > 2022-02-16 09:30:04.615 20 INFO manila.share.manager > [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share > status > 2022-02-16 09:30:04.616 20 DEBUG manila.share.driver > [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share > stats. _update_share_stats > /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/driver.py:1232 > 2022-02-16 09:30:54.675 20 DEBUG manila.share.drivers.cephfs.driver > [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > - -] create_share CEPHFSNFS1 > name=449a52a4-f19c-4d1b-b437-7dc2443e040c size=1 share_group_id=None > create_share > /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py:262 > 2022-02-16 09:30:54.682 20 INFO ceph_volume_client > [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > - -] create_volume: > /volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c2022-02-16 > 09:30:54.927 20 ERROR manila.share.manager > [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > - -] Share instance 449a52a4-f19c-4d1b-b437-7dc2443e040c failed on > creation.: cephfs.OSError: error in mkdir > volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission > denied [Errno 13] > 2022-02-16 09:30:54.929 20 WARNING manila.share.manager > [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > - -] Share instance information in exception can not be written to > db because it contains {} and it is not a dictionary.: > cephfs.OSError: error in mkdir > volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission > denied [Errno 13] > 2022-02-16 09:30:54.955 20 INFO manila.message.api > [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > - -] Creating message record for request_id = > req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > - -] Exception during message handling: cephfs.OSError: error in > mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: > Permission denied [Errno 13] > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback > (most recent call last): > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 656, in > _mkdir_p > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > self.fs.stat(subpath) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "cephfs.pyx", line 1257, in cephfs.LibCephFS.stat > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > cephfs.ObjectNotFound: error in stat: > volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: No such file > or directory [Errno 2] > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server During > handling of the above exception, another exception occurred: > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback > (most recent call last): > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, in > _process_incoming > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server res = > self.dispatcher.dispatch(message) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 274, in > dispatch > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > return self._do_dispatch(endpoint, method, ctxt, args) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in > _do_dispatch > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > result = func(ctxt, **new_args) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", > line 187, in wrapped > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > return f(self, *args, **kwargs) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/utils.py", > line 568, in wrapper > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > return func(self, *args, **kwargs) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", > line 1790, in create_share_instance > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server exception=e) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 220, in __exit__ > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > self.force_reraise() > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 196, in force_reraise > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > six.reraise(self.type_, self.value, self.tb) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/six.py", line 693, > in reraise > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server raise value > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", > line 1753, in create_share_instance > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > context, share_instance, share_server=share_server) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py", line 272, in > create_share > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > mode=self._cephfs_volume_mode) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 677, in > create_volume > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > self._mkdir_p(path, mode) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 658, in > _mkdir_p > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > self.fs.mkdir(subpath, mode) > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > "cephfs.pyx", line 887, in cephfs.LibCephFS.mkdir > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > cephfs.OSError: error in mkdir > volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission > denied [Errno 13] > 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server From knikolla at bu.edu Wed Feb 16 14:23:34 2022 From: knikolla at bu.edu (Nikolla, Kristi) Date: Wed, 16 Feb 2022 14:23:34 +0000 Subject: [keystone] anyone using OpenID with Keystone? In-Reply-To: References: Message-ID: <5FF67B34-1ACC-4195-94A5-4653B9462252@bu.edu> Would application credentials fit your use case for CLI access? Users will be able to create them through Horizon, and after creation they will be prompted to download either a clouds.yaml or an openrc file, so the process is pretty straightforward. https://docs.openstack.org/keystone/latest/user/application_credentials.html Can you elaborate more on your issue with not being able to grant roles to groups? Best, Kristi On Feb 15, 2022, at 05: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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Feb 16 14:32:03 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 16 Feb 2022 08:32:03 -0600 Subject: [all][elections][tc] TC Election Campaigning Kickoff Message-ID: <17f02f28808.ee711d6465602.6522021347693836554@ghanshyammann.com> Community Members, The TC Election Campaigning Period has now started [1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms [2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform [2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. Even though there are no runoffs, still it is good to have campaigning discussion. [1] https://governance.openstack.org/election/ [2] https://governance.openstack.org/election/#z-tc-candidates -gmann & The OpenStack Technical Election Officials From satish.txt at gmail.com Wed Feb 16 14:44:08 2022 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 16 Feb 2022 09:44:08 -0500 Subject: Openstack HPC Infiniband question In-Reply-To: <45a0a5e2-b3d9-bb83-7756-97e3920ccbd0@cnrs.fr> References: <45a0a5e2-b3d9-bb83-7756-97e3920ccbd0@cnrs.fr> Message-ID: Thank you Mahendra, I did compile hello world with openmpi with ucx and also I turned off fallback to TCP while running MPI jobs and it does work. I did test ib interface using ib_read_bw running between two nodes and I almost hit 97 Gbps bandwidth. ib-1 and ib-2 are my two vm instances running on two different hypervisors. root at ib-1:~# ib_write_bw -F --report_gbits ib-2 --------------------------------------------------------------------------------------- RDMA_Write BW Test Dual-port : OFF Device : mlx5_0 Number of qps : 1 Transport type : IB Connection type : RC Using SRQ : OFF PCIe relax order: ON ibv_wr* API : ON TX depth : 128 CQ Moderation : 1 Mtu : 4096[B] Link type : IB Max inline data : 0[B] rdma_cm QPs : OFF Data ex. method : Ethernet --------------------------------------------------------------------------------------- local address: LID 0x26 QPN 0x03f0 PSN 0xae88e6 RKey 0x020464 VAddr 0x007fba82a4b000 remote address: LID 0x2a QPN 0x03f2 PSN 0x5ac9fa RKey 0x020466 VAddr 0x007fe68a5cf000 --------------------------------------------------------------------------------------- #bytes #iterations BW peak[Gb/sec] BW average[Gb/sec] MsgRate[Mpps] 65536 5000 97.08 97.02 0.185048 --------------------------------------------------------------------------------------- Looks like my infiniband network is working so far based on all my validation tests. I am just curious to know how folks running HPC on openstack using IPoIB or RDMA or any other better and simple way to deploy HPC on openstack. On Wed, Feb 16, 2022 at 5:23 AM Mahendra Paipuri wrote: > > Hello, > > I have worked on IB before although not on the top of Openstack. As > primary purpose of IB is to use RDMA, you should check if it is working > on your instances. I am not quite sure if a simple hello world code is > sufficient to test RDMA functionality. Because, if there is any issue > with IB stack, MPI implementations tend to fallback to TCP for > communications. One thing you can do is install linux rdma-core [1] (if > you have not already done it) and use `ibstat` command to check if your > IB ports are up and running. Then you can build OpenMPI with UCX [2] and > do a PingPong test [3] to see if you are getting proper bandwidth > according to your ConnectX card type. > > If you are planning to do more HPC tests on Openstack cloud, I suggest > you look into HPC package managers like Spack [4] or EasyBuild [5] to > build HPC related stack easily. StackHPC has been working on HPC over > Openstack clouds and they developed some tools [6] which might of > interest to you. I hope that helps!! > > - > > Mahendra > > [1] https://github.com/linux-rdma/rdma-core > > [2] https://openucx.readthedocs.io/en/master/running.html#openmpi-with-ucx > > [3] > https://www.intel.com/content/www/us/en/develop/documentation/imb-user-guide/top/mpi-1-benchmarks/imb-p2p-benchmarks/pingpong.html > > [4] https://spack-tutorial.readthedocs.io/en/latest/ > > [5] https://docs.easybuild.io/ > > [6] https://github.com/stackhpc > > On 16/02/2022 05:31, Satish Patel wrote: > > Hi all, > > > > I am playing with HPC on openstack cloud deployment and I have a > > Mellanox infiniband nic card. I have a couple of deployment questions > > regarding the infiniband network. I am new to ib so excuse me if i ask > > noob questions. > > > > I have configured Mellanox for sriov and created a flavor with the > > property pci_passthrough:alias='mlx5-sriov-ib:1' to expose VF to my > > instance. so far so good and i am able to see the ib interface inside > > my vm and its active. (I am running SM inside infiniband HW switch) > > > > root at ib-vm:~# ethtool -i ibs5 > > driver: mlx5_core[ib_ipoib] > > version: 5.5-1.0.3 > > firmware-version: 20.28.1002 (MT_0000000222) > > expansion-rom-version: > > bus-info: 0000:00:05.0 > > supports-statistics: yes > > supports-test: yes > > supports-eeprom-access: no > > supports-register-dump: no > > supports-priv-flags: yes > > > > I didn't configure any ipaddr on the ibs5 interface etc. For testing > > purposes I have compiled mpirun hello world program to POC my > > infiniband network between two instances and I am able to successfully > > run the mpi sample program. > > > > Somewhere i read about neutron-mellanox agent to setup IPoIB for > > segmentation etc but not very sure that how complex it and what are > > the advantage here over just using simple passthru of SR-IOV > > > > Is this the correct way to set up an HPC cluster using openstack or is > > there a better way to design HPC on openstack? > > > From jose.castro.leon at cern.ch Wed Feb 16 14:45:02 2022 From: jose.castro.leon at cern.ch (Jose Castro Leon) Date: Wed, 16 Feb 2022 15:45:02 +0100 Subject: [keystone] anyone using OpenID with Keystone? In-Reply-To: <5FF67B34-1ACC-4195-94A5-4653B9462252@bu.edu> References: <5FF67B34-1ACC-4195-94A5-4653B9462252@bu.edu> Message-ID: <4df2d683-c7f3-f487-c8a4-6be511ba4228@cern.ch> Hi, We are preparing something based on keystoneauth1 that uses an authorization code grant in OIDC that will send you an url address to the client so they can do the SSO there and receive a validation code. Then you input the validation code in the CLI and receive an OIDC. Once it receives the OIDC access token and refresh token, we cache them on the filesystem for subsequent calls. The idea was to contribute it upstream once we clean it up a bit Cheers Jose On 2/16/22 15:23, Nikolla, Kristi wrote: > Would application credentials fit your use case for CLI access? Users > will be able to create them through Horizon, and after creation they > will be prompted to download either a clouds.yaml or an openrc file, so > the process is pretty straightforward. > > https://docs.openstack.org/keystone/latest/user/application_credentials.html > > > Can you elaborate more on your issue with not being able to grant roles > to groups? > > Best, > Kristi > >> On Feb 15, 2022, at 05: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 tonyliu0592 at hotmail.com Tue Feb 15 23:38:06 2022 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Tue, 15 Feb 2022 23:38:06 +0000 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: References: Message-ID: Enable debug logging on nova-scheduler, you will see how the winner is picked. I had the same issue before, caused by the build-failure weigher enabled by default. setting build_failure_weight_multiplier to 0 resolved issue for me. Instances are balanced by weighers (compute and memory) as expected. shuffle_best_same_weighed_hosts and host_subset_size are not necessary, unless it's required by certain cases. Tony ________________________________________ From: Laurent Dumont Sent: February 15, 2022 12:54 PM To: Franck VEDEL Cc: openstack-discuss Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers There are two settings we've tweaked in the past in Nova. shuffle_best_same_weighed_hosts --> Allow more spreading in the case of computes with the exact same specs/weights. host_subset_size --> Helps with concurrent requests to get different hosts Before that, we saw the same behavior with Openstack stacking VM on single computes. It still respects anti-affinity, but I don't see a good reason to not spread as a default. Changing these two was enough to allow our spread to get a little better. On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL > wrote: Hello, I seem to have a problem that I hadn't seen. I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) [cid:17eff2778356f37a4481] [cid:17eff277835e47aa83c2] [cid:17eff2778356f53d34a3] I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? Thanks in advance if you can help me. Franck VEDEL -------------- next part -------------- A non-text attachment was scrubbed... Name: im1.png Type: image/png Size: 100474 bytes Desc: im1.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture d?e?cran 2022-02-15 a? 16.55.13.png Type: image/png Size: 92774 bytes Desc: Capture d?e?cran 2022-02-15 a? 16.55.13.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: im3.png Type: image/png Size: 124170 bytes Desc: im3.png URL: From anyrude10 at gmail.com Wed Feb 16 12:58:58 2022 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Wed, 16 Feb 2022 18:28:58 +0530 Subject: [TripleO] Offline Installation Support Message-ID: Hi Team, We have successfully done POC on deploying my TripleO Train HA Setup with Baremetal Provisioning on Overcloud Node as well. We would like to thank Tripleo community members for helping us and resolving all our concerns at all times. Moving forward, we need to deploy the setup on the Lab environment for which I need some support as well. We don't have internet in Lab machines, all that we have is access to a central server (staging) which has internet access and we can download all the requirements over there. Queries: - Is there any feasible method to install Undercloud and Overcloud Machines in complete offline mode? - If yes, then 1. What are the steps to download all related stuff on the staging server? 2. What modifications would be required in undercloud/overcloud and other configuration files to support this? Regards Anirudh Gupta Regards Anirudh Gupta -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcastill at redhat.com Wed Feb 16 16:28:44 2022 From: rcastill at redhat.com (Rafael Castillo) Date: Wed, 16 Feb 2022 09:28:44 -0700 Subject: [TripleO] Gate blocker - ansible version Message-ID: Hi All, We have an issue affecting multiple centos stream 8 gate jobs related to an ansible version conflict. Details: https://bugs.launchpad.net/tripleo/+bug/1961035 We are currently deciding on the best course of action for unblocking this issue. We will post an update once the gate is clear. Until then, please hold on rechecking. Thank you! From tonyliu0592 at hotmail.com Wed Feb 16 16:37:01 2022 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Wed, 16 Feb 2022 16:37:01 +0000 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: <10a704d1461a0a78bbe898d0ca11372b7b9f1288.camel@redhat.com> References: <10a704d1461a0a78bbe898d0ca11372b7b9f1288.camel@redhat.com> Message-ID: Totally understand the intention and risk. What I'd expect is some way to 1) expose such failure for monitor system to detect it, eg. by local nova-compute API or global nova-api, (we also collect and analyze logs, it will trigger alarm when failure happens, but it would be easier to get such info from API.), then operator will be able to jump in and fix it, 2) reset the failure flag to recover. Thanks! Tony ________________________________________ From: Sean Mooney Sent: February 16, 2022 04:45 AM To: Tony Liu; Laurent Dumont Cc: Franck VEDEL; openstack-discuss Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers On Wed, 2022-02-16 at 02:35 +0000, Tony Liu wrote: > Build failure could be caused by different things, networking, storage, hypervisor, etc. > For example, failure caused by Neutron service, that doesn't mean this hypervisor is > not healthy, but because of that weigher, even Neutron service is recovered, this > hypervisor is still excluded from holding instance. This doesn't make sense. > I wouldn't enable this weigher until it's smart enough to know the failure is caused > by hypervisor itself, but not anywhere else. this is enabled by default on all deployments and has been for many years at this point. we stongly recommend that it is used. you can elect to disable it but if you do you can end up with vms constantly being sechdluled to the same set of broken hosts this become more apprent as the deployment get more full. while you coudl reduce the weight of this filter it high multipler was conse so that it coudl override the votes of the other weighers. we likely could imporve the weigher perhaps have it age our the failed builds to account for traisient failures or provide a nova-manage command to allow operators to reset the value for a host or soemthign like that but in a healthy cloud you should not get failed builds that land on a host rater then cell0 you can get failed builds where there is no host avaiable but those will land in cell0 and not affect the host failure count. you can also get failed builds due to quota ectra but that is validated in the api before we try to build the instance so if you are getting failed builds it shoudl be an indication that you have at least a trasient problem with your deployment that shoudl be fixed. > > Tony > ________________________________________ > From: Laurent Dumont > Sent: February 15, 2022 05:00 PM > To: Tony Liu > Cc: Franck VEDEL; openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers > > In a healthy setup, should build_failure_weight_multiplier be triggered? > > From the doc, tweaking this might mean you try to schedule and built instances on computes that are not healthy. > > On Tue, Feb 15, 2022 at 6:38 PM Tony Liu > wrote: > Enable debug logging on nova-scheduler, you will see how the winner is picked. > I had the same issue before, caused by the build-failure weigher enabled by default. > setting build_failure_weight_multiplier to 0 resolved issue for me. Instances are > balanced by weighers (compute and memory) as expected. > shuffle_best_same_weighed_hosts and host_subset_size are not necessary, unless > it's required by certain cases. > > Tony > ________________________________________ > From: Laurent Dumont > > Sent: February 15, 2022 12:54 PM > To: Franck VEDEL > Cc: openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers > > There are two settings we've tweaked in the past in Nova. > > shuffle_best_same_weighed_hosts --> Allow more spreading in the case of computes with the exact same specs/weights. > host_subset_size --> Helps with concurrent requests to get different hosts > > Before that, we saw the same behavior with Openstack stacking VM on single computes. It still respects anti-affinity, but I don't see a good reason to not spread as a default. Changing these two was enough to allow our spread to get a little better. > > On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL >> wrote: > Hello, > I seem to have a problem that I hadn't seen. > I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. > I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. > > The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) > [cid:17eff2778356f37a4481] > [cid:17eff277835e47aa83c2] > [cid:17eff2778356f53d34a3] > > > I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. > How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? > > > Thanks in advance if you can help me. > > Franck VEDEL > > > From gouthampravi at gmail.com Wed Feb 16 17:30:21 2022 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Wed, 16 Feb 2022 09:30:21 -0800 Subject: [manila][cinder][glance][nova][devstack][qa] Add fmount to devstack-plugin-ceph core In-Reply-To: References: Message-ID: On Wed, Feb 9, 2022 at 7: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? > > 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 Thanks all for your responses; I've added him to the group. From derekokeeffe85 at yahoo.ie Wed Feb 16 18:04:20 2022 From: derekokeeffe85 at yahoo.ie (Derek O keeffe) Date: Wed, 16 Feb 2022 18:04:20 +0000 (UTC) Subject: Masquerading VM works 99% In-Reply-To: <5801622.lOV4Wx5bFT@p1> References: <46615849.557895.1644509565653.ref@mail.yahoo.com> <46615849.557895.1644509565653@mail.yahoo.com> <5801622.lOV4Wx5bFT@p1> Message-ID: <1132455927.3695356.1645034661008@mail.yahoo.com> Hi, Laurent, Slawek, Removing the port security did indeed solve the issue for me so I really appreciate the advice from both of you. On your point below Slawek:ML2/Linuxbridge don't supports distributed routing (DVR) at all. What do You?mean by "distributed routing" here?" We have enabled DVR on the nodes in the following locations: plugins/ml2/ml2_conf.ini:enable_distributed_routing = Trueplugins/ml2/linuxbridge_agent.ini:enable_distributed_routing = Trueneutron.conf:router_distributed = True We have obviously been mistaken here, we had assumed this was working as the VM's on each compute can continue working fine if the controller is shut down. Would this be a reason that if we spin up a neutron router the interface is always down and we cannot bring it up? We're a little caught on the networking side of things. Regards,Derek ? On Tuesday 15 February 2022, 09:41:54 GMT, Slawek Kaplonski wrote: 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 > > 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 -------------- An HTML attachment was scrubbed... URL: From franck.vedel at univ-grenoble-alpes.fr Wed Feb 16 18:09:33 2022 From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL) Date: Wed, 16 Feb 2022 19:09:33 +0100 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: <315f6246b9aafc18e1976d7e271848bef5691764.camel@redhat.com> References: <512CF6F4-BC22-486D-B28F-3CD57E2CE479@univ-grenoble-alpes.fr> <315f6246b9aafc18e1976d7e271848bef5691764.camel@redhat.com> Message-ID: <5C18D234-CD88-46A1-BB39-16C36D1CE212@univ-grenoble-alpes.fr> > yes this is logged in the schduler at debug level is it this ? 2022-02-16 10:18:26.802 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.build_failure_weight_multiplier = 1000000.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.802 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.cpu_weight_multiplier = 1.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.802 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.cross_cell_move_weight_multiplier = 1000000.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.802 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.disk_weight_multiplier = 1.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.803 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.io_ops_weight_multiplier = -1.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.804 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.pci_weight_multiplier = 1.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.804 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.ram_weight_multiplier = 1.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.805 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.soft_affinity_weight_multiplier = 1.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.805 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.soft_anti_affinity_weight_multiplier = 1.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.805 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] filter_scheduler.weight_classes = ['nova.scheduler.weights.all_weighers'] log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.806 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] metrics.weight_multiplier = 1.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.806 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] metrics.weight_of_unavailable = -10000.0 log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 2022-02-16 10:18:26.806 8 DEBUG oslo_service.service [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] metrics.weight_setting = [] log_opt_values /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 Franck > Le 16 f?vr. 2022 ? 13:45, Sean Mooney a ?crit : > > On Wed, 2022-02-16 at 10:52 +0100, Franck VEDEL wrote: >> Thank?s a lot ! >> I changed the settings and indeed, it seems to work. This distribution of instances is really interesting. I learn a lot. >> Question: is it possible to view the calculated weight when choosing a server? >> Otherwise, thanks again, really > yes this is logged in the schduler at debug level >> >> Franck >> >>> Le 16 f?vr. 2022 ? 03:35, Tony Liu a ?crit : >>> >>> Build failure could be caused by different things, networking, storage, hypervisor, etc. >>> For example, failure caused by Neutron service, that doesn't mean this hypervisor is >>> not healthy, but because of that weigher, even Neutron service is recovered, this >>> hypervisor is still excluded from holding instance. This doesn't make sense. >>> I wouldn't enable this weigher until it's smart enough to know the failure is caused >>> by hypervisor itself, but not anywhere else. >>> >>> Tony >>> ________________________________________ >>> From: Laurent Dumont >>> Sent: February 15, 2022 05:00 PM >>> To: Tony Liu >>> Cc: Franck VEDEL; openstack-discuss >>> Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers >>> >>> In a healthy setup, should build_failure_weight_multiplier be triggered? >>> >>> From the doc, tweaking this might mean you try to schedule and built instances on computes that are not healthy. >>> >>> On Tue, Feb 15, 2022 at 6:38 PM Tony Liu > wrote: >>> Enable debug logging on nova-scheduler, you will see how the winner is picked. >>> I had the same issue before, caused by the build-failure weigher enabled by default. >>> setting build_failure_weight_multiplier to 0 resolved issue for me. Instances are >>> balanced by weighers (compute and memory) as expected. >>> shuffle_best_same_weighed_hosts and host_subset_size are not necessary, unless >>> it's required by certain cases. >>> >>> Tony >>> ________________________________________ >>> From: Laurent Dumont > >>> Sent: February 15, 2022 12:54 PM >>> To: Franck VEDEL >>> Cc: openstack-discuss >>> Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on servers >>> >>> There are two settings we've tweaked in the past in Nova. >>> >>> shuffle_best_same_weighed_hosts --> Allow more spreading in the case of computes with the exact same specs/weights. >>> host_subset_size --> Helps with concurrent requests to get different hosts >>> >>> Before that, we saw the same behavior with Openstack stacking VM on single computes. It still respects anti-affinity, but I don't see a good reason to not spread as a default. Changing these two was enough to allow our spread to get a little better. >>> >>> On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL >> wrote: >>> Hello, >>> I seem to have a problem that I hadn't seen. >>> I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. >>> I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. >>> >>> The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) >>> [cid:17eff2778356f37a4481] >>> [cid:17eff277835e47aa83c2] >>> [cid:17eff2778356f53d34a3] >>> >>> >>> I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. >>> How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? >>> >>> >>> Thanks in advance if you can help me. >>> >>> Franck VEDEL >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Wed Feb 16 18:38:03 2022 From: smooney at redhat.com (Sean Mooney) Date: Wed, 16 Feb 2022 18:38:03 +0000 Subject: Masquerading VM works 99% In-Reply-To: <1132455927.3695356.1645034661008@mail.yahoo.com> References: <46615849.557895.1644509565653.ref@mail.yahoo.com> <46615849.557895.1644509565653@mail.yahoo.com> <5801622.lOV4Wx5bFT@p1> <1132455927.3695356.1645034661008@mail.yahoo.com> Message-ID: On Wed, 2022-02-16 at 18:04 +0000, Derek O keeffe wrote: > Hi, Laurent, Slawek, > Removing the port security did indeed solve the issue for me so I really appreciate the advice from both of you. > On your point below Slawek:ML2/Linuxbridge don't supports distributed routing (DVR) at all. What do You?mean by "distributed routing" here?" > We have enabled DVR on the nodes in the following locations: > plugins/ml2/ml2_conf.ini:enable_distributed_routing = Trueplugins/ml2/linuxbridge_agent.ini:enable_distributed_routing = Trueneutron.conf:router_distributed = True > > We have obviously been mistaken here, we had assumed this was working as the VM's on each compute can continue working fine if the controller is shut down. Would this be a reason that if we spin up a neutron router the interface is always down and we cannot bring it up? We're a little caught on the networking side of things. > Regards,Derek > linux bridge supprot VRRP HA routering https://docs.openstack.org/neutron/latest/admin/deploy-lb-ha-vrrp.html but ovs syle dvr where each compute node does the routing appears to be unsupported. i tought we added dvr to linux bridge as part of the vlan support in kilo or at least proposed at one point but the docs dont reference it. looking at the agent config https://docs.openstack.org/neutron/latest/configuration/linuxbridge-agent.html that option does not exist "enable_distributed_routing" https://docs.openstack.org/neutron/latest/configuration/neutron.html#DEFAULT.router_distributed https://docs.openstack.org/neutron/latest/configuration/neutron.html#DEFAULT.enable_dvr are generic neuton toplevl option but i think that just sets the default values so they shoudl also not be set in the agent config. dvr is implemented by the l3 agent however and is contold by https://docs.openstack.org/neutron/latest/configuration/l3-agent.html#DEFAULT.agent_mode i had though that if you enable that and deploy the l3 agent on each of the compute nodes with linux bridge it would still work after all the routeing is impleted by the kernel not ovs when usign dvr so the same namepace approch shoudl work. but i guess that was never implemnted so your only otpion with linux bridge would he to use ha routers not dvr routers the main deltaa is for ha routers all routing happnes on the network nodes/contoler where the l3 agent is running rahter then beign distibuted across all compute nodes. > ? On Tuesday 15 February 2022, 09:41:54 GMT, Slawek Kaplonski wrote: > > 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 > > > > 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 > > > From laurentfdumont at gmail.com Wed Feb 16 22:35:34 2022 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Wed, 16 Feb 2022 17:35:34 -0500 Subject: [kolla-ansible][nova]Problem with distribution of instance on servers In-Reply-To: <5C18D234-CD88-46A1-BB39-16C36D1CE212@univ-grenoble-alpes.fr> References: <512CF6F4-BC22-486D-B28F-3CD57E2CE479@univ-grenoble-alpes.fr> <315f6246b9aafc18e1976d7e271848bef5691764.camel@redhat.com> <5C18D234-CD88-46A1-BB39-16C36D1CE212@univ-grenoble-alpes.fr> Message-ID: Could be nice to have that metric exposed inside the API for nova-hypervisors. We scrape those with Prometheus and an exporter so we could have a bit more visibility. On Wed, Feb 16, 2022 at 1:11 PM Franck VEDEL < franck.vedel at univ-grenoble-alpes.fr> wrote: > yes this is logged in the schduler at debug level > > > is it this ? > > 2022-02-16 10:18:26.802 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.build_failure_weight_multiplier = 1000000.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.802 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.cpu_weight_multiplier = 1.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.802 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.cross_cell_move_weight_multiplier = 1000000.0 > log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.802 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.disk_weight_multiplier = 1.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.803 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.io_ops_weight_multiplier = -1.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.804 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.pci_weight_multiplier = 1.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.804 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.ram_weight_multiplier = 1.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.805 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.soft_affinity_weight_multiplier = 1.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.805 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.soft_anti_affinity_weight_multiplier = 1.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.805 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > filter_scheduler.weight_classes = ['nova.scheduler.weights.all_weighers'] > log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.806 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > metrics.weight_multiplier = 1.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.806 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] > metrics.weight_of_unavailable = -10000.0 log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > 2022-02-16 10:18:26.806 8 DEBUG oslo_service.service > [req-629e8eaf-9e0e-471a-b99c-957459b6c9af - - - - -] metrics.weight_setting > = [] log_opt_values > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_config/cfg.py:2611 > > > Franck > > Le 16 f?vr. 2022 ? 13:45, Sean Mooney a ?crit : > > On Wed, 2022-02-16 at 10:52 +0100, Franck VEDEL wrote: > > Thank?s a lot ! > I changed the settings and indeed, it seems to work. This distribution of > instances is really interesting. I learn a lot. > Question: is it possible to view the calculated weight when choosing a > server? > Otherwise, thanks again, really > > yes this is logged in the schduler at debug level > > > Franck > > Le 16 f?vr. 2022 ? 03:35, Tony Liu a ?crit : > > Build failure could be caused by different things, networking, storage, > hypervisor, etc. > For example, failure caused by Neutron service, that doesn't mean this > hypervisor is > not healthy, but because of that weigher, even Neutron service is > recovered, this > hypervisor is still excluded from holding instance. This doesn't make > sense. > I wouldn't enable this weigher until it's smart enough to know the failure > is caused > by hypervisor itself, but not anywhere else. > > Tony > ________________________________________ > From: Laurent Dumont > Sent: February 15, 2022 05:00 PM > To: Tony Liu > Cc: Franck VEDEL; openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on > servers > > In a healthy setup, should build_failure_weight_multiplier be triggered? > > From the doc, tweaking this might mean you try to schedule and built > instances on computes that are not healthy. > > On Tue, Feb 15, 2022 at 6:38 PM Tony Liu mailto:tonyliu0592 at hotmail.com >> wrote: > Enable debug logging on nova-scheduler, you will see how the winner is > picked. > I had the same issue before, caused by the build-failure weigher enabled > by default. > setting build_failure_weight_multiplier to 0 resolved issue for me. > Instances are > balanced by weighers (compute and memory) as expected. > shuffle_best_same_weighed_hosts and host_subset_size are not necessary, > unless > it's required by certain cases. > > Tony > ________________________________________ > From: Laurent Dumont mailto:laurentfdumont at gmail.com >> > Sent: February 15, 2022 12:54 PM > To: Franck VEDEL > Cc: openstack-discuss > Subject: Re: [kolla-ansible][nova]Problem with distribution of instance on > servers > > There are two settings we've tweaked in the past in Nova. > > shuffle_best_same_weighed_hosts --> Allow more spreading in the case of > computes with the exact same specs/weights. > host_subset_size --> Helps with concurrent requests to get different hosts > > Before that, we saw the same behavior with Openstack stacking VM on single > computes. It still respects anti-affinity, but I don't see a good reason to > not spread as a default. Changing these two was enough to allow our spread > to get a little better. > > On Tue, Feb 15, 2022 at 11:19 AM Franck VEDEL < > franck.vedel at univ-grenoble-alpes.fr< > mailto:franck.vedel at univ-grenoble-alpes.fr > >< > mailto:franck.vedel at univ-grenoble-alpes.fr > < > mailto:franck.vedel at univ-grenoble-alpes.fr > >>> wrote: > Hello, > I seem to have a problem that I hadn't seen. > I have 3 servers for my openstack, built with Kolla-ansible, I'm in > Victoria version. > I had simply put the 3 servers in the [compute] part of the multinode > file, at first it worked, but for some time all the VMs are placed on > server 1. > > The 3 servers are operational, identical. here are 3 screenshots to show > it. (on the images, the instances on servers 2 and 3 are present because it > worked correctly, but no more instances are created on these servers now) > [cid:17eff2778356f37a4481] > [cid:17eff277835e47aa83c2] > [cid:17eff2778356f53d34a3] > > > I tried to understand how the instances are distributed on the servers, > but in my case, I don't understand why none are assigned to the 2nd and 3rd > server. > How to find the problem? It should be nova-scheduler . Do you have to do > anything special? Go see if a parameter has a bad value? > > > Thanks in advance if you can help me. > > Franck VEDEL > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Wed Feb 16 23:56:01 2022 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Wed, 16 Feb 2022 15:56:01 -0800 Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud In-Reply-To: References: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com> Message-ID: On Mon, Feb 14, 2022 at 9:40 PM Laurent Dumont wrote: > 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 > > +1. This is a good idea. This will tell us if Nova is at least syncing with Ironic. If it can't push the information to placement, that is obviously going to cause issues. > 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"* >> >> >> So this error is a bit of a generic catch error indicating it just doesn't know how to schedule the node. But the next error you mentioned *is* telling in that a node can't be scheduled if placement is not working. [trim] > 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 >> 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 >> 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) >> >> >> 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/ | jq .inventories >> *null* >> >> result is the same even if we run the curl command on public endpoint. >> >> Please advice. >> >> So this sounds like you have placement either not operating or incorrectly configured somehow. I am not a placement expert, but I don't think a node_id is used for resource providers. Hopefully a placement expert can chime in here. That being said, the note about the service failing to connect to the endpoint for discovery is somewhat telling. You *should* be able to curl the root of the API, without a token, and discover a basic JSON document response with information which is used for API discovery. If that is not working, then there may be several things occuring. I would check to make sure the container(s) running placement are operating, not logging any errors, and responding properly. If they are responding if directly queried, then I wonder if there is something going on with load balancing. Possibly consider connecting to placement's port directly instead of through any sort of load balancing such as what is provided by haproxy. I think placement's log indicates the port it starts on, so that would hopefully help. It's configuration should also share the information as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bxzhu_5355 at 163.com Thu Feb 17 01:59:39 2022 From: bxzhu_5355 at 163.com (Boxiang Zhu) Date: Thu, 17 Feb 2022 09:59:39 +0800 (CST) Subject: =?GBK?Q?=BB=D8=B8=B4:Re:_[kolla-ansible][manila]Perm?= =?GBK?Q?ission_denied_when_using_cephfs_nfs?= In-Reply-To: <20220216134115.Horde.qEmiPZOnsxvbkcw0OCUN8ly@webmail.nde.ag> References: <20220216134115.Horde.qEmiPZOnsxvbkcw0OCUN8ly@webmail.nde.ag> Message-ID: eblock, Thanks for your reply. I have read the report [1] but it can not fix my issue. In our manila-share container, the manila-share service is running by manila user not root user. When I run as root user into manila-share container with command like "docker exec -it -uroot manila_share bash". And then run "python" into interactive model. Then run code as followed: importceph_volume_client share={"share_group_id":None,"id":"449a52a4-f19c-4d1b-b437-7dc2443e040c"} c=ceph_volume_client.CephFSVolumeClient("manila", "/etc/ceph/ceph.conf", "ceph", volume_prefix="/volumes") c.connect(premount_evict="manila") v=c.create_volume(ceph_volume_client.VolumePath(share['share_group_id'], share['id']), size=1073741824, data_isolated=False, mode=int('755',8)) I can succeed to create the volume. But when I run as manila user into manila-share container with command like "docker exec -it manila_share bash". And then run the same python codes, it will raise the same error which appears in the manila-share.log file. [1]: https://bugs.launchpad.net/charm-manila-ganesha/+bug/1901570 Regards Boxiang At 2022-02-16 21:41:15, "Eugen Block" wrote: >This sounds a lot like this bug: >https://bugs.launchpad.net/charm-manila-ganesha/+bug/1901570 > >What are your ceph auth caps for the required pool(s)? I'm not >familiar with Manila or Kolla, but maybe as a workaround you can >change the directory permissions as described in the report. > > >Zitat von Boxiang Zhu : > >> Hi all, >> >> >> I have met an issue when I use manila with cephfs nfs backend. >> >> >> Environment Information: >> - OS: ubuntu 18.04 >> - OpenStack Version: Train >> - Kolla-ansible Version: 9.3.2 >> >> >> I used kolla-ansible to deploy my OpenStack environment AIO. >> >> >> Here is the info of my globals.yml as followed: >> --- >> kolla_base_distro: "ubuntu" >> kolla_install_type: "source" >> openstack_release: "train" >> kolla_internal_vip_address: "172.16.150.67" >> network_interface: "ens3" >> neutron_external_interface: "ens4" >> enable_haproxy: "no" >> enable_ceph: "yes" >> enable_ceph_mds: "yes" >> enable_ceph_rgw: "yes" >> enable_ceph_nfs: "yes" >> enable_cinder: "yes" >> enable_manila: "yes" >> enable_manila_backend_cephfs_nfs: "yes" >> enable_ceph_rgw_keystone: "yes" >> ceph_osd_store_type: "filestore" >> >> >> I try to use cephfs nfs backend for manila. >> All containers are running and the services of manila is good. >> +----+------------------+-------------------+------+---------+-------+----------------------------+ >> | Id | Binary | Host | Zone | Status | State | Updated_at | >> +----+------------------+-------------------+------+---------+-------+----------------------------+ >> | 1 | manila-data | manila | nova | enabled | up | >> 2022-02-16T03:25:34.000000 | >> | 2 | manila-scheduler | manila | nova | enabled | up | >> 2022-02-16T03:25:35.000000 | >> | 3 | manila-share | manila at cephfsnfs1 | nova | enabled | up | >> 2022-02-16T03:25:40.000000 | >> +----+------------------+-------------------+------+---------+-------+----------------------------+ >> >> >> Here is my share type: >> +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ >> | ID | Name | >> visibility | is_default | required_extra_specs | >> optional_extra_specs | Description | >> +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ >> | 265a6637-0322-4c4a-9185-f30f01b96d12 | default_share_type | public >> | - | driver_handles_share_servers : False | >> | None | >> +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ >> >> >> When I create a share, error information appears in manila-share.log file: >> >> >> 2022-02-16 09:30:04.615 20 INFO manila.share.manager >> [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share >> status >> 2022-02-16 09:30:04.616 20 DEBUG manila.share.driver >> [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share >> stats. _update_share_stats >> /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/driver.py:1232 >> 2022-02-16 09:30:54.675 20 DEBUG manila.share.drivers.cephfs.driver >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - >> - -] create_share CEPHFSNFS1 >> name=449a52a4-f19c-4d1b-b437-7dc2443e040c size=1 share_group_id=None >> create_share >> /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py:262 >> 2022-02-16 09:30:54.682 20 INFO ceph_volume_client >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - >> - -] create_volume: >> /volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c2022-02-16 >> 09:30:54.927 20 ERROR manila.share.manager >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - >> - -] Share instance 449a52a4-f19c-4d1b-b437-7dc2443e040c failed on >> creation.: cephfs.OSError: error in mkdir >> volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission >> denied [Errno 13] >> 2022-02-16 09:30:54.929 20 WARNING manila.share.manager >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - >> - -] Share instance information in exception can not be written to >> db because it contains {} and it is not a dictionary.: >> cephfs.OSError: error in mkdir >> volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission >> denied [Errno 13] >> 2022-02-16 09:30:54.955 20 INFO manila.message.api >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - >> - -] Creating message record for request_id = >> req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - >> - -] Exception during message handling: cephfs.OSError: error in >> mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: >> Permission denied [Errno 13] >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback >> (most recent call last): >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 656, in >> _mkdir_p >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> self.fs.stat(subpath) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "cephfs.pyx", line 1257, in cephfs.LibCephFS.stat >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> cephfs.ObjectNotFound: error in stat: >> volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: No such file >> or directory [Errno 2] >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server During >> handling of the above exception, another exception occurred: >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback >> (most recent call last): >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, in >> _process_incoming >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server res = >> self.dispatcher.dispatch(message) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 274, in >> dispatch >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> return self._do_dispatch(endpoint, method, ctxt, args) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in >> _do_dispatch >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> result = func(ctxt, **new_args) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", >> line 187, in wrapped >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> return f(self, *args, **kwargs) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/utils.py", >> line 568, in wrapper >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> return func(self, *args, **kwargs) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", >> line 1790, in create_share_instance >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server exception=e) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", >> line 220, in __exit__ >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> self.force_reraise() >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", >> line 196, in force_reraise >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> six.reraise(self.type_, self.value, self.tb) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/six.py", line 693, >> in reraise >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server raise value >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", >> line 1753, in create_share_instance >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> context, share_instance, share_server=share_server) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py", line 272, in >> create_share >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> mode=self._cephfs_volume_mode) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 677, in >> create_volume >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> self._mkdir_p(path, mode) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 658, in >> _mkdir_p >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> self.fs.mkdir(subpath, mode) >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File >> "cephfs.pyx", line 887, in cephfs.LibCephFS.mkdir >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server >> cephfs.OSError: error in mkdir >> volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission >> denied [Errno 13] >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Feb 17 02:13:36 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 16 Feb 2022 20:13:36 -0600 Subject: [all][tc] Technical Committee next weekly meeting on Feb 17th at 1500 UTC In-Reply-To: <17eff5682c4.bd4b3d9f7304.5686127029797830923@ghanshyammann.com> References: <17eff5682c4.bd4b3d9f7304.5686127029797830923@ghanshyammann.com> Message-ID: <17f0574d3fd.ed09822e94393.4114583483911079739@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 ** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027242.html * Z cycle Technical Elections ** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027311.html *Dropping tags framework - next steps (yoctozepto) * Progress check on Yoga tracker ** https://etherpad.opendev.org/p/tc-yoga-tracker * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Tue, 15 Feb 2022 15:42:46 -0600 Ghanshyam Mann wrote ---- > Hello Everyone, > > Technical Committee's next weekly meeting is scheduled for Feb 17th at 1500 UTC. > > If you would like to add topics for discussion, please add them to the below wiki page by > Wednesday, Feb 16th, at 2100 UTC. > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > -gmann > > From gouthampravi at gmail.com Thu Feb 17 03:41:34 2022 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Wed, 16 Feb 2022 19:41:34 -0800 Subject: [kolla-ansible][manila]Permission denied when using cephfs nfs In-Reply-To: References: <20220216134115.Horde.qEmiPZOnsxvbkcw0OCUN8ly@webmail.nde.ag> Message-ID: Manila interacts with ceph using a ceph client user (this user is called ?manila?by default, but is customizable with config option [1]). It?s likely that user doesn?t have permission to use the data pool that?s assigned to the underlying cephfs file system; can you check these permissions? (called ?caps?) In Train, these are the permissions the ceph client user needs: https://docs.openstack.org/manila/train/admin/cephfs_driver.html#authorizing-the-driver-to-communicate-with-ceph Can you check that these permissions match in your deployment? If they do, check the file permissions for the ceph keyring associated with the user. [1] https://github.com/openstack/manila/blob/191e8c9634d606c16ca0c1882cc01f4eb310d710/manila/share/drivers/cephfs/driver.py#L62 On Wed, Feb 16, 2022 at 6:08 PM Boxiang Zhu wrote: > > eblock, Thanks for your reply. I have read the report [1] but it can not > fix my issue. > > In our manila-share container, the manila-share service is running by > *manila* > *user not root user*. > > When I run as *root user* into manila-share container with command like > "docker exec -it -uroot manila_share bash". And then run "python" into > interactive model. Then run code as followed: > import ceph_volume_client > share={"share_group_id":None,"id":"449a52a4-f19c-4d1b-b437-7dc2443e040c"} > c=ceph_volume_client.CephFSVolumeClient("manila", "/etc/ceph/ceph.conf", > "ceph", volume_prefix="/volumes") > c.connect(premount_evict="manila") > v=c.create_volume(ceph_volume_client.VolumePath(share['share_group_id'], > share['id']), size=1073741824, data_isolated=False, mode=int('755',8)) > I can *succeed *to create the volume. > > But when I run as manila user into manila-share container with command > like "docker exec -it manila_share bash". And then run the same python > codes, it will raise the same error which appears in the manila-share.log > file. > > [1]: https://bugs.launchpad.net/charm-manila-ganesha/+bug/1901570 > > > Regards > > Boxiang > > > At 2022-02-16 21:41:15, "Eugen Block" wrote: > >This sounds a lot like this bug: > >https://bugs.launchpad.net/charm-manila-ganesha/+bug/1901570 > > > >What are your ceph auth caps for the required pool(s)? I'm not > >familiar with Manila or Kolla, but maybe as a workaround you can > >change the directory permissions as described in the report. > > > > > >Zitat von Boxiang Zhu : > > > >> Hi all, > >> > >> > >> I have met an issue when I use manila with cephfs nfs backend. > >> > >> > >> Environment Information: > >> - OS: ubuntu 18.04 > >> - OpenStack Version: Train > >> - Kolla-ansible Version: 9.3.2 > >> > >> > >> I used kolla-ansible to deploy my OpenStack environment AIO. > >> > >> > >> Here is the info of my globals.yml as followed: > >> --- > >> kolla_base_distro: "ubuntu" > >> kolla_install_type: "source" > >> openstack_release: "train" > >> kolla_internal_vip_address: "172.16.150.67" > >> network_interface: "ens3" > >> neutron_external_interface: "ens4" > >> enable_haproxy: "no" > >> enable_ceph: "yes" > >> enable_ceph_mds: "yes" > >> enable_ceph_rgw: "yes" > >> enable_ceph_nfs: "yes" > >> enable_cinder: "yes" > >> enable_manila: "yes" > >> enable_manila_backend_cephfs_nfs: "yes" > >> enable_ceph_rgw_keystone: "yes" > >> ceph_osd_store_type: "filestore" > >> > >> > >> I try to use cephfs nfs backend for manila. > >> All containers are running and the services of manila is good. > >> +----+------------------+-------------------+------+---------+-------+----------------------------+ > >> | Id | Binary | Host | Zone | Status | State | Updated_at | > >> +----+------------------+-------------------+------+---------+-------+----------------------------+ > >> | 1 | manila-data | manila | nova | enabled | up | > >> 2022-02-16T03:25:34.000000 | > >> | 2 | manila-scheduler | manila | nova | enabled | up | > >> 2022-02-16T03:25:35.000000 | > >> | 3 | manila-share | manila at cephfsnfs1 | nova | enabled | up | > >> 2022-02-16T03:25:40.000000 | > >> +----+------------------+-------------------+------+---------+-------+----------------------------+ > >> > >> > >> Here is my share type: > >> +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ > >> | ID | Name | > >> visibility | is_default | required_extra_specs | > >> optional_extra_specs | Description | > >> +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ > >> | 265a6637-0322-4c4a-9185-f30f01b96d12 | default_share_type | public > >> | - | driver_handles_share_servers : False | > >> | None | > >> +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ > >> > >> > >> When I create a share, error information appears in manila-share.log file: > >> > >> > >> 2022-02-16 09:30:04.615 20 INFO manila.share.manager > >> [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share > >> status > >> 2022-02-16 09:30:04.616 20 DEBUG manila.share.driver > >> [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share > >> stats. _update_share_stats > >> /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/driver.py:1232 > >> 2022-02-16 09:30:54.675 20 DEBUG manila.share.drivers.cephfs.driver > >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > >> - -] create_share CEPHFSNFS1 > >> name=449a52a4-f19c-4d1b-b437-7dc2443e040c size=1 share_group_id=None > >> create_share > >> /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py:262 > >> 2022-02-16 09:30:54.682 20 INFO ceph_volume_client > >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > >> - -] create_volume: > >> /volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c2022-02-16 > >> 09:30:54.927 20 ERROR manila.share.manager > >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > >> - -] Share instance 449a52a4-f19c-4d1b-b437-7dc2443e040c failed on > >> creation.: cephfs.OSError: error in mkdir > >> volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission > >> denied [Errno 13] > >> 2022-02-16 09:30:54.929 20 WARNING manila.share.manager > >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > >> - -] Share instance information in exception can not be written to > >> db because it contains {} and it is not a dictionary.: > >> cephfs.OSError: error in mkdir > >> volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission > >> denied [Errno 13] > >> 2022-02-16 09:30:54.955 20 INFO manila.message.api > >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > >> - -] Creating message record for request_id = > >> req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b > >> eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - > >> - -] Exception during message handling: cephfs.OSError: error in > >> mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: > >> Permission denied [Errno 13] > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback > >> (most recent call last): > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 656, in > >> _mkdir_p > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> self.fs.stat(subpath) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "cephfs.pyx", line 1257, in cephfs.LibCephFS.stat > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> cephfs.ObjectNotFound: error in stat: > >> volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: No such file > >> or directory [Errno 2] > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server During > >> handling of the above exception, another exception occurred: > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback > >> (most recent call last): > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, in > >> _process_incoming > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server res = > >> self.dispatcher.dispatch(message) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 274, in > >> dispatch > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> return self._do_dispatch(endpoint, method, ctxt, args) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in > >> _do_dispatch > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> result = func(ctxt, **new_args) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", > >> line 187, in wrapped > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> return f(self, *args, **kwargs) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/utils.py", > >> line 568, in wrapper > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> return func(self, *args, **kwargs) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", > >> line 1790, in create_share_instance > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server exception=e) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >> line 220, in __exit__ > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> self.force_reraise() > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >> line 196, in force_reraise > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> six.reraise(self.type_, self.value, self.tb) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/six.py", line 693, > >> in reraise > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server raise value > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", > >> line 1753, in create_share_instance > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> context, share_instance, share_server=share_server) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py", line 272, in > >> create_share > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> mode=self._cephfs_volume_mode) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 677, in > >> create_volume > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> self._mkdir_p(path, mode) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 658, in > >> _mkdir_p > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> self.fs.mkdir(subpath, mode) > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File > >> "cephfs.pyx", line 887, in cephfs.LibCephFS.mkdir > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > >> cephfs.OSError: error in mkdir > >> volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission > >> denied [Errno 13] > >> 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lokendrarathour at gmail.com Thu Feb 17 05:04:38 2022 From: lokendrarathour at gmail.com (Lokendra Rathour) Date: Thu, 17 Feb 2022 10:34:38 +0530 Subject: [Tripleo] Issue in Baremetal Provisioning from Overcloud In-Reply-To: References: <40296e0d-d28b-fadc-91a0-97946aa52f29@redhat.com> Message-ID: Kudos to every1, with your valuable suggestions and feedback we were able to deploy the baremetal successfully. Few things we considered to make this run possible: - Yes, the openstack hypervisor list is showing details for the added Baremetal Node with the IP allocated from the pool of internalAPI. - That placement related error as was highlighted looks like a bug in Train release but it is not impacting our process. - inclusion of modified serviceNetMap in case of a composable network approach. ( as suggested by Harald) - Using the openstack openSource document as a primary reference . ( as suggest by Julia) - https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/baremetal_overcloud.html - This document focused clearly on the host-aggregate concept and setting baremetal flavor property to be "true". Thanks once again it was really helpful. *Also can you please share some information on this query:* *http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027315.html* Best Regards, Lokendra On Thu, Feb 17, 2022 at 5:26 AM Julia Kreger wrote: > > > On Mon, Feb 14, 2022 at 9:40 PM Laurent Dumont > wrote: > >> 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 >> >> > +1. This is a good idea. This will tell us if Nova is at least syncing > with Ironic. If it can't push the information to placement, that is > obviously going to cause issues. > > >> 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"* >>> >>> >>> > > So this error is a bit of a generic catch error indicating it just doesn't > know how to schedule the node. But the next error you mentioned *is* > telling in that a node can't be scheduled if placement is not working. > > [trim] > > >> 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 >>> 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 >>> 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) >>> >>> >>> 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/ | jq .inventories >>> *null* >>> >>> result is the same even if we run the curl command on public endpoint. >>> >>> Please advice. >>> >>> > So this sounds like you have placement either not operating or incorrectly > configured somehow. I am not a placement expert, but I don't think a > node_id is used for resource providers. > > Hopefully a placement expert can chime in here. That being said, the note > about the service failing to connect to the endpoint for discovery is > somewhat telling. You *should* be able to curl the root of the API, without > a token, and discover a basic JSON document response with information which > is used for API discovery. If that is not working, then there may be > several things occuring. I would check to make sure the container(s) > running placement are operating, not logging any errors, and responding > properly. If they are responding if directly queried, then I wonder if > there is something going on with load balancing. Possibly consider > connecting to placement's port directly instead of through any sort of load > balancing such as what is provided by haproxy. I think placement's log > indicates the port it starts on, so that would hopefully help. It's > configuration should also share the information as well. > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrancoa at redhat.com Thu Feb 17 08:47:18 2022 From: jfrancoa at redhat.com (Jose Luis Franco Arza) Date: Thu, 17 Feb 2022 09:47:18 +0100 Subject: [TripleO] Sergii Golovatiuk for TripleO core reviewer (upgrades-related) In-Reply-To: References: Message-ID: Thank you all for your votes folks! If there are no objections I will proceed to include Sergii in the tripleo-core group. Regards, Jos? Luis On Mon, Feb 14, 2022 at 8:39 PM Brent Eagles wrote: > > +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 > > 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkuchlan at redhat.com Thu Feb 17 13:10:22 2022 From: lkuchlan at redhat.com (Liron Kuchlani) Date: Thu, 17 Feb 2022 15:10:22 +0200 Subject: [Manila] Manila Collaborative Review Session - Thursday, March 10th Message-ID: Hi all, We are planning a Manila collaborative review session on Thursday, March 10th, to walk through the following proposed feature: - Add S-RBAC tests for manila [1] The session will start at 14:30 UTC and continue through the first half of the weekly upstream manila community meeting as needed. We will use an etherpad [2] during the session to capture notes and discussions. Hope you can all join us, [1] https://review.opendev.org/c/openstack/manila-tempest-plugin/+/805938 [2] https://etherpad.opendev.org/p/Manila-S-RBAC-collaborative-review -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcastill at redhat.com Thu Feb 17 14:07:40 2022 From: rcastill at redhat.com (Rafael Castillo) Date: Thu, 17 Feb 2022 07:07:40 -0700 Subject: [TripleO] Gate blocker - ansible version In-Reply-To: References: Message-ID: > We have an issue affecting multiple centos stream 8 gate jobs related > to an ansible version conflict. > > Details: https://bugs.launchpad.net/tripleo/+bug/1961035 > > We are currently deciding on the best course of action for unblocking > this issue. We will post an update once the gate is clear. > > Until then, please hold on rechecking. Update: We have pushed an updated ansible package that fixes this issue. Check/gate jobs should pass now. Thank you! From katonalala at gmail.com Thu Feb 17 17:04:20 2022 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 17 Feb 2022 18:04:20 +0100 Subject: [neutron] Drivers meeting - Friday 18.2.2022 - cancelled Message-ID: Hi Neutron Drivers! As Friday is recharge day for RedHat, and most probably we will not have a quorum for the voting, let's cancel tomorrow's meeting. See You at the meeting next week. Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Thu Feb 17 18:00:33 2022 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 17 Feb 2022 13:00:33 -0500 Subject: [cinder] festival of XS reviews 18 February 2022 Message-ID: Hello Argonauts, Apologies for the lateness of this reminder, but hopefully everyone has already used the handy ICS file [0] to have this event on their personal calendars. The most recent edition of the Cinder Festival of XS Reviews will be held tomorrow (Friday 18 February). who: Everyone! what: The Cinder Festival of XS Reviews when: Friday 18 February 2022 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews See you there! brian [0] http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics From cdilorenzo at gmail.com Thu Feb 17 18:53:03 2022 From: cdilorenzo at gmail.com (Chris DiLorenzo) Date: Thu, 17 Feb 2022 13:53:03 -0500 Subject: [kolla][neutron] VM is getting the wrong IP, can't contact metadata service Message-ID: Hello, I am having a weird issue. I am running openstack Victoria with OVN. Generally, everything is working. I created a VM using a fixed port with an IP of 10.210.64.6. There are no issues with this VM. When I create a new VM, I get this route info: [ 29.363664] cloud-init[564]: ci-info: ++++++++++++++++++++++++++++++++Route IPv4 info++++++++++++++++++++++++++++++++ [ 29.368568] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ [ 29.369945] cloud-init[564]: ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags | [ 29.372441] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ [ 29.376434] cloud-init[564]: ci-info: | 0 | 0.0.0.0 | 10.210.64.1 | 0.0.0.0 | ens3 | UG | [ 29.377820] cloud-init[564]: ci-info: | 1 | 10.210.64.0 | 0.0.0.0 | 255.255.255.192 | ens3 | U | [ 29.380417] cloud-init[564]: ci-info: | 2 | 169.254.169.254 | 10.210.64.6 | 255.255.255.255 | ens3 | UGH | [ 29.384448] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ The IP is set correctly, but you can see I am getting a gateway of 10.210.64.6 for the metadata ser. ice. This is preventing the VM from reaching the service so the SSH key is not being added preventing me from logging in. As far as I can tell, there are no error and every VM I build is getting this .6 IP for this route. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Feb 17 19:00:30 2022 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 17 Feb 2022 14:00:30 -0500 Subject: [kolla][neutron] VM is getting the wrong IP, can't contact metadata service In-Reply-To: References: Message-ID: 10.210.64.6 must be your computer node IP, it will redirect metadata requests to your controller node. 169.254.169.254 is a special IP address for meta services. On Thu, Feb 17, 2022 at 1:55 PM Chris DiLorenzo wrote: > > Hello, > > I am having a weird issue. I am running openstack Victoria with OVN. Generally, everything is working. I created a VM using a fixed port with an IP of 10.210.64.6. There are no issues with this VM. When I create a new VM, I get this route info: > > [ 29.363664] cloud-init[564]: ci-info: ++++++++++++++++++++++++++++++++Route IPv4 info++++++++++++++++++++++++++++++++ > [ 29.368568] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ > [ 29.369945] cloud-init[564]: ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags | > [ 29.372441] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ > [ 29.376434] cloud-init[564]: ci-info: | 0 | 0.0.0.0 | 10.210.64.1 | 0.0.0.0 | ens3 | UG | > [ 29.377820] cloud-init[564]: ci-info: | 1 | 10.210.64.0 | 0.0.0.0 | 255.255.255.192 | ens3 | U | > [ 29.380417] cloud-init[564]: ci-info: | 2 | 169.254.169.254 | 10.210.64.6 | 255.255.255.255 | ens3 | UGH | > [ 29.384448] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ > > The IP is set correctly, but you can see I am getting a gateway of 10.210.64.6 for the metadata ser. ice. This is preventing the VM from reaching the service so the SSH key is not being added preventing me from logging in. As far as I can tell, there are no error and every VM I build is getting this .6 IP for this route. > > Thanks, > Chris > > From satish.txt at gmail.com Thu Feb 17 19:06:22 2022 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 17 Feb 2022 14:06:22 -0500 Subject: [kolla][neutron] VM is getting the wrong IP, can't contact metadata service In-Reply-To: References: Message-ID: Disregard my above email, I didn't see that you created vm using a fixed IP address. When you create a network/subnet during that time OVN creates this special localport IP. In my case its 10.1.1.5 I believe you shouldn't use that IP address for VM. port 0e36e2b1-12d2-4eb2-a9ea-556644a73067 type: localport addresses: ["fa:16:3e:6e:36:f9 10.1.1.5"] On Thu, Feb 17, 2022 at 2:00 PM Satish Patel wrote: > > 10.210.64.6 must be your computer node IP, it will redirect metadata > requests to your controller node. 169.254.169.254 is a special IP > address for meta services. > > On Thu, Feb 17, 2022 at 1:55 PM Chris DiLorenzo wrote: > > > > Hello, > > > > I am having a weird issue. I am running openstack Victoria with OVN. Generally, everything is working. I created a VM using a fixed port with an IP of 10.210.64.6. There are no issues with this VM. When I create a new VM, I get this route info: > > > > [ 29.363664] cloud-init[564]: ci-info: ++++++++++++++++++++++++++++++++Route IPv4 info++++++++++++++++++++++++++++++++ > > [ 29.368568] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ > > [ 29.369945] cloud-init[564]: ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags | > > [ 29.372441] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ > > [ 29.376434] cloud-init[564]: ci-info: | 0 | 0.0.0.0 | 10.210.64.1 | 0.0.0.0 | ens3 | UG | > > [ 29.377820] cloud-init[564]: ci-info: | 1 | 10.210.64.0 | 0.0.0.0 | 255.255.255.192 | ens3 | U | > > [ 29.380417] cloud-init[564]: ci-info: | 2 | 169.254.169.254 | 10.210.64.6 | 255.255.255.255 | ens3 | UGH | > > [ 29.384448] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ > > > > The IP is set correctly, but you can see I am getting a gateway of 10.210.64.6 for the metadata ser. ice. This is preventing the VM from reaching the service so the SSH key is not being added preventing me from logging in. As far as I can tell, there are no error and every VM I build is getting this .6 IP for this route. > > > > Thanks, > > Chris > > > > From lance at osuosl.org Thu Feb 17 19:40:32 2022 From: lance at osuosl.org (Lance Albertson) Date: Thu, 17 Feb 2022 11:40:32 -0800 Subject: [all][elections][ptl][tc][Adjutant][Freezer][Heat][Magnum][Masakari][Monasca][Murano][OpenStack_Charms][Openstack_Chef][Senlin][Skyline][Solum][Trove][Venus][Watcher][Zaqar][Zun][Combined PTL/TC Zed cycle Election Nominations Last Days In-Reply-To: <17eff8a3ff3.d7c839108685.7403613792495141625@ghanshyammann.com> References: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com> <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> <17eff8a3ff3.d7c839108685.7403613792495141625@ghanshyammann.com> Message-ID: Apologies for the delay as I'm behind on my email. I just submitted my candidacy even though I'm a few days late. Thanks- On Tue, Feb 15, 2022 at 2:40 PM Ghanshyam Mann wrote: > Hello Everyone, > > ~1 hr left for nomination close, I am tagging the 17 projects in ML > subject which left with the nomination. > > -gmann > > ---- On Tue, 15 Feb 2022 13:07:36 -0600 Ghanshyam Mann < > gmann at ghanshyammann.com> wrote ---- > > Hello Everyone, > > > > Less than 5 hours left for nomination end and we still need nominations > for 21 projects (Zun and Masakari nomination are there but not passed the > validation): > > > > - Adjutant Freezer Heat Magnum Masakari Monasca Murano OpenStack_Charms > Openstack_Chef Release_Management Requirements Senlin Skyline Solum Swift > Tripleo Trove Venus Watcher Zaqar Zun > > > > If you are maintainer of above projects, please do not delay the > nomination or motivate the one you think should add nomination. > > > > -gmann & The OpenStack Technical Election Officials > > > > ---- On Mon, 14 Feb 2022 18:20:38 -0600 Ghanshyam Mann < > gmann at ghanshyammann.com> wrote ---- > > > 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 > > > > > > > > > > > > > > > -- Lance Albertson Director Oregon State University | Open Source Lab -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Feb 17 19:55:47 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 17 Feb 2022 13:55:47 -0600 Subject: [all][elections][ptl][tc][Adjutant][Freezer][Heat][Magnum][Masakari][Monasca][Murano][OpenStack_Charms][Openstack_Chef][Senlin][Skyline][Solum][Trove][Venus][Watcher][Zaqar][Zun][Combined PTL/TC Zed cycle Election Nominations Last Days In-Reply-To: References: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com> <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> <17eff8a3ff3.d7c839108685.7403613792495141625@ghanshyammann.com> Message-ID: <17f094147e0.f5efb8e7168864.5996896917712641978@ghanshyammann.com> ---- On Thu, 17 Feb 2022 13:40:32 -0600 Lance Albertson wrote ---- > Apologies for the delay as I'm behind on my email. I just submitted my candidacy even though I'm a few days late. Thanks- Thanks, Lance for your nomination. As nomination is closed now, TC will appoint the PTL. I have added your late candidacy in TC etherpad https://etherpad.opendev.org/p/zed-leaderless As the next step, TC will discuss and let you about the appointment. -gmann > On Tue, Feb 15, 2022 at 2:40 PM Ghanshyam Mann wrote: > Hello Everyone, > > ~1 hr left for nomination close, I am tagging the 17 projects in ML subject which left with the nomination. > > -gmann > > ---- On Tue, 15 Feb 2022 13:07:36 -0600 Ghanshyam Mann wrote ---- > > Hello Everyone, > > > > Less than 5 hours left for nomination end and we still need nominations for 21 projects (Zun and Masakari nomination are there but not passed the validation): > > > > - Adjutant Freezer Heat Magnum Masakari Monasca Murano OpenStack_Charms Openstack_Chef Release_Management Requirements Senlin Skyline Solum Swift Tripleo Trove Venus Watcher Zaqar Zun > > > > If you are maintainer of above projects, please do not delay the nomination or motivate the one you think should add nomination. > > > > -gmann & The OpenStack Technical Election Officials > > > > ---- On Mon, 14 Feb 2022 18:20:38 -0600 Ghanshyam Mann wrote ---- > > > 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 > > > > > > > > > > > > > > > > > -- > Lance AlbertsonDirectorOregon State University | Open Source Lab From senrique at redhat.com Thu Feb 17 21:32:35 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Thu, 17 Feb 2022 18:32:35 -0300 Subject: Call for Outreachy OpenStack mentors - May 2022 round In-Reply-To: References: Message-ID: Greetings, Are we going to update https://wiki.openstack.org/wiki/Internship_ideas ? Best Regards, Sofia On Mon, Feb 14, 2022 at 1:18 PM Mahati Chamarthy wrote: > 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 or Dmitry > Tantsur > > Best, > Mahati > -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Thu Feb 17 21:32:35 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Thu, 17 Feb 2022 18:32:35 -0300 Subject: Call for Outreachy OpenStack mentors - May 2022 round In-Reply-To: References: Message-ID: Greetings, Are we going to update https://wiki.openstack.org/wiki/Internship_ideas ? Best Regards, Sofia On Mon, Feb 14, 2022 at 1:18 PM Mahati Chamarthy wrote: > 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 or Dmitry > Tantsur > > Best, > Mahati > -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Thu Feb 17 21:32:35 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Thu, 17 Feb 2022 18:32:35 -0300 Subject: Call for Outreachy OpenStack mentors - May 2022 round In-Reply-To: References: Message-ID: Greetings, Are we going to update https://wiki.openstack.org/wiki/Internship_ideas ? Best Regards, Sofia On Mon, Feb 14, 2022 at 1:18 PM Mahati Chamarthy wrote: > 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 or Dmitry > Tantsur > > Best, > Mahati > -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From derekokeeffe85 at yahoo.ie Thu Feb 17 22:01:35 2022 From: derekokeeffe85 at yahoo.ie (Derek O keeffe) Date: Thu, 17 Feb 2022 22:01:35 +0000 Subject: Masquerading VM works 99% In-Reply-To: References: Message-ID: <937AA58E-2090-4CC7-A12B-E89E69CC0BA5@yahoo.ie> Hi Sean, Thank you for those comments. When I get a chance to get through all the links I will let you know what we find. Regards, Derek > On 16 Feb 2022, at 18:40, Sean Mooney wrote: > > ?On Wed, 2022-02-16 at 18:04 +0000, Derek O keeffe wrote: >> Hi, Laurent, Slawek, >> Removing the port security did indeed solve the issue for me so I really appreciate the advice from both of you. >> On your point below Slawek:ML2/Linuxbridge don't supports distributed routing (DVR) at all. What do You mean by "distributed routing" here?" >> We have enabled DVR on the nodes in the following locations: >> plugins/ml2/ml2_conf.ini:enable_distributed_routing = Trueplugins/ml2/linuxbridge_agent.ini:enable_distributed_routing = Trueneutron.conf:router_distributed = True >> >> We have obviously been mistaken here, we had assumed this was working as the VM's on each compute can continue working fine if the controller is shut down. Would this be a reason that if we spin up a neutron router the interface is always down and we cannot bring it up? We're a little caught on the networking side of things. >> Regards,Derek >> > > linux bridge supprot VRRP HA routering > https://docs.openstack.org/neutron/latest/admin/deploy-lb-ha-vrrp.html > but ovs syle dvr where each compute node does the routing appears to be unsupported. > > i tought we added dvr to linux bridge as part of the vlan support in kilo > or at least proposed at one point but the docs dont reference it. > > looking at the agent config > https://docs.openstack.org/neutron/latest/configuration/linuxbridge-agent.html > that option does not exist "enable_distributed_routing" > > https://docs.openstack.org/neutron/latest/configuration/neutron.html#DEFAULT.router_distributed > https://docs.openstack.org/neutron/latest/configuration/neutron.html#DEFAULT.enable_dvr > are generic neuton toplevl option but i think that just sets the default values so they shoudl also not be set in the agent config. > > dvr is implemented by the l3 agent however and is contold by > https://docs.openstack.org/neutron/latest/configuration/l3-agent.html#DEFAULT.agent_mode > > i had though that if you enable that and deploy the l3 agent on each of the compute nodes with linux bridge > it would still work after all the routeing is impleted by the kernel not ovs when usign dvr so the same namepace approch shoudl work. > but i guess that was never implemnted so your only otpion with linux bridge would he to use ha routers not dvr routers > > the main deltaa is for ha routers all routing happnes on the network nodes/contoler where the l3 agent is running rahter then > beign distibuted across all compute nodes. > > > > >> On Tuesday 15 February 2022, 09:41:54 GMT, Slawek Kaplonski wrote: >> >> 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 >>> >>> 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 >> >> >> > From elod.illes at est.tech Fri Feb 18 15:42:55 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Fri, 18 Feb 2022 16:42:55 +0100 Subject: [release] Release countdown for week R-5, Feb 21-25 Message-ID: <62a290c8-0f09-1924-7b71-b904249d2b10@est.tech> Development Focus ----------------- We are getting close to the end of the Yogacycle! Next week on February 24th, 2022is the Yoga-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the Zedcycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on February 24th, 2022. Only bugfix 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 February 24th, 2022is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also the deadline for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights for more details. Upcoming Deadlines & Dates -------------------------- Yoga-3 milestone (feature freeze): February 24th, 2022(R-5 week) RC1 deadline: March 10th, 2022(R-3 week) Final RC deadline: March 24th, 2022(R-1 week) Final Yogarelease: March 30th, 2022 Next PTG: April 4 - 8, 2022 (virtual) El?dIll?s irc: elodilles -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Fri Feb 18 16:42:22 2022 From: zigo at debian.org (Thomas Goirand) Date: Fri, 18 Feb 2022 17:42:22 +0100 Subject: [all] [requirements] Artificially inflated requirements in os-brick Message-ID: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> Hi, I've been quite surprised to see $topic. Most requirements for os-brick are now to be found in Yoga only. I've asked why, and I've been told that the reason is because "we've been testing with the new versions only for the number of months". Well, the reason why someone would increase a minimum requirement *must* be only because of the need of a new feature, and should be treated with care. Otherwise, this makes upgrading very dangerous and annoying to do. As much as possible, I would strongly recommend that any dependency in Stable can be found in Stable-1 (only when a new feature is mandatory, then it's ok-ish to require that new version, though I would advocate for a possible fallback if that's not too complex to write). Now, if that's the path we're taking, all is going backward 5 years ago, and then my thinking is: we must reintroduce lower-constraints testing ASAP. Your thoughts everyone? Cheers, Thomas Goirand (zigo) P.S: Please note that this is absolutely not about os-brick, I'm not pointing my finger to any team, it's a global thinking for the whole OpenStack project. From rosmaita.fossdev at gmail.com Fri Feb 18 17:33:18 2022 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Fri, 18 Feb 2022 12:33:18 -0500 Subject: [all] [requirements] Artificially inflated requirements in os-brick In-Reply-To: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> Message-ID: On 2/18/22 11:42 AM, Thomas Goirand wrote: > Hi, > > I've been quite surprised to see $topic. Most requirements for os-brick > are now to be found in Yoga only. I've asked why, and I've been told > that the reason is because "we've been testing with the new versions > only for the number of months". > > Well, the reason why someone would increase a minimum requirement *must* > be only because of the need of a new feature, and should be treated with > care. Otherwise, this makes upgrading very dangerous and annoying to do. > As much as possible, I would strongly recommend that any dependency in > Stable can be found in Stable-1 (only when a new feature is mandatory, > then it's ok-ish to require that new version, though I would advocate > for a possible fallback if that's not too complex to write). > > Now, if that's the path we're taking, all is going backward 5 years ago, > and then my thinking is: we must reintroduce lower-constraints testing > ASAP. > > Your thoughts everyone? It would be nice to have clear guidance on this. I tried to get pre-release comments about what I planned to do with os-brick, but maybe I didn't allow enough time or had an unclear subject line: http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html My concern about keeping the minima low is that what we're actually testing with in the gate is pretty much whatever's in upper constraints. The previous lower-constraint job basically just checked to see if you could co-install the minimum versions of dependencies and run pass unit tests within a single project, which doesn't seem very realistic. In any case, it would be better to have an openstack-wide policy so we can raise minima in a coordinated way, rather than me forcing everyone who uses os-brick to do whatever I do. > > Cheers, > > Thomas Goirand (zigo) > > P.S: Please note that this is absolutely not about os-brick, I'm not > pointing my finger to any team, it's a global thinking for the whole > OpenStack project. > From gmann at ghanshyammann.com Fri Feb 18 22:30:37 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 18 Feb 2022 16:30:37 -0600 Subject: [all][tc] What's happening in Technical Committee: summary 18th Feb, 21: Reading: 5 min Message-ID: <17f0ef5652b.d5348595244949.511299613153820019@ghanshyammann.com> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on 17th. 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-17-15.00.log.html * Next week's meeting is on 24th Feb Thursday 15:00 UTC, feel free to add the topic on the agenda[1] by 23rd Feb. 2. What we completed this week: ========================= * Z cycle release name [2] 3. Activities In progress: ================== TC Tracker for Yoga cycle ------------------------------ * This etherpad includes the Yoga cycle targets/working items for TC[3]. 2 out of 9 items are completed. Open Reviews ----------------- * Six open reviews for ongoing activities[4]. Release identification and release name ----------------------------------------------- As Zed is the last release for the current alphabet release name iteration. TC discussed the future release name ideas. Belmiro has proposed the idea of adding "." number to each release. The proposal is up for review[5] Switch Keystone back to PTL model ------------------------------------------- Keystone team proposed to move Keystone from DPL to PTL model[6] with Douglas Mendiz?bal as PTL. Dropping tags framework ------------------------------ yoctozepto has updated part1 of dropping the tag framework[7] which is ready for review. Elod us updating the release scripts to remove the tag ref. Z release cycle Technical Election --------------------------------------- The nomination for PTL and TC elections is closed and there is no voting required. TC Campaigning period is open until 22nd Feb[8]. We will be closing the election on 22nd Feb. There are total 17 projects that missed the nomination, I have created the etherpad to work on the leaderless projects[9]. There is already late candidacy for 8 projects and 9 projects still need leaders. Please add your name if you would like to lead those projects. TC position on release cadence ------------------------------------- No other updates from last week, Dan's proposal is under review[10]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[11]. Project updates ------------------- * Retire js-openstack-lib (waiting on Adjutant to have new PTL/maintainer) [12] 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[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027242.html [3] https://etherpad.opendev.org/p/tc-yoga-tracker [4] https://review.opendev.org/q/projects:openstack/governance+status:open [5] https://review.opendev.org/c/openstack/governance/+/829563 [6] https://review.opendev.org/c/openstack/governance/+/829037 [7] https://review.opendev.org/c/openstack/governance/+/822900 [8] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027311.html [9] https://etherpad.opendev.org/p/zed-leaderless [10] https://review.opendev.org/c/openstack/governance/+/828777 [11] https://etherpad.opendev.org/p/zuul-config-error-openstack [12] https://review.opendev.org/c/openstack/governance/+/798540 [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann From radoslaw.piliszek at gmail.com Sun Feb 20 18:24:17 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Sun, 20 Feb 2022 19:24:17 +0100 Subject: [tc][release] Removing TC tags framework - next steps for release notes In-Reply-To: References: Message-ID: I have proposed https://review.opendev.org/c/openstack/releases/+/830084 to remove the remaining dependent bits. -yoctozepto On Tue, 15 Feb 2022 at 09:07, Rados?aw Piliszek wrote: > > 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 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 syedammad83 at gmail.com Mon Feb 21 07:24:19 2022 From: syedammad83 at gmail.com (Ammad Syed) Date: Mon, 21 Feb 2022 12:24:19 +0500 Subject: [nova] OOM Killed Processes Message-ID: Hi,, I am having trouble with my compute node that nova-compute and ovs process are being killed by OOM. I have alot memory available in system. # free -g total used free shared buff/cache available Mem: 1006 121 881 0 2 879 Swap: 7 0 7 But I am seeing process are being killed in dmesg. [Sat Feb 19 03:46:26 2022] Memory cgroup out of memory: Killed process 2080898 (ovs-vswitchd) total-vm:9474284kB, anon-rss:1076384kB, file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2776kB oom_score_adj:0 [Sat Feb 19 03:47:01 2022] Memory cgroup out of memory: Killed process 2081218 (ovs-vswitchd) total-vm:9475332kB, anon-rss:1096988kB, file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2780kB oom_score_adj:0 [Sat Feb 19 03:47:06 2022] Memory cgroup out of memory: Killed process 2081616 (ovs-vswitchd) total-vm:9473252kB, anon-rss:1073052kB, file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2784kB oom_score_adj:0 [Sat Feb 19 03:47:16 2022] Memory cgroup out of memory: Killed process 2081940 (ovs-vswitchd) total-vm:9471236kB, anon-rss:1070920kB, file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2776kB oom_score_adj:0 [Sat Feb 19 03:47:16 2022] Memory cgroup out of memory: Killed process 6098 (nova-compute) total-vm:3428356kB, anon-rss:279920kB, file-rss:9868kB, shmem-rss:0kB, UID:64060 pgtables:1020kB oom_score_adj:0 [Mon Feb 21 11:15:08 2022] Memory cgroup out of memory: Killed process 2082296 (ovs-vswitchd) total-vm:9475372kB, anon-rss:1162636kB, file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2864kB oom_score_adj:0 Any advice on how to fix this ? Also any best practices document on configuring memory optimizations in nova compute node. Ammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralonsoh at redhat.com Mon Feb 21 11:49:31 2022 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Mon, 21 Feb 2022 12:49:31 +0100 Subject: [kolla][neutron] VM is getting the wrong IP, can't contact metadata service In-Reply-To: References: Message-ID: Hello Chris: 10.210.65.6 is the IP address of the metadata namespace interface. The metadata service is on 169.254.169.254 address; this route is redirecting this traffic. Check the network ID and then the corresponding metadata: root at u20ovn:~# ip netns ovnmeta-5274fa45-c33a-4c66-be3a-b8ecd294c769 (id: 3) ovnmeta-ee1597ee-579d-49dc-9b90-fbb8f98baef9 (id: 2) root at u20ovn:~# ip netns exec $meta ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: tap5274fa45-c1 at if62: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether fa:16:3e:dd:2b:2c brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.0.10.3/26 brd 10.0.10.63 scope global tap5274fa45-c1 valid_lft forever preferred_lft forever inet 169.254.169.254/32 brd 169.254.169.254 scope global tap5274fa45-c1 Check if the metadata agent logs and verify you are not hitting [1]. Check you have [2]. Regards. [1]https://bugs.launchpad.net/neutron/+bug/1952550 [2]https://review.opendev.org/c/openstack/neutron/+/822669 On Thu, Feb 17, 2022 at 8:14 PM Satish Patel wrote: > Disregard my above email, I didn't see that you created vm using a > fixed IP address. When you create a network/subnet during that time > OVN creates this special localport IP. In my case its 10.1.1.5 > > I believe you shouldn't use that IP address for VM. > > port 0e36e2b1-12d2-4eb2-a9ea-556644a73067 > type: localport > addresses: ["fa:16:3e:6e:36:f9 10.1.1.5"] > > On Thu, Feb 17, 2022 at 2:00 PM Satish Patel wrote: > > > > 10.210.64.6 must be your computer node IP, it will redirect metadata > > requests to your controller node. 169.254.169.254 is a special IP > > address for meta services. > > > > On Thu, Feb 17, 2022 at 1:55 PM Chris DiLorenzo > wrote: > > > > > > Hello, > > > > > > I am having a weird issue. I am running openstack Victoria with OVN. > Generally, everything is working. I created a VM using a fixed port with > an IP of 10.210.64.6. There are no issues with this VM. When I create a > new VM, I get this route info: > > > > > > [ 29.363664] cloud-init[564]: ci-info: > ++++++++++++++++++++++++++++++++Route IPv4 > info++++++++++++++++++++++++++++++++ > > > [ 29.368568] cloud-init[564]: ci-info: > +-------+-----------------+-------------+-----------------+-----------+-------+ > > > [ 29.369945] cloud-init[564]: ci-info: | Route | Destination | > Gateway | Genmask | Interface | Flags | > > > [ 29.372441] cloud-init[564]: ci-info: > +-------+-----------------+-------------+-----------------+-----------+-------+ > > > [ 29.376434] cloud-init[564]: ci-info: | 0 | 0.0.0.0 | > 10.210.64.1 | 0.0.0.0 | ens3 | UG | > > > [ 29.377820] cloud-init[564]: ci-info: | 1 | 10.210.64.0 | > 0.0.0.0 | 255.255.255.192 | ens3 | U | > > > [ 29.380417] cloud-init[564]: ci-info: | 2 | 169.254.169.254 | > 10.210.64.6 | 255.255.255.255 | ens3 | UGH | > > > [ 29.384448] cloud-init[564]: ci-info: > +-------+-----------------+-------------+-----------------+-----------+-------+ > > > > > > The IP is set correctly, but you can see I am getting a gateway of > 10.210.64.6 for the metadata ser. ice. This is preventing the VM from > reaching the service so the SSH key is not being added preventing me from > logging in. As far as I can tell, there are no error and every VM I build > is getting this .6 IP for this route. > > > > > > Thanks, > > > Chris > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Mon Feb 21 13:10:28 2022 From: zigo at debian.org (Thomas Goirand) Date: Mon, 21 Feb 2022 14:10:28 +0100 Subject: [all] [requirements] Artificially inflated requirements in os-brick In-Reply-To: References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> Message-ID: <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> On 2/18/22 18:33, Brian Rosmaita wrote: > On 2/18/22 11:42 AM, Thomas Goirand wrote: >> Hi, >> >> I've been quite surprised to see $topic. Most requirements for >> os-brick are now to be found in Yoga only. I've asked why, and I've >> been told that the reason is because "we've been testing with the new >> versions only for the number of months". >> >> Well, the reason why someone would increase a minimum requirement >> *must* be only because of the need of a new feature, and should be >> treated with care. Otherwise, this makes upgrading very dangerous and >> annoying to do. As much as possible, I would strongly recommend that >> any dependency in Stable can be found in Stable-1 (only when a new >> feature is mandatory, then it's ok-ish to require that new version, >> though I would advocate for a possible fallback if that's not too >> complex to write). >> >> Now, if that's the path we're taking, all is going backward 5 years >> ago, and then my thinking is: we must reintroduce lower-constraints >> testing ASAP. >> >> Your thoughts everyone? > > It would be nice to have clear guidance on this.? I tried to get > pre-release comments about what I planned to do with os-brick, but maybe > I didn't allow enough time or had an unclear subject line: > > http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html I saw the message, but reading it, it wasn't clear enough what the intention was, and TBH, I probably read the patch too quickly. > My concern about keeping the minima low is that what we're actually > testing with in the gate is pretty much whatever's in upper constraints. > The previous lower-constraint job basically just checked to see if you > could co-install the minimum versions of dependencies and run pass unit > tests within a single project, which doesn't seem very realistic. It was catching API / ABI breakage, which was the intention. > In any case, it would be better to have an openstack-wide policy so we > can raise minima in a coordinated way, rather than me forcing everyone > who uses os-brick to do whatever I do. That's what the global-requirements were supposed to be about, however, as far as the CI is concerned, now only the upper-constraints.txt are in use, resulting in now useless requirements.txt. I very much see a huge regression here, compared to what we had maybe 2 years ago. Indeed, we need to have a (more) global thinking OpenStack wide about what we should do. I still believe that all project should be able as much as possible to run with all the requirements from stable -1, to ease upgrading. This way, it's possible to: 1/ upgrade all services without updating the libs 2/ then upgrade the libs 3/ and finally restart all services. without troubles with co-existing services. Requiring a lib from the current release means that potentially, during the upgrade, an older service may run with a library from oldstable+1, which that service doesn't know about (yet). If that's not always possible, it's of course IMO ok to allow exceptions, if they are under control, and if we make sure there's no backward breakage (which can only be checked manually). Cheers, Thomas Goirand (zigo) From smooney at redhat.com Mon Feb 21 13:21:12 2022 From: smooney at redhat.com (Sean Mooney) Date: Mon, 21 Feb 2022 13:21:12 +0000 Subject: [nova] OOM Killed Processes In-Reply-To: References: Message-ID: <8cac2ca15914bc2be6373ea708c40d64bb6d85ce.camel@redhat.com> On Mon, 2022-02-21 at 12:24 +0500, Ammad Syed wrote: > Hi,, > > I am having trouble with my compute node that nova-compute and ovs process > are being killed by OOM. I have alot memory available in system. > > # free -g > total used free shared buff/cache > available > Mem: 1006 121 881 0 2 > 879 > Swap: 7 0 7 > > But I am seeing process are being killed in dmesg. > > [Sat Feb 19 03:46:26 2022] Memory cgroup out of memory: Killed process > 2080898 (ovs-vswitchd) total-vm:9474284kB, anon-rss:1076384kB, > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2776kB oom_score_adj:0 > [Sat Feb 19 03:47:01 2022] Memory cgroup out of memory: Killed process > 2081218 (ovs-vswitchd) total-vm:9475332kB, anon-rss:1096988kB, > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2780kB oom_score_adj:0 > [Sat Feb 19 03:47:06 2022] Memory cgroup out of memory: Killed process > 2081616 (ovs-vswitchd) total-vm:9473252kB, anon-rss:1073052kB, > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2784kB oom_score_adj:0 > [Sat Feb 19 03:47:16 2022] Memory cgroup out of memory: Killed process > 2081940 (ovs-vswitchd) total-vm:9471236kB, anon-rss:1070920kB, > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2776kB oom_score_adj:0 > [Sat Feb 19 03:47:16 2022] Memory cgroup out of memory: Killed process 6098 > (nova-compute) total-vm:3428356kB, anon-rss:279920kB, file-rss:9868kB, > shmem-rss:0kB, UID:64060 pgtables:1020kB oom_score_adj:0 > [Mon Feb 21 11:15:08 2022] Memory cgroup out of memory: Killed process > 2082296 (ovs-vswitchd) total-vm:9475372kB, anon-rss:1162636kB, > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2864kB oom_score_adj:0 > > Any advice on how to fix this ? Also any best practices document on > configuring memory optimizations in nova compute node. so one thing to note is that the OOM reaper service runs per numa node so the gloable free memory values are not really what you need to look at. croups/systemd also provide ways to limit the max memory a process/cgroup tree can consume so your first stp shoudl be to determin if the oom event was triggered by exaustign the memroy in a specific numa node or if you are hitting a differnt cgroup memory limit. in terms fo how to optimisze memroy it really depend on what your end goal is here. obviously we do not want ovs or nova-compute to be killsed in general. the virtaul and reseden memory for ovs is in the 10 to 1 GB range so that is not excessively large. that also should not be anywhere near the numa limit but if you were incorrectly creating numa affinged vms without seting hw:mem_page_size via nova then that could perhaps tirgger out of memory events effectivly with openenstack if your vm is numa affined eiter explictly via hw:numa_nodes extra specs or implictly via cpu pinning or otherwise then you must define that the memory is tracked using the numa aware path which requires you do defien hw:mem_page_size in the flaovr or hw_mem_page_size in the image. if you do not want ot use hugepages hw:mem_page_size=small is a good default but just be aware that if the vm has a numa topology then memory over subsction is not supproted in openstack. i.e. you cannot use cpu pinning or any other feature that requriees a numa topoplogy like virtual persistent memory and also use memory over subscription. assuming these event do not corralate with vm boots then i woudl investiagte the cgroup memory limits you set on teh ovs and compute service cgroups. if they are correatlted with vm boots check if the vm is numa affined and if it is which page size is requested. ir its hw:mem_page_size=small then you might need to use the badly named reserved_huge_pages config option to reserve 4k pages for the host per numa node. https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_huge_pages e.g. reserve 4G on node 0 and 1 reserved_huge_pages = node:0,size:4,count:1048576 reserved_huge_pages = node:1,size:4,count:1048576 the sum of all the 4k page size reservation should equal the value of reserved_host_memory_mb https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_memory_mb this is only really needed where you are usign numa instances since reserved_host_memory_mb dose not account for the host numa toplogy so it will not prevent the numa node form being exausted. if you are usign a amd epyc system and the NPS( numa per socket) bios option set to say 4 or 8 on a dual or single socket system respecivly then the the 1TB of ram you have on the host woudl be devided into numa nodes of 128GB each which is very close to the 121 used you have when you star seeing issues. nova currently tries to fill the numa nodes in order when you have numa instances too which causes the OOM issue to manifest much sooner then people often exepct due to the per numa nature of OOM reaper. that may not help you in your case but that is how i would approch tracking down this issue. > > Ammad From skaplons at redhat.com Mon Feb 21 13:24:42 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 21 Feb 2022 14:24:42 +0100 Subject: [neutron] Bug deputy - week of 14.02.2022 Message-ID: <12959107.uLZWGnKmhe@p1> Hi, I was bug deputy last week. It was very quiet week in terms of bugs in Neutron. Here is the summary: ## Critical https://bugs.launchpad.net/neutron/+bug/1961112 - [ovn] overlapping security group rules break neutron-ovn-db-sync-util - fix already proposed long time ago: https://review.opendev.org/c/openstack/neutron/+/801707, ## High https://bugs.launchpad.net/neutron/+bug/1961173 - [fullstack] test_vm_is_accessible_by_local_ip fails sometimes - assigned to Oleg, fix proposed alreadh https://review.opendev.org/c/openstack/neutron/+/829659 ## Medium https://bugs.launchpad.net/neutron/+bug/1961013 - [stable][ovn] frequent OVN DB leader changes increase rate of Neutron API errors - assigned to Frode, it's about backport feature from master to stable branches, ## Low https://bugs.launchpad.net/neutron/+bug/1961184 - [OVN] Virtual ports are always DOWN - assigned to Rodolfo, ## Whishlist (RFEs) https://bugs.launchpad.net/neutron/+bug/1960850 - [RFE][OVN] Support DNS subdomains at a network level - I think it's properly described and needs to be discussed during the drivers meeting now, https://bugs.launchpad.net/neutron/+bug/1961011 - [RFE][L3][OVS] use controller (ovs-agent) send (packet-out) RA to (VMs) ports - I think it's properly described and needs to be discussed during the drivers meeting now, -- 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: From smooney at redhat.com Mon Feb 21 13:27:07 2022 From: smooney at redhat.com (Sean Mooney) Date: Mon, 21 Feb 2022 13:27:07 +0000 Subject: [all] [requirements] Artificially inflated requirements in os-brick In-Reply-To: <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> Message-ID: <3f06828a40cd6a473b06246aea214d040c15cc37.camel@redhat.com> On Mon, 2022-02-21 at 14:10 +0100, Thomas Goirand wrote: > On 2/18/22 18:33, Brian Rosmaita wrote: > > On 2/18/22 11:42 AM, Thomas Goirand wrote: > > > Hi, > > > > > > I've been quite surprised to see $topic. Most requirements for > > > os-brick are now to be found in Yoga only. I've asked why, and I've > > > been told that the reason is because "we've been testing with the new > > > versions only for the number of months". > > > > > > Well, the reason why someone would increase a minimum requirement > > > *must* be only because of the need of a new feature, and should be > > > treated with care. Otherwise, this makes upgrading very dangerous and > > > annoying to do. As much as possible, I would strongly recommend that > > > any dependency in Stable can be found in Stable-1 (only when a new > > > feature is mandatory, then it's ok-ish to require that new version, > > > though I would advocate for a possible fallback if that's not too > > > complex to write). > > > > > > Now, if that's the path we're taking, all is going backward 5 years > > > ago, and then my thinking is: we must reintroduce lower-constraints > > > testing ASAP. > > > > > > Your thoughts everyone? > > > > It would be nice to have clear guidance on this.? I tried to get > > pre-release comments about what I planned to do with os-brick, but maybe > > I didn't allow enough time or had an unclear subject line: > > > > http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html > > I saw the message, but reading it, it wasn't clear enough what the > intention was, and TBH, I probably read the patch too quickly. > > > My concern about keeping the minima low is that what we're actually > > testing with in the gate is pretty much whatever's in upper constraints. > > The previous lower-constraint job basically just checked to see if you > > could co-install the minimum versions of dependencies and run pass unit > > tests within a single project, which doesn't seem very realistic. > > It was catching API / ABI breakage, which was the intention. > > > In any case, it would be better to have an openstack-wide policy so we > > can raise minima in a coordinated way, rather than me forcing everyone > > who uses os-brick to do whatever I do. > > That's what the global-requirements were supposed to be about, however, > as far as the CI is concerned, now only the upper-constraints.txt are in > use, resulting in now useless requirements.txt. > > I very much see a huge regression here, compared to what we had maybe 2 > years ago. > > Indeed, we need to have a (more) global thinking OpenStack wide about > what we should do. I still believe that all project should be able as > much as possible to run with all the requirements from stable -1, to > ease upgrading. This way, it's possible to: > 1/ upgrade all services without updating the libs > 2/ then upgrade the libs > 3/ and finally restart all services. much of the feature development actully assume you upgade the libs first then upgrade the service then restart it. doign the libs second make the code in the consuming porject much more difficult to write as we need to have fallbacks but upgrading the libs outside of a breaking major version should not break exisign users. supporting the version of n-1 libs might be worth considering instaed of our older lower constraits aproch but im really not sure we shoudl expect the service in general to be upgraded first. i can kind of see why you woudl like that but that woudl increase the burden on client which i dont think we want to do. > > without troubles with co-existing services. Requiring a lib from the > current release means that potentially, during the upgrade, an older > service may run with a library from oldstable+1, which that service > doesn't know about (yet). If that's not always possible, it's of course > IMO ok to allow exceptions, if they are under control, and if we make > sure there's no backward breakage (which can only be checked manually). > > Cheers, > > Thomas Goirand (zigo) > From bxzhu_5355 at 163.com Mon Feb 21 13:30:13 2022 From: bxzhu_5355 at 163.com (Boxiang Zhu) Date: Mon, 21 Feb 2022 21:30:13 +0800 (CST) Subject: [kolla-ansible][manila]Permission denied when using cephfs nfs In-Reply-To: References: <20220216134115.Horde.qEmiPZOnsxvbkcw0OCUN8ly@webmail.nde.ag> Message-ID: <5313fe60.5ea9.17f1c79b890.Coremail.bxzhu_5355@163.com> Hi gouthampravi, Thanks for your reply. I have recheck the issue[1][2] and I found some commands. I run commands as followed: - docker exec -it -uroot manila_share bash - mount -t ceph 172.20.0.33:6789:/ /mnt -o name=manila,secret= - chown 42429:42429 /mnt/ - umount /mnt/ At last, it resolved my issue. [1]: https://bugs.launchpad.net/charm-manila-ganesha/+bug/1901570 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1639823 Regards Boxiang At 2022-02-17 11:41:34,"Goutham Pacha Ravi" , said: Manila interacts with ceph using a ceph client user (this user is called ?manila?by default, but is customizable with config option [1]). It?s likely that user doesn?t have permission to use the data pool that?s assigned to the underlying cephfs file system; can you check these permissions? (called ?caps?) In Train, these are the permissions the ceph client user needs: https://docs.openstack.org/manila/train/admin/cephfs_driver.html#authorizing-the-driver-to-communicate-with-ceph Can you check that these permissions match in your deployment? If they do, check the file permissions for the ceph keyring associated with the user. [1] https://github.com/openstack/manila/blob/191e8c9634d606c16ca0c1882cc01f4eb310d710/manila/share/drivers/cephfs/driver.py#L62 -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Mon Feb 21 13:32:12 2022 From: smooney at redhat.com (Sean Mooney) Date: Mon, 21 Feb 2022 13:32:12 +0000 Subject: [all] [requirements] Artificially inflated requirements in os-brick In-Reply-To: <3f06828a40cd6a473b06246aea214d040c15cc37.camel@redhat.com> References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> <3f06828a40cd6a473b06246aea214d040c15cc37.camel@redhat.com> Message-ID: On Mon, 2022-02-21 at 13:27 +0000, Sean Mooney wrote: > On Mon, 2022-02-21 at 14:10 +0100, Thomas Goirand wrote: > > On 2/18/22 18:33, Brian Rosmaita wrote: > > > On 2/18/22 11:42 AM, Thomas Goirand wrote: > > > > Hi, > > > > > > > > I've been quite surprised to see $topic. Most requirements for > > > > os-brick are now to be found in Yoga only. I've asked why, and I've > > > > been told that the reason is because "we've been testing with the new > > > > versions only for the number of months". > > > > > > > > Well, the reason why someone would increase a minimum requirement > > > > *must* be only because of the need of a new feature, and should be > > > > treated with care. Otherwise, this makes upgrading very dangerous and > > > > annoying to do. As much as possible, I would strongly recommend that > > > > any dependency in Stable can be found in Stable-1 (only when a new > > > > feature is mandatory, then it's ok-ish to require that new version, > > > > though I would advocate for a possible fallback if that's not too > > > > complex to write). > > > > > > > > Now, if that's the path we're taking, all is going backward 5 years > > > > ago, and then my thinking is: we must reintroduce lower-constraints > > > > testing ASAP. > > > > > > > > Your thoughts everyone? > > > > > > It would be nice to have clear guidance on this.? I tried to get > > > pre-release comments about what I planned to do with os-brick, but maybe > > > I didn't allow enough time or had an unclear subject line: > > > > > > http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html > > > > I saw the message, but reading it, it wasn't clear enough what the > > intention was, and TBH, I probably read the patch too quickly. > > > > > My concern about keeping the minima low is that what we're actually > > > testing with in the gate is pretty much whatever's in upper constraints. > > > The previous lower-constraint job basically just checked to see if you > > > could co-install the minimum versions of dependencies and run pass unit > > > tests within a single project, which doesn't seem very realistic. > > > > It was catching API / ABI breakage, which was the intention. > > > > > In any case, it would be better to have an openstack-wide policy so we > > > can raise minima in a coordinated way, rather than me forcing everyone > > > who uses os-brick to do whatever I do. > > > > That's what the global-requirements were supposed to be about, however, > > as far as the CI is concerned, now only the upper-constraints.txt are in > > use, resulting in now useless requirements.txt. > > > > I very much see a huge regression here, compared to what we had maybe 2 > > years ago. > > > > Indeed, we need to have a (more) global thinking OpenStack wide about > > what we should do. I still believe that all project should be able as > > much as possible to run with all the requirements from stable -1, to > > ease upgrading. This way, it's possible to: > > 1/ upgrade all services without updating the libs > > 2/ then upgrade the libs > > 3/ and finally restart all services. > much of the feature development actully assume you upgade the libs first > then upgrade the service > then restart it. > > doign the libs second make the code in the consuming porject much more difficult to write > as we need to have fallbacks but upgrading the libs outside of a breaking major version should > not break exisign users. > > supporting the version of n-1 libs might be worth considering instaed of our older lower constraits aproch > but im really not sure we shoudl expect the service in general to be upgraded first. i can kind of see > why you woudl like that but that woudl increase the burden on client which i dont think we want to do. by the way the reason i prefer the idea of upgrading the lib first is os-vif and all the other lib projects already have jobs that install the master verion of the lib with the current release of the projects that use them i.e. os-vif is used by nova and neutron so we have a devstack job that ensure we can still work with the current master version of nova and neutron. ideally that means we shoudl never break them with a new release. extending that to n-1 would be simpler to do then inverting the upgrade worklow to upgrade the service before the libs. our current testing today assuems the libs will be upgraded first so extending that approch to test more then just the current release is less invaisive. > > > > without troubles with co-existing services. Requiring a lib from the > > current release means that potentially, during the upgrade, an older > > service may run with a library from oldstable+1, which that service > > doesn't know about (yet). If that's not always possible, it's of course > > IMO ok to allow exceptions, if they are under control, and if we make > > sure there's no backward breakage (which can only be checked manually). > > > > Cheers, > > > > Thomas Goirand (zigo) > > > From cdilorenzo at gmail.com Mon Feb 21 16:08:19 2022 From: cdilorenzo at gmail.com (Chris DiLorenzo) Date: Mon, 21 Feb 2022 11:08:19 -0500 Subject: [kolla][neutron] VM is getting the wrong IP, can't contact metadata service In-Reply-To: References: Message-ID: I ended up figuring it out. All the interfaces were created correctly. However, for some reason the DHCP options for this subnet were incorrect. The static route for the subnet was set to the .6 address but neutron had setup the metadata interface on .16. Once I modified the DHCP options and built new instances everything worked fine. Thanks Chris On Mon, Feb 21, 2022 at 6:49 AM Rodolfo Alonso Hernandez < ralonsoh at redhat.com> wrote: > Hello Chris: > > 10.210.65.6 is the IP address of the metadata namespace interface. The > metadata service is on 169.254.169.254 address; this route is redirecting > this traffic. Check the network ID and then the corresponding metadata: > root at u20ovn:~# ip netns > ovnmeta-5274fa45-c33a-4c66-be3a-b8ecd294c769 (id: 3) > ovnmeta-ee1597ee-579d-49dc-9b90-fbb8f98baef9 (id: 2) > > root at u20ovn:~# ip netns exec $meta ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: tap5274fa45-c1 at if62: mtu 1500 qdisc > noqueue state UP group default qlen 1000 > link/ether fa:16:3e:dd:2b:2c brd ff:ff:ff:ff:ff:ff link-netnsid 0 > inet 10.0.10.3/26 brd 10.0.10.63 scope global tap5274fa45-c1 > valid_lft forever preferred_lft forever > inet 169.254.169.254/32 brd 169.254.169.254 scope global > tap5274fa45-c1 > > > Check if the metadata agent logs and verify you are not hitting [1]. Check > you have [2]. > > Regards. > > [1]https://bugs.launchpad.net/neutron/+bug/1952550 > [2]https://review.opendev.org/c/openstack/neutron/+/822669 > > > On Thu, Feb 17, 2022 at 8:14 PM Satish Patel wrote: > >> Disregard my above email, I didn't see that you created vm using a >> fixed IP address. When you create a network/subnet during that time >> OVN creates this special localport IP. In my case its 10.1.1.5 >> >> I believe you shouldn't use that IP address for VM. >> >> port 0e36e2b1-12d2-4eb2-a9ea-556644a73067 >> type: localport >> addresses: ["fa:16:3e:6e:36:f9 10.1.1.5"] >> >> On Thu, Feb 17, 2022 at 2:00 PM Satish Patel >> wrote: >> > >> > 10.210.64.6 must be your computer node IP, it will redirect metadata >> > requests to your controller node. 169.254.169.254 is a special IP >> > address for meta services. >> > >> > On Thu, Feb 17, 2022 at 1:55 PM Chris DiLorenzo >> wrote: >> > > >> > > Hello, >> > > >> > > I am having a weird issue. I am running openstack Victoria with >> OVN. Generally, everything is working. I created a VM using a fixed port >> with an IP of 10.210.64.6. There are no issues with this VM. When I >> create a new VM, I get this route info: >> > > >> > > [ 29.363664] cloud-init[564]: ci-info: >> ++++++++++++++++++++++++++++++++Route IPv4 >> info++++++++++++++++++++++++++++++++ >> > > [ 29.368568] cloud-init[564]: ci-info: >> +-------+-----------------+-------------+-----------------+-----------+-------+ >> > > [ 29.369945] cloud-init[564]: ci-info: | Route | Destination | >> Gateway | Genmask | Interface | Flags | >> > > [ 29.372441] cloud-init[564]: ci-info: >> +-------+-----------------+-------------+-----------------+-----------+-------+ >> > > [ 29.376434] cloud-init[564]: ci-info: | 0 | 0.0.0.0 | >> 10.210.64.1 | 0.0.0.0 | ens3 | UG | >> > > [ 29.377820] cloud-init[564]: ci-info: | 1 | 10.210.64.0 | >> 0.0.0.0 | 255.255.255.192 | ens3 | U | >> > > [ 29.380417] cloud-init[564]: ci-info: | 2 | 169.254.169.254 | >> 10.210.64.6 | 255.255.255.255 | ens3 | UGH | >> > > [ 29.384448] cloud-init[564]: ci-info: >> +-------+-----------------+-------------+-----------------+-----------+-------+ >> > > >> > > The IP is set correctly, but you can see I am getting a gateway of >> 10.210.64.6 for the metadata ser. ice. This is preventing the VM from >> reaching the service so the SSH key is not being added preventing me from >> logging in. As far as I can tell, there are no error and every VM I build >> is getting this .6 IP for this route. >> > > >> > > Thanks, >> > > Chris >> > > >> > > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc-antoine.godde at viarezo.fr Mon Feb 21 17:25:17 2022 From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde) Date: Mon, 21 Feb 2022 18:25:17 +0100 Subject: LetsEncrypt OS Ansible Ussuri Message-ID: Hello, I have a question on how to setup LetsEncrypt with OpenStack Ansible. We are still on OpenStack Ussuri. We added the following variables to user_variables.yml. ================================================================================== haproxy_ssl_letsencrypt_enable: True haproxy_ssl_letsencrypt_install_method: "distro" haproxy_ssl_letsencrypt_setup_extra_params: "--http-01-address {{ ansible_host }} --http-01-port 8888" haproxy_ssl_letsencrypt_email: email at example.com haproxy_interval: 2000 user avatar user avatar haproxy_extra_services: # an internal only service for acme-challenge whose backend is certbot on the haproxy host - service: haproxy_service_name: letsencrypt haproxy_backend_nodes: - name: localhost ip_addr: {{ ansible_host }} #certbot binds to the internal IP backend_rise: 1 #quick rise and fall time for multinode deployment to succeed backend_fall: 2 haproxy_bind: - 127.0.0.1 #bind to 127.0.0.1 as the local internal address will be used by certbot haproxy_port: 8888 #certbot is configured with http-01-port to be 8888 haproxy_balance_type: http ================================================================================== Yet, Horizon config for HAproxy is already defined in the default vars (https://github.com/openstack/openstack-ansible/blob/stable/ussuri/inventory/group_vars/haproxy/haproxy.yml ) and we don?t know where ta add the required ACL to redirect the traffic from 80 port to 8888: ==================================== haproxy_frontend_acls: #use a frontend ACL specify the backend to use for acme-challenge letsencrypt-acl: rule: "path_beg /.well-known/acme-challenge/" backend_name: letsencrypt ==================================== We know that this is fixed in OpenStack Ansible Victoria. Is it possible with Ussuri tho ? Many thanks, Best, Marc-Antoine Godde -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.rosser at rd.bbc.co.uk Mon Feb 21 17:52:19 2022 From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser) Date: Mon, 21 Feb 2022 17:52:19 +0000 Subject: [openstack-ansible] LetsEncrypt OS Ansible Ussuri In-Reply-To: References: Message-ID: <4997625f-e36d-96c3-3a2a-6982b2c51d15@rd.bbc.co.uk> Hi Marc-Antoine, For setting the horizon acl, see https://docs.openstack.org/openstack-ansible/ussuri/user/security/index.html Specifically: "Copy the whole variable haproxy_default_services from /opt/openstack-ansible/inventory/group_vars/haproxy/haproxy.yml to /etc/openstack_deploy/group_vars/haproxy/haproxy_all.yml and update the section for horizon to include the ACL redirects http-01 challenges to the HAProxy letsencrypt backend as follows: ......" It is correct that this is not necessary in later releases and the letsencrypt support is more straightforward to configure in Victoria. You can also join #openstack-ansible IRC channel for some real-time help if needed. Jonathan. On 21/02/2022 17:25, Marc-Antoine Godde wrote: > Hello, > > I have a question on how to setup LetsEncrypt with OpenStack Ansible. > We are still on OpenStack Ussuri. > > We added the following variables to user_variables.yml. > > ================================================================================== > haproxy_ssl_letsencrypt_enable: True > haproxy_ssl_letsencrypt_install_method: "distro" > haproxy_ssl_letsencrypt_setup_extra_params: "--http-01-address {{ > ansible_host }} --http-01-port 8888" > haproxy_ssl_letsencrypt_email: email at example.com > haproxy_interval: 2000 > > user avatar user avatar > haproxy_extra_services: > ? # an internal only service for acme-challenge whose backend is > certbot on the haproxy host > ? - service: > ? ? ? haproxy_service_name: letsencrypt > ? ? ? haproxy_backend_nodes: > ? ? ? ? - name: localhost > ? ? ? ? ? ip_addr: {{ ansible_host }} ? ? ? ? ? ?#certbot binds to the > internal IP > ? ? ? backend_rise: 1 ? ? ? ? ? ?#quick rise and fall time for > multinode deployment to succeed > ? ? ? backend_fall: 2 > ? ? ? haproxy_bind: > ? ? ? ? - 127.0.0.1 ? ? ? ? ? ?#bind to 127.0.0.1 as the local > internal address ?will be used by certbot > ? ? ? haproxy_port: 8888 ? ? ? ? ? #certbot is configured with > http-01-port to be 8888 > ? ? ? haproxy_balance_type: http > ================================================================================== > > Yet, Horizon?config for HAproxy is?already defined in the default vars > (https://github.com/openstack/openstack-ansible/blob/stable/ussuri/inventory/group_vars/haproxy/haproxy.yml) > and we don?t know where ta add the required ACL to redirect the > traffic from 80 port to 8888: > > ==================================== > haproxy_frontend_acls: ? ? #use a frontend ACL specify the backend to > use for acme-challenge > ? letsencrypt-acl: > ? ? rule: "path_beg /.well-known/acme-challenge/" > ? ? backend_name: letsencrypt > ==================================== > > We know that this is fixed in OpenStack Ansible Victoria. Is it > possible with Ussuri tho ? > > Many thanks, > Best, > Marc-Antoine Godde > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Mon Feb 21 18:07:08 2022 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 21 Feb 2022 19:07:08 +0100 Subject: [all] [requirements] Artificially inflated requirements in os-brick In-Reply-To: <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> Message-ID: Hi, I just would like to put my 2 cents on the general idea of having something like we had lower-constraints testing (on master in networking we still have l-c job, but not on stable branches). I think generally everybody agrees that such testing can be really helpful for distro builders for example. The issue is that there is nobody to keep these requirement lists continuously under control. Cheers, Lajos Katona (lajoskatona) Thomas Goirand ezt ?rta (id?pont: 2022. febr. 21., H, 14:17): > On 2/18/22 18:33, Brian Rosmaita wrote: > > On 2/18/22 11:42 AM, Thomas Goirand wrote: > >> Hi, > >> > >> I've been quite surprised to see $topic. Most requirements for > >> os-brick are now to be found in Yoga only. I've asked why, and I've > >> been told that the reason is because "we've been testing with the new > >> versions only for the number of months". > >> > >> Well, the reason why someone would increase a minimum requirement > >> *must* be only because of the need of a new feature, and should be > >> treated with care. Otherwise, this makes upgrading very dangerous and > >> annoying to do. As much as possible, I would strongly recommend that > >> any dependency in Stable can be found in Stable-1 (only when a new > >> feature is mandatory, then it's ok-ish to require that new version, > >> though I would advocate for a possible fallback if that's not too > >> complex to write). > >> > >> Now, if that's the path we're taking, all is going backward 5 years > >> ago, and then my thinking is: we must reintroduce lower-constraints > >> testing ASAP. > >> > >> Your thoughts everyone? > > > > It would be nice to have clear guidance on this. I tried to get > > pre-release comments about what I planned to do with os-brick, but maybe > > I didn't allow enough time or had an unclear subject line: > > > > > http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html > > I saw the message, but reading it, it wasn't clear enough what the > intention was, and TBH, I probably read the patch too quickly. > > > My concern about keeping the minima low is that what we're actually > > testing with in the gate is pretty much whatever's in upper constraints. > > The previous lower-constraint job basically just checked to see if you > > could co-install the minimum versions of dependencies and run pass unit > > tests within a single project, which doesn't seem very realistic. > > It was catching API / ABI breakage, which was the intention. > > > In any case, it would be better to have an openstack-wide policy so we > > can raise minima in a coordinated way, rather than me forcing everyone > > who uses os-brick to do whatever I do. > > That's what the global-requirements were supposed to be about, however, > as far as the CI is concerned, now only the upper-constraints.txt are in > use, resulting in now useless requirements.txt. > > I very much see a huge regression here, compared to what we had maybe 2 > years ago. > > Indeed, we need to have a (more) global thinking OpenStack wide about > what we should do. I still believe that all project should be able as > much as possible to run with all the requirements from stable -1, to > ease upgrading. This way, it's possible to: > 1/ upgrade all services without updating the libs > 2/ then upgrade the libs > 3/ and finally restart all services. > > without troubles with co-existing services. Requiring a lib from the > current release means that potentially, during the upgrade, an older > service may run with a library from oldstable+1, which that service > doesn't know about (yet). If that's not always possible, it's of course > IMO ok to allow exceptions, if they are under control, and if we make > sure there's no backward breakage (which can only be checked manually). > > Cheers, > > Thomas Goirand (zigo) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From divius.inside at gmail.com Mon Feb 21 17:22:05 2022 From: divius.inside at gmail.com (Dmitry Tantsur) Date: Mon, 21 Feb 2022 18:22:05 +0100 Subject: Call for Outreachy OpenStack mentors - May 2022 round In-Reply-To: References: Message-ID: Hi Sofia, I must admit, I was not even aware of this page. I know that there is a desire to move away from wiki, and in the end, each project has to decide separately, if they have ideas AND free mentors. Dmitry ??, 17 ????. 2022 ?. ? 22:32, Sofia Enriquez : > Greetings, > Are we going to update https://wiki.openstack.org/wiki/Internship_ideas ? > Best Regards, > Sofia > > > On Mon, Feb 14, 2022 at 1:18 PM Mahati Chamarthy < > mahati.chamarthy at gmail.com> wrote: > >> 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 >> or Dmitry Tantsur >> >> Best, >> Mahati >> > > > -- > > Sof?a Enriquez > > she/her > > Software Engineer > > Red Hat PnT > > IRC: @enriquetaso > @RedHat Red Hat > Red Hat > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc-antoine.godde at viarezo.fr Mon Feb 21 18:51:10 2022 From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde) Date: Mon, 21 Feb 2022 19:51:10 +0100 Subject: [openstack-ansible] LetsEncrypt OS Ansible Ussuri In-Reply-To: <4997625f-e36d-96c3-3a2a-6982b2c51d15@rd.bbc.co.uk> References: <4997625f-e36d-96c3-3a2a-6982b2c51d15@rd.bbc.co.uk> Message-ID: <258D844F-72E6-415A-A7CA-858491021DD8@viarezo.fr> Thanks for your huge help. It?s is exactly what we wanted to try. We?ll feel more confident. Best, Marc-Antoine > Le 21 f?vr. 2022 ? 18:52, Jonathan Rosser a ?crit : > > Hi Marc-Antoine, > > For setting the horizon acl, see https://docs.openstack.org/openstack-ansible/ussuri/user/security/index.html > Specifically: > > "Copy the whole variable haproxy_default_services from /opt/openstack-ansible/inventory/group_vars/haproxy/haproxy.yml to /etc/openstack_deploy/group_vars/haproxy/haproxy_all.yml and update the section for horizon to include the ACL redirects http-01 challenges to the HAProxy letsencrypt backend as follows: ......" > > It is correct that this is not necessary in later releases and the letsencrypt support is more straightforward to configure in Victoria. > > You can also join #openstack-ansible IRC channel for some real-time help if needed. > > Jonathan. > > On 21/02/2022 17:25, Marc-Antoine Godde wrote: >> Hello, >> >> I have a question on how to setup LetsEncrypt with OpenStack Ansible. We are still on OpenStack Ussuri. >> >> We added the following variables to user_variables.yml. >> >> ================================================================================== >> haproxy_ssl_letsencrypt_enable: True >> haproxy_ssl_letsencrypt_install_method: "distro" >> haproxy_ssl_letsencrypt_setup_extra_params: "--http-01-address {{ ansible_host }} --http-01-port 8888" >> haproxy_ssl_letsencrypt_email: email at example.com >> haproxy_interval: 2000 >> >> user avatar user avatar >> haproxy_extra_services: >> # an internal only service for acme-challenge whose backend is certbot on the haproxy host >> - service: >> haproxy_service_name: letsencrypt >> haproxy_backend_nodes: >> - name: localhost >> ip_addr: {{ ansible_host }} #certbot binds to the internal IP >> backend_rise: 1 #quick rise and fall time for multinode deployment to succeed >> backend_fall: 2 >> haproxy_bind: >> - 127.0.0.1 #bind to 127.0.0.1 as the local internal address will be used by certbot >> haproxy_port: 8888 #certbot is configured with http-01-port to be 8888 >> haproxy_balance_type: http >> ================================================================================== >> >> Yet, Horizon config for HAproxy is already defined in the default vars (https://github.com/openstack/openstack-ansible/blob/stable/ussuri/inventory/group_vars/haproxy/haproxy.yml ) and we don?t know where ta add the required ACL to redirect the traffic from 80 port to 8888: >> >> ==================================== >> haproxy_frontend_acls: #use a frontend ACL specify the backend to use for acme-challenge >> letsencrypt-acl: >> rule: "path_beg /.well-known/acme-challenge/" >> backend_name: letsencrypt >> ==================================== >> >> We know that this is fixed in OpenStack Ansible Victoria. Is it possible with Ussuri tho ? >> >> Many thanks, >> Best, >> Marc-Antoine Godde >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Mon Feb 21 19:52:35 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Mon, 21 Feb 2022 20:52:35 +0100 Subject: [PTLs][release] Yoga Cycle Highligts Message-ID: Hi, This is a reminder, that *this week* is the week for Cycle highlights [1][2]! They need to be added to deliverable yamls so that they can be included in release marketing preparations. (See the details about how to add them at the project team guide [3].) [1] https://releases.openstack.org/yoga/schedule.html [2] https://releases.openstack.org/yoga/schedule.html#y-cycle-highlights [3] https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights Thanks, El?d Ill?s irc: elodilles From gmann at ghanshyammann.com Mon Feb 21 21:16:38 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 21 Feb 2022 15:16:38 -0600 Subject: [all][tc] Technical Committee next weekly meeting on Feb 24th at 1500 UTC Message-ID: <17f1e24bc0b.c42360a5371741.4976648255459197392@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Feb 24th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Feb 23rd, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From jonathan.rosser at rd.bbc.co.uk Tue Feb 22 09:35:34 2022 From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser) Date: Tue, 22 Feb 2022 09:35:34 +0000 Subject: [openstack-ansible] LetsEncrypt OS Ansible Ussuri In-Reply-To: <258D844F-72E6-415A-A7CA-858491021DD8@viarezo.fr> References: <4997625f-e36d-96c3-3a2a-6982b2c51d15@rd.bbc.co.uk> <258D844F-72E6-415A-A7CA-858491021DD8@viarezo.fr> Message-ID: <03f65b29-b5be-2b45-7482-4936359cedb4@rd.bbc.co.uk> Hi Marc-Antione, No problem. I would recommend adding --staging to haproxy_ssl_letsencrypt_setup_extra_params whilst you get the letsencrypt support working. You will not get a proper certificate with that flag but it will bypass the letsencrypt rate limit so you can have as many tests as you need. It would be also worth checking the timeout values on later branches, Ussuri is now in extended-maintenance so not receiving back ported bug fixes. See for example https://github.com/openstack/openstack-ansible/blob/stable/xena/inventory/group_vars/haproxy/haproxy.yml#L248-L258 On 21/02/2022 18:51, Marc-Antoine Godde wrote: > Thanks for your huge help. It?s is exactly what we wanted to try. > We?ll feel?more confident. > > Best, > Marc-Antoine > > > >> Le 21 f?vr. 2022 ? 18:52, Jonathan Rosser >> a ?crit : >> >> Hi Marc-Antoine, >> >> For setting the horizon acl, see >> https://docs.openstack.org/openstack-ansible/ussuri/user/security/index.html >> >> Specifically: >> >> "Copy the whole variable haproxy_default_services from >> /opt/openstack-ansible/inventory/group_vars/haproxy/haproxy.yml to >> /etc/openstack_deploy/group_vars/haproxy/haproxy_all.yml and update >> the section for horizon to include the ACL redirects http-01 >> challenges to the HAProxy letsencrypt backend as follows: ......" >> >> It is correct that this is not necessary in later releases and the >> letsencrypt support is more straightforward to configure in Victoria. >> >> You can also join #openstack-ansible IRC channel for some real-time >> help if needed. >> >> Jonathan. >> >> On 21/02/2022 17:25, Marc-Antoine Godde wrote: >>> Hello, >>> >>> I have a question on how to setup LetsEncrypt with OpenStack >>> Ansible. We are still on OpenStack Ussuri. >>> >>> We added the following variables to user_variables.yml. >>> >>> ================================================================================== >>> haproxy_ssl_letsencrypt_enable: True >>> haproxy_ssl_letsencrypt_install_method: "distro" >>> haproxy_ssl_letsencrypt_setup_extra_params: "--http-01-address {{ >>> ansible_host }} --http-01-port 8888" >>> haproxy_ssl_letsencrypt_email: email at example.com >>> haproxy_interval: 2000 >>> >>> user avatar user avatar >>> haproxy_extra_services: >>> ? # an internal only service for acme-challenge whose backend is >>> certbot on the haproxy host >>> ? - service: >>> ? ? ? haproxy_service_name: letsencrypt >>> ? ? ? haproxy_backend_nodes: >>> ? ? ? ? - name: localhost >>> ? ? ? ? ? ip_addr: {{ ansible_host }} ? ? ? ? ? ? ? ? ? ? ? >>> ?#certbot binds to the internal IP >>> ? ? ? backend_rise: 1 ? ? ? ? ? ? ? ? ? ? ? ? ?#quick rise and fall >>> time for multinode deployment to succeed >>> ? ? ? backend_fall: 2 >>> ? ? ? haproxy_bind: >>> ? ? ? ? - 127.0.0.1 ? ? ? ? ? ? ? ? ? ? ? ? ?#bind to 127.0.0.1 as >>> the local internal address ?will be used by certbot >>> ? ? ? haproxy_port: 8888 ? ? ? ? ? ? ? ? ? ? ? ? #certbot is >>> configured with http-01-port to be 8888 >>> ? ? ? haproxy_balance_type: http >>> ================================================================================== >>> >>> Yet, Horizon?config for HAproxy is?already defined in the default >>> vars >>> (https://github.com/openstack/openstack-ansible/blob/stable/ussuri/inventory/group_vars/haproxy/haproxy.yml) >>> and we don?t know where ta add the required ACL to redirect the >>> traffic from 80 port to 8888: >>> >>> ==================================== >>> haproxy_frontend_acls: ? ? ? ? ? ? ? ? ? #use a frontend ACL specify >>> the backend to use for acme-challenge >>> ? letsencrypt-acl: >>> ? ? rule: "path_beg /.well-known/acme-challenge/" >>> ? ? backend_name: letsencrypt >>> ==================================== >>> >>> We know that this is fixed in OpenStack Ansible Victoria. Is it >>> possible with Ussuri tho ? >>> >>> Many thanks, >>> Best, >>> Marc-Antoine Godde >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Tue Feb 22 09:44:53 2022 From: zigo at debian.org (Thomas Goirand) Date: Tue, 22 Feb 2022 10:44:53 +0100 Subject: [all] [requirements] Artificially inflated requirements in os-brick In-Reply-To: <3f06828a40cd6a473b06246aea214d040c15cc37.camel@redhat.com> References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> <3f06828a40cd6a473b06246aea214d040c15cc37.camel@redhat.com> Message-ID: On 2/21/22 14:27, Sean Mooney wrote: > On Mon, 2022-02-21 at 14:10 +0100, Thomas Goirand wrote: >> On 2/18/22 18:33, Brian Rosmaita wrote: >>> On 2/18/22 11:42 AM, Thomas Goirand wrote: >>>> Hi, >>>> >>>> I've been quite surprised to see $topic. Most requirements for >>>> os-brick are now to be found in Yoga only. I've asked why, and I've >>>> been told that the reason is because "we've been testing with the new >>>> versions only for the number of months". >>>> >>>> Well, the reason why someone would increase a minimum requirement >>>> *must* be only because of the need of a new feature, and should be >>>> treated with care. Otherwise, this makes upgrading very dangerous and >>>> annoying to do. As much as possible, I would strongly recommend that >>>> any dependency in Stable can be found in Stable-1 (only when a new >>>> feature is mandatory, then it's ok-ish to require that new version, >>>> though I would advocate for a possible fallback if that's not too >>>> complex to write). >>>> >>>> Now, if that's the path we're taking, all is going backward 5 years >>>> ago, and then my thinking is: we must reintroduce lower-constraints >>>> testing ASAP. >>>> >>>> Your thoughts everyone? >>> >>> It would be nice to have clear guidance on this.? I tried to get >>> pre-release comments about what I planned to do with os-brick, but maybe >>> I didn't allow enough time or had an unclear subject line: >>> >>> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html >> >> I saw the message, but reading it, it wasn't clear enough what the >> intention was, and TBH, I probably read the patch too quickly. >> >>> My concern about keeping the minima low is that what we're actually >>> testing with in the gate is pretty much whatever's in upper constraints. >>> The previous lower-constraint job basically just checked to see if you >>> could co-install the minimum versions of dependencies and run pass unit >>> tests within a single project, which doesn't seem very realistic. >> >> It was catching API / ABI breakage, which was the intention. >> >>> In any case, it would be better to have an openstack-wide policy so we >>> can raise minima in a coordinated way, rather than me forcing everyone >>> who uses os-brick to do whatever I do. >> >> That's what the global-requirements were supposed to be about, however, >> as far as the CI is concerned, now only the upper-constraints.txt are in >> use, resulting in now useless requirements.txt. >> >> I very much see a huge regression here, compared to what we had maybe 2 >> years ago. >> >> Indeed, we need to have a (more) global thinking OpenStack wide about >> what we should do. I still believe that all project should be able as >> much as possible to run with all the requirements from stable -1, to >> ease upgrading. This way, it's possible to: >> 1/ upgrade all services without updating the libs >> 2/ then upgrade the libs >> 3/ and finally restart all services. > much of the feature development actully assume you upgade the libs first > then upgrade the service > then restart it. If we support the version of the libs from stable-1, this means that effectively, we support the workflow I'm talking about. The way you are describing the upgrade (ie: libs first) simply doesn't work. It would mean services from stable -1 support libs from stable: nobody has a crystal ball, and it's impossible to support the changes we're going to do in 6 months of time. So the only thing we can do is support backward compatibility. Note that I haven't advocate for *only* supporting libs from stable -1. I think this must be the lowest bar to set. I'd very much prefer if we were doing things right (tm), meaning supporting the lowest possible version. This means one would increase the lower bound of a requirement only when needing a new API not provided by an earlier version of the lib. Though giving the current constraints, maybe testing with the version of the libs from stable -1 would work. Also, let's keep in mind the current TC proposal (ie: mandate allowing to skip every odd release during upgrades). If it goes forward, then probably we will need to support libs from stable -2 on every odd release of OpenStack. Cheers, Thomas Goirand (zigo) From zigo at debian.org Tue Feb 22 09:51:04 2022 From: zigo at debian.org (Thomas Goirand) Date: Tue, 22 Feb 2022 10:51:04 +0100 Subject: [all] [requirements] Artificially inflated requirements in os-brick In-Reply-To: References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> <3f06828a40cd6a473b06246aea214d040c15cc37.camel@redhat.com> Message-ID: On 2/21/22 14:32, Sean Mooney wrote: > On Mon, 2022-02-21 at 13:27 +0000, Sean Mooney wrote: >> On Mon, 2022-02-21 at 14:10 +0100, Thomas Goirand wrote: >>> On 2/18/22 18:33, Brian Rosmaita wrote: >>>> On 2/18/22 11:42 AM, Thomas Goirand wrote: >>>>> Hi, >>>>> >>>>> I've been quite surprised to see $topic. Most requirements for >>>>> os-brick are now to be found in Yoga only. I've asked why, and I've >>>>> been told that the reason is because "we've been testing with the new >>>>> versions only for the number of months". >>>>> >>>>> Well, the reason why someone would increase a minimum requirement >>>>> *must* be only because of the need of a new feature, and should be >>>>> treated with care. Otherwise, this makes upgrading very dangerous and >>>>> annoying to do. As much as possible, I would strongly recommend that >>>>> any dependency in Stable can be found in Stable-1 (only when a new >>>>> feature is mandatory, then it's ok-ish to require that new version, >>>>> though I would advocate for a possible fallback if that's not too >>>>> complex to write). >>>>> >>>>> Now, if that's the path we're taking, all is going backward 5 years >>>>> ago, and then my thinking is: we must reintroduce lower-constraints >>>>> testing ASAP. >>>>> >>>>> Your thoughts everyone? >>>> >>>> It would be nice to have clear guidance on this.? I tried to get >>>> pre-release comments about what I planned to do with os-brick, but maybe >>>> I didn't allow enough time or had an unclear subject line: >>>> >>>> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html >>> >>> I saw the message, but reading it, it wasn't clear enough what the >>> intention was, and TBH, I probably read the patch too quickly. >>> >>>> My concern about keeping the minima low is that what we're actually >>>> testing with in the gate is pretty much whatever's in upper constraints. >>>> The previous lower-constraint job basically just checked to see if you >>>> could co-install the minimum versions of dependencies and run pass unit >>>> tests within a single project, which doesn't seem very realistic. >>> >>> It was catching API / ABI breakage, which was the intention. >>> >>>> In any case, it would be better to have an openstack-wide policy so we >>>> can raise minima in a coordinated way, rather than me forcing everyone >>>> who uses os-brick to do whatever I do. >>> >>> That's what the global-requirements were supposed to be about, however, >>> as far as the CI is concerned, now only the upper-constraints.txt are in >>> use, resulting in now useless requirements.txt. >>> >>> I very much see a huge regression here, compared to what we had maybe 2 >>> years ago. >>> >>> Indeed, we need to have a (more) global thinking OpenStack wide about >>> what we should do. I still believe that all project should be able as >>> much as possible to run with all the requirements from stable -1, to >>> ease upgrading. This way, it's possible to: >>> 1/ upgrade all services without updating the libs >>> 2/ then upgrade the libs >>> 3/ and finally restart all services. >> much of the feature development actully assume you upgade the libs first >> then upgrade the service >> then restart it. >> >> doign the libs second make the code in the consuming porject much more difficult to write >> as we need to have fallbacks but upgrading the libs outside of a breaking major version should >> not break exisign users. >> >> supporting the version of n-1 libs might be worth considering instaed of our older lower constraits aproch >> but im really not sure we shoudl expect the service in general to be upgraded first. i can kind of see >> why you woudl like that but that woudl increase the burden on client which i dont think we want to do. > > by the way the reason i prefer the idea of upgrading the lib first is os-vif and all the other lib projects > already have jobs that install the master verion of the lib with the current release of the projects that use them > i.e. os-vif is used by nova and neutron so we have a devstack job that ensure we can still work with the current > master version of nova and neutron. ideally that means we shoudl never break them with a new release. Oh, this makes me think that what I wrote is not completely accurate. While IMO, supporting the stable -1 version of a lib like os-vif and os-brick is important, a lib like neutron-lib of course, is bound to a specific release of OpenStack and the matching Neutron API. So IMO, the reasoning doesn't apply for something like neutron-lib, which contains the internal description of the Neutron API. This however, may make things difficult to upgrade when having Octavia running on the same server as Neutron, but I currently don't see any workaround. Maybe the solution is only to make sure that neutron-lib doesn't break the stable -1 version of Octavia (for example). So in this case, it's more up to neutron-lib to be backward compatible. Hoping what I wrote makes sense, Cheers, Thomas Goirand (zigo) From marc-antoine.godde at viarezo.fr Tue Feb 22 10:11:00 2022 From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde) Date: Tue, 22 Feb 2022 11:11:00 +0100 Subject: [openstack-ansible] LetsEncrypt OS Ansible Ussuri In-Reply-To: <03f65b29-b5be-2b45-7482-4936359cedb4@rd.bbc.co.uk> References: <4997625f-e36d-96c3-3a2a-6982b2c51d15@rd.bbc.co.uk> <258D844F-72E6-415A-A7CA-858491021DD8@viarezo.fr> <03f65b29-b5be-2b45-7482-4936359cedb4@rd.bbc.co.uk> Message-ID: <8C92B8B1-F0AF-4CB4-9C01-FD4BAA6BA913@viarezo.fr> Hello Jonathan, Thanks for the tips. It is interesting that you point this out, it was indeed one of my concern. If I understood the process correctly, Certbot will run on each HAproxy node and request LetsEncypt to issue certificate on each node. This means that we ask many certificates for the same domain (for instance openstack.example.com ). This must impact the following rate limit of LetsEncrypt: "Renewals are treated specially: they don?t count against your Certificates per Registered Domain limit, but they are subject to a Duplicate Certificate limit of 5 per week. Exceeding the Duplicate Certificate limit is reported with the error message too many certificates already issued for exact set of domains. ? LetsEncrypt Website Does that mean that the the deployment is limited to 5 HAProxy nodes ? Normally we are safe tho, we have 3. Concerning, the timeout values, we?ll make sure to check them out. We?ll upgrade to Wallaby or Xena by the end of the year in any case. Thanks, Marc-Antoine > Le 22 f?vr. 2022 ? 10:35, Jonathan Rosser a ?crit : > > Hi Marc-Antione, > > No problem. I would recommend adding --staging to haproxy_ssl_letsencrypt_setup_extra_params whilst you get the letsencrypt support working. You will not get a proper certificate with that flag but it will bypass the letsencrypt rate limit so you can have as many tests as you need. > > It would be also worth checking the timeout values on later branches, Ussuri is now in extended-maintenance so not receiving back ported bug fixes. > > See for example https://github.com/openstack/openstack-ansible/blob/stable/xena/inventory/group_vars/haproxy/haproxy.yml#L248-L258 > > On 21/02/2022 18:51, Marc-Antoine Godde wrote: >> Thanks for your huge help. It?s is exactly what we wanted to try. We?ll feel more confident. >> >> Best, >> Marc-Antoine >> >> >> >>> Le 21 f?vr. 2022 ? 18:52, Jonathan Rosser > a ?crit : >>> >>> Hi Marc-Antoine, >>> >>> For setting the horizon acl, see https://docs.openstack.org/openstack-ansible/ussuri/user/security/index.html >>> Specifically: >>> >>> "Copy the whole variable haproxy_default_services from /opt/openstack-ansible/inventory/group_vars/haproxy/haproxy.yml to /etc/openstack_deploy/group_vars/haproxy/haproxy_all.yml and update the section for horizon to include the ACL redirects http-01 challenges to the HAProxy letsencrypt backend as follows: ......" >>> >>> It is correct that this is not necessary in later releases and the letsencrypt support is more straightforward to configure in Victoria. >>> >>> You can also join #openstack-ansible IRC channel for some real-time help if needed. >>> >>> Jonathan. >>> >>> On 21/02/2022 17:25, Marc-Antoine Godde wrote: >>>> Hello, >>>> >>>> I have a question on how to setup LetsEncrypt with OpenStack Ansible. We are still on OpenStack Ussuri. >>>> >>>> We added the following variables to user_variables.yml. >>>> >>>> ================================================================================== >>>> haproxy_ssl_letsencrypt_enable: True >>>> haproxy_ssl_letsencrypt_install_method: "distro" >>>> haproxy_ssl_letsencrypt_setup_extra_params: "--http-01-address {{ ansible_host }} --http-01-port 8888" >>>> haproxy_ssl_letsencrypt_email: email at example.com >>>> haproxy_interval: 2000 >>>> >>>> user avatar user avatar >>>> haproxy_extra_services: >>>> # an internal only service for acme-challenge whose backend is certbot on the haproxy host >>>> - service: >>>> haproxy_service_name: letsencrypt >>>> haproxy_backend_nodes: >>>> - name: localhost >>>> ip_addr: {{ ansible_host }} #certbot binds to the internal IP >>>> backend_rise: 1 #quick rise and fall time for multinode deployment to succeed >>>> backend_fall: 2 >>>> haproxy_bind: >>>> - 127.0.0.1 #bind to 127.0.0.1 as the local internal address will be used by certbot >>>> haproxy_port: 8888 #certbot is configured with http-01-port to be 8888 >>>> haproxy_balance_type: http >>>> ================================================================================== >>>> >>>> Yet, Horizon config for HAproxy is already defined in the default vars (https://github.com/openstack/openstack-ansible/blob/stable/ussuri/inventory/group_vars/haproxy/haproxy.yml ) and we don?t know where ta add the required ACL to redirect the traffic from 80 port to 8888: >>>> >>>> ==================================== >>>> haproxy_frontend_acls: #use a frontend ACL specify the backend to use for acme-challenge >>>> letsencrypt-acl: >>>> rule: "path_beg /.well-known/acme-challenge/" >>>> backend_name: letsencrypt >>>> ==================================== >>>> >>>> We know that this is fixed in OpenStack Ansible Victoria. Is it possible with Ussuri tho ? >>>> >>>> Many thanks, >>>> Best, >>>> Marc-Antoine Godde >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpawlik at redhat.com Tue Feb 22 11:34:34 2022 From: dpawlik at redhat.com (Daniel Pawlik) Date: Tue, 22 Feb 2022 12:34:34 +0100 Subject: New CI log workflow improvement Message-ID: Hi, tl;dr Besides sending CI logs, does someone use Logstash on Opendev to push information to the new Elasticsearch (Opensearch) service? Long version: I am currently looking into a new log workflow for OpenDev's OpenSearch that is using the logscraper tool [1], as an improvement over the current workflow [2]. I spotted a few bottlenecks that are complicating pushing logs to the new Elasticsearch service. The most important bottlenecks are: - - gearman worker - this service needs at least 10 instances to keep up with the current influx of build logs. - As a reminder, this service consumes information prepared by gearman client, downloads the logs, adds information and - pushes data to the logstash service, - - logstash service - this service is "freezing" from time to time and it requires many resources such as CPU and RAM. - As a reminder, the service receives data and by using grok filter [3] prepares information that later will be pushed - to Elasticsearch. - The new workflow would eliminate these bottlenecks by pushing data directly into Elasticsearch. This would therefore drop the following services: - gearman client - gearman worker - logstash service Before proceeding further, we need to know if these services, especially logstash, are (apart from sending logs from CI) not used anywhere, so that we don't accidentally pull the plug on any other workflows. If you are aware of these, please let me know. Dan [1] https://opendev.org/openstack/ci-log-processing [2] https://docs.opendev.org/opendev/system-config/latest/logstash.html [3] https://opendev.org/openstack/logstash-filters/src/branch/master/filters/openstack-filters.conf -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Feb 22 11:59:11 2022 From: smooney at redhat.com (Sean Mooney) Date: Tue, 22 Feb 2022 11:59:11 +0000 Subject: [all] [requirements] Artificially inflated requirements in os-brick In-Reply-To: References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> <80433acd-81e5-d4f8-5f59-285875b84709@debian.org> <3f06828a40cd6a473b06246aea214d040c15cc37.camel@redhat.com> Message-ID: <833161e31963cb3e9db1bef478edb76ab8f158a2.camel@redhat.com> On Tue, 2022-02-22 at 10:51 +0100, Thomas Goirand wrote: > On 2/21/22 14:32, Sean Mooney wrote: > > On Mon, 2022-02-21 at 13:27 +0000, Sean Mooney wrote: > > > On Mon, 2022-02-21 at 14:10 +0100, Thomas Goirand wrote: > > > > On 2/18/22 18:33, Brian Rosmaita wrote: > > > > > On 2/18/22 11:42 AM, Thomas Goirand wrote: > > > > > > Hi, > > > > > > > > > > > > I've been quite surprised to see $topic. Most requirements for > > > > > > os-brick are now to be found in Yoga only. I've asked why, and I've > > > > > > been told that the reason is because "we've been testing with the new > > > > > > versions only for the number of months". > > > > > > > > > > > > Well, the reason why someone would increase a minimum requirement > > > > > > *must* be only because of the need of a new feature, and should be > > > > > > treated with care. Otherwise, this makes upgrading very dangerous and > > > > > > annoying to do. As much as possible, I would strongly recommend that > > > > > > any dependency in Stable can be found in Stable-1 (only when a new > > > > > > feature is mandatory, then it's ok-ish to require that new version, > > > > > > though I would advocate for a possible fallback if that's not too > > > > > > complex to write). > > > > > > > > > > > > Now, if that's the path we're taking, all is going backward 5 years > > > > > > ago, and then my thinking is: we must reintroduce lower-constraints > > > > > > testing ASAP. > > > > > > > > > > > > Your thoughts everyone? > > > > > > > > > > It would be nice to have clear guidance on this.? I tried to get > > > > > pre-release comments about what I planned to do with os-brick, but maybe > > > > > I didn't allow enough time or had an unclear subject line: > > > > > > > > > > http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html > > > > > > > > I saw the message, but reading it, it wasn't clear enough what the > > > > intention was, and TBH, I probably read the patch too quickly. > > > > > > > > > My concern about keeping the minima low is that what we're actually > > > > > testing with in the gate is pretty much whatever's in upper constraints. > > > > > The previous lower-constraint job basically just checked to see if you > > > > > could co-install the minimum versions of dependencies and run pass unit > > > > > tests within a single project, which doesn't seem very realistic. > > > > > > > > It was catching API / ABI breakage, which was the intention. > > > > > > > > > In any case, it would be better to have an openstack-wide policy so we > > > > > can raise minima in a coordinated way, rather than me forcing everyone > > > > > who uses os-brick to do whatever I do. > > > > > > > > That's what the global-requirements were supposed to be about, however, > > > > as far as the CI is concerned, now only the upper-constraints.txt are in > > > > use, resulting in now useless requirements.txt. > > > > > > > > I very much see a huge regression here, compared to what we had maybe 2 > > > > years ago. > > > > > > > > Indeed, we need to have a (more) global thinking OpenStack wide about > > > > what we should do. I still believe that all project should be able as > > > > much as possible to run with all the requirements from stable -1, to > > > > ease upgrading. This way, it's possible to: > > > > 1/ upgrade all services without updating the libs > > > > 2/ then upgrade the libs > > > > 3/ and finally restart all services. > > > much of the feature development actully assume you upgade the libs first > > > then upgrade the service > > > then restart it. > > > > > > doign the libs second make the code in the consuming porject much more difficult to write > > > as we need to have fallbacks but upgrading the libs outside of a breaking major version should > > > not break exisign users. > > > > > > supporting the version of n-1 libs might be worth considering instaed of our older lower constraits aproch > > > but im really not sure we shoudl expect the service in general to be upgraded first. i can kind of see > > > why you woudl like that but that woudl increase the burden on client which i dont think we want to do. > > > > by the way the reason i prefer the idea of upgrading the lib first is os-vif and all the other lib projects > > already have jobs that install the master verion of the lib with the current release of the projects that use them > > i.e. os-vif is used by nova and neutron so we have a devstack job that ensure we can still work with the current > > master version of nova and neutron. ideally that means we shoudl never break them with a new release. > > Oh, this makes me think that what I wrote is not completely accurate. > While IMO, supporting the stable -1 version of a lib like os-vif and > os-brick is important, a lib like neutron-lib of course, is bound to a > specific release of OpenStack and the matching Neutron API. So IMO, the > reasoning doesn't apply for something like neutron-lib, which contains > the internal description of the Neutron API. This however, may make > things difficult to upgrade when having Octavia running on the same > server as Neutron, but I currently don't see any workaround. Maybe the > solution is only to make sure that neutron-lib doesn't break the stable > -1 version of Octavia (for example). So in this case, it's more up to > neutron-lib to be backward compatible. > > Hoping what I wrote makes sense, > Cheers, ya it does we might need to test diffrently for release independent libs vs release coupled libs. one of the other issue we have is deciding when we bump a dep for example we are adding support for lightos storage backend to os-brick nova and cinder. now if you are using lightos you will need a new verion of os-brick but if you dont nova and cinder technically dont need the latest version which adds support for it. we dont have an excelent way to track that today. bindeps has suppport for tags and requirements.txt or well pbr/setuptools more then requiremetns.txt also have the concept of filtering requiremetns too based on things like python version or you can make use of extras to supprot things like pip install nova[lightos] ir we wanted to do that. maybe it would make sense to start tracking deps for optional backend differently. right now we need to have the new dep for testing but most deployment will use ceph so lightos does not matter in terms of selecting a min os-brick dep for nova. i have made the argument in the past that we shoudl not bump the dep in nova in this case and we shoudl instetad document or track this differently for the less common backend but we never really came to a good way to test that without explodign the jobs. the one think i will say however is if we cant depend on havign the requried dep installed it forces us to add check on the version of the lib installed before using some feature which is not somethign we want to have to do in nova or in your example octavia and neutron both adding check on the neutorn-lib version. so right now we bump the min version any time any feature in any backend uses a new feature of a lib. in many cases an older version will work provided you dont use that backend leadign to what feels like an artifically high version requirement. > > Thomas Goirand (zigo) > From tdecacqu at redhat.com Tue Feb 22 12:05:49 2022 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Tue, 22 Feb 2022 12:05:49 +0000 Subject: New CI log workflow improvement In-Reply-To: References: Message-ID: <87sfsbgl7m.tristanC@fedora> On Tue, Feb 22, 2022 at 12:34 Daniel Pawlik wrote: > Hi, > > tl;dr Besides sending CI logs, does someone use Logstash on Opendev to push > information to the new Elasticsearch (Opensearch) service? Would it be possible to check the logstash service access log? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From lokendrarathour at gmail.com Tue Feb 22 12:08:48 2022 From: lokendrarathour at gmail.com (Lokendra Rathour) Date: Tue, 22 Feb 2022 17:38:48 +0530 Subject: [TripleO] Offline Installation Support In-Reply-To: References: Message-ID: Hi Team, Any support here please. We need to understand the offline approach as well. On Wed, 16 Feb 2022, 22:00 Anirudh Gupta, wrote: > Hi Team, > > We have successfully done POC on deploying my TripleO Train HA Setup with > Baremetal Provisioning on Overcloud Node as well. > > We would like to thank Tripleo community members for helping us and > resolving all our concerns at all times. > > Moving forward, we need to deploy the setup on the Lab environment for > which I need some support as well. > > We don't have internet in Lab machines, all that we have is access to a > central server (staging) which has internet access and we can download all > the requirements over there. > > Queries: > > - Is there any feasible method to install Undercloud and Overcloud > Machines in complete offline mode? > - If yes, then > > > 1. What are the steps to download all related stuff on the staging > server? > 2. What modifications would be required in undercloud/overcloud and > other configuration files to support this? > > Regards > Anirudh Gupta > > Regards > Anirudh Gupta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Tue Feb 22 12:13:35 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Tue, 22 Feb 2022 09:13:35 -0300 Subject: [CloudKitty] Virtual PTG April 2022 Message-ID: Hello everyone, As you probably heard our next PTG will be held virtually in April. We've marked April 4, at 13:00-16:00 UTC [1]. We already have a CloudKitty meeting organized for this day. Therefore, it seems the most practical choice. However, if you guys would like some other dates and/or time, just let me know. The room we selected is called "Cactus". I've also created an etherpad [2] to collect ideas/topics for the PTG sessions. If you have anything to discuss, please don't hesitate to write it there. [1] https://ethercalc.openstack.org/7yxdas7suqnd [2] https://etherpad.opendev.org/p/cloudkitty-ptg-zed -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Tue Feb 22 12:51:09 2022 From: syedammad83 at gmail.com (Ammad Syed) Date: Tue, 22 Feb 2022 17:51:09 +0500 Subject: [nova] OOM Killed Processes In-Reply-To: <8cac2ca15914bc2be6373ea708c40d64bb6d85ce.camel@redhat.com> References: <8cac2ca15914bc2be6373ea708c40d64bb6d85ce.camel@redhat.com> Message-ID: On Mon, Feb 21, 2022 at 6:21 PM Sean Mooney wrote: > On Mon, 2022-02-21 at 12:24 +0500, Ammad Syed wrote: > > Hi,, > > > > I am having trouble with my compute node that nova-compute and ovs > process > > are being killed by OOM. I have alot memory available in system. > > > > # free -g > > total used free shared buff/cache > > available > > Mem: 1006 121 881 0 2 > > 879 > > Swap: 7 0 7 > > > > But I am seeing process are being killed in dmesg. > > > > [Sat Feb 19 03:46:26 2022] Memory cgroup out of memory: Killed process > > 2080898 (ovs-vswitchd) total-vm:9474284kB, anon-rss:1076384kB, > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2776kB oom_score_adj:0 > > [Sat Feb 19 03:47:01 2022] Memory cgroup out of memory: Killed process > > 2081218 (ovs-vswitchd) total-vm:9475332kB, anon-rss:1096988kB, > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2780kB oom_score_adj:0 > > [Sat Feb 19 03:47:06 2022] Memory cgroup out of memory: Killed process > > 2081616 (ovs-vswitchd) total-vm:9473252kB, anon-rss:1073052kB, > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2784kB oom_score_adj:0 > > [Sat Feb 19 03:47:16 2022] Memory cgroup out of memory: Killed process > > 2081940 (ovs-vswitchd) total-vm:9471236kB, anon-rss:1070920kB, > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2776kB oom_score_adj:0 > > [Sat Feb 19 03:47:16 2022] Memory cgroup out of memory: Killed process > 6098 > > (nova-compute) total-vm:3428356kB, anon-rss:279920kB, file-rss:9868kB, > > shmem-rss:0kB, UID:64060 pgtables:1020kB oom_score_adj:0 > > [Mon Feb 21 11:15:08 2022] Memory cgroup out of memory: Killed process > > 2082296 (ovs-vswitchd) total-vm:9475372kB, anon-rss:1162636kB, > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2864kB oom_score_adj:0 > > > > Any advice on how to fix this ? Also any best practices document on > > configuring memory optimizations in nova compute node. > so one thing to note is that the OOM reaper service runs per numa node > so the gloable free memory values are not really what you need to look at. > > croups/systemd also provide ways to limit the max memory a process/cgroup > tree can consume > > so your first stp shoudl be to determin if the oom event was triggered by > exaustign the memroy in > a specific numa node or if you are hitting a differnt cgroup memory limit. > As the logs suggest, it looks like the memory of cgroup is exhausted. The memory of system.slice cgroup is 4G and user.slice is 2G by default. I have increased system.slice to 64GB. > > in terms fo how to optimisze memroy it really depend on what your end goal > is here. > > obviously we do not want ovs or nova-compute to be killsed in general. > the virtaul and reseden memory for ovs is in the 10 to 1 GB range so that > is not excessively large. > > that also should not be anywhere near the numa limit but if you were > incorrectly creating numa affinged > vms without seting hw:mem_page_size via nova then that could perhaps > tirgger out of memory events > Currently I am not using any page_size in my flavors. > > effectivly with openenstack if your vm is numa affined eiter explictly via > hw:numa_nodes extra specs or implictly via > cpu pinning or otherwise then you must define that the memory is tracked > using the numa aware path which requires > you do defien hw:mem_page_size in the flaovr or hw_mem_page_size in the > image. > I am only using CPU soft pinning (vcpu placement) i.e cpu_shared_set. However I have only configured hw:cpu_sockets='2' in flavors to make two sockets for VM. This helps in effective cpu utilization in windows hosts. However in VM I can only see one numa node of memory. Will this possibly cause trouble ? > > if you do not want ot use hugepages hw:mem_page_size=small is a good > default but just be aware that if the > vm has a numa topology then memory over subsction is not supproted in > openstack. i.e. you cannot use cpu pinning > or any other feature that requriees a numa topoplogy like virtual > persistent memory and also use memory over subscription. > Got it. > > assuming these event do not corralate with vm boots then i woudl > investiagte the cgroup memory limits you set on teh ovs and compute service > cgroups. if they are correatlted with vm boots check if the vm is numa > affined and if it is which page size is requested. > ir its hw:mem_page_size=small then you might need to use the badly named > reserved_huge_pages config option to reserve 4k pages for the host per numa > node. > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_huge_pages > e.g. reserve 4G on node 0 and 1 > reserved_huge_pages = node:0,size:4,count:1048576 > reserved_huge_pages = node:1,size:4,count:1048576 > the sum of all the 4k page size reservation should equal the value of > reserved_host_memory_mb > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_memory_mb Currently I have reserved_host_memory_mb with 64GB memory reserved for host and no oversubscription i.e memory over provisioning factor set to 1.0 in compute nodes. > > > this is only really needed where you are usign numa instances since > reserved_host_memory_mb dose not account > for the host numa toplogy so it will not prevent the numa node form being > exausted. > > if you are usign a amd epyc system and the NPS( numa per socket) bios > option set to say 4 or 8 > on a dual or single socket system respecivly then the the 1TB of ram you > have on the host woudl be devided > into numa nodes of 128GB each which is very close to the 121 used you have > when you star seeing issues. > Yes I am using epyc system and checked in BIOS NPS is set to 1. > > nova currently tries to fill the numa nodes in order when you have numa > instances too which causes the OOM issue to manifest much sooner then > people often exepct due to the per numa nature of OOM reaper. > > that may not help you in your case but that is how i would approch > tracking down this issue. > This indeed helped a lot. It's been last 18 hours, and no OOM Killed observed till now. > > > > Ammad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian at citynetwork.eu Tue Feb 22 13:06:17 2022 From: florian at citynetwork.eu (Florian Haas) Date: Tue, 22 Feb 2022 14:06:17 +0100 Subject: [openstacksdk][magnum] Adding get_coe_cluster_by_id() method to openstack.cloud._coe In-Reply-To: <9983785c-d456-abd0-c696-c77b6bde1ee6@citynetwork.eu> References: <9983785c-d456-abd0-c696-c77b6bde1ee6@citynetwork.eu> Message-ID: Hello again, just taking the liberty to re-up on this one. :) I've rebased my patch on current master, but I'm still looking for input on whether it's actually on the right track. Artem, I hope you don't mind the CC. Cheers, Florian On 14/02/2022 13:41, Florian Haas wrote: > 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/ > 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/ 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 smooney at redhat.com Tue Feb 22 13:10:08 2022 From: smooney at redhat.com (Sean Mooney) Date: Tue, 22 Feb 2022 13:10:08 +0000 Subject: [nova] OOM Killed Processes In-Reply-To: References: <8cac2ca15914bc2be6373ea708c40d64bb6d85ce.camel@redhat.com> Message-ID: On Tue, 2022-02-22 at 17:51 +0500, Ammad Syed wrote: > On Mon, Feb 21, 2022 at 6:21 PM Sean Mooney wrote: > > > On Mon, 2022-02-21 at 12:24 +0500, Ammad Syed wrote: > > > Hi,, > > > > > > I am having trouble with my compute node that nova-compute and ovs > > process > > > are being killed by OOM. I have alot memory available in system. > > > > > > # free -g > > > total used free shared buff/cache > > > available > > > Mem: 1006 121 881 0 2 > > > 879 > > > Swap: 7 0 7 > > > > > > But I am seeing process are being killed in dmesg. > > > > > > [Sat Feb 19 03:46:26 2022] Memory cgroup out of memory: Killed process > > > 2080898 (ovs-vswitchd) total-vm:9474284kB, anon-rss:1076384kB, > > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2776kB oom_score_adj:0 > > > [Sat Feb 19 03:47:01 2022] Memory cgroup out of memory: Killed process > > > 2081218 (ovs-vswitchd) total-vm:9475332kB, anon-rss:1096988kB, > > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2780kB oom_score_adj:0 > > > [Sat Feb 19 03:47:06 2022] Memory cgroup out of memory: Killed process > > > 2081616 (ovs-vswitchd) total-vm:9473252kB, anon-rss:1073052kB, > > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2784kB oom_score_adj:0 > > > [Sat Feb 19 03:47:16 2022] Memory cgroup out of memory: Killed process > > > 2081940 (ovs-vswitchd) total-vm:9471236kB, anon-rss:1070920kB, > > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2776kB oom_score_adj:0 > > > [Sat Feb 19 03:47:16 2022] Memory cgroup out of memory: Killed process > > 6098 > > > (nova-compute) total-vm:3428356kB, anon-rss:279920kB, file-rss:9868kB, > > > shmem-rss:0kB, UID:64060 pgtables:1020kB oom_score_adj:0 > > > [Mon Feb 21 11:15:08 2022] Memory cgroup out of memory: Killed process > > > 2082296 (ovs-vswitchd) total-vm:9475372kB, anon-rss:1162636kB, > > > file-rss:11700kB, shmem-rss:0kB, UID:0 pgtables:2864kB oom_score_adj:0 > > > > > > Any advice on how to fix this ? Also any best practices document on > > > configuring memory optimizations in nova compute node. > > so one thing to note is that the OOM reaper service runs per numa node > > so the gloable free memory values are not really what you need to look at. > > > > croups/systemd also provide ways to limit the max memory a process/cgroup > > tree can consume > > > > so your first stp shoudl be to determin if the oom event was triggered by > > exaustign the memroy in > > a specific numa node or if you are hitting a differnt cgroup memory limit. > > > > As the logs suggest, it looks like the memory of cgroup is exhausted. The > memory of system.slice cgroup is 4G and user.slice is 2G by default. I have > increased system.slice to 64GB. ack this seam so be out side the scope of nova then. nova does not magne host cgroups libvirt does create cgroups for the vms but nova has not role in any cgroup management. > > > > > > in terms fo how to optimisze memroy it really depend on what your end goal > > is here. > > > > obviously we do not want ovs or nova-compute to be killsed in general. > > the virtaul and reseden memory for ovs is in the 10 to 1 GB range so that > > is not excessively large. > > > > that also should not be anywhere near the numa limit but if you were > > incorrectly creating numa affinged > > vms without seting hw:mem_page_size via nova then that could perhaps > > tirgger out of memory events > > > > Currently I am not using any page_size in my flavors. ack > > > > > effectivly with openenstack if your vm is numa affined eiter explictly via > > hw:numa_nodes extra specs or implictly via > > cpu pinning or otherwise then you must define that the memory is tracked > > using the numa aware path which requires > > you do defien hw:mem_page_size in the flaovr or hw_mem_page_size in the > > image. > > > > I am only using CPU soft pinning (vcpu placement) i.e cpu_shared_set. > However I have only configured hw:cpu_sockets='2' in flavors to make two > sockets for VM. This helps in effective cpu utilization in windows hosts. > However in VM I can only see one numa node of memory. Will this possibly > cause trouble ? no it should not. hw:cpu_sockets='2' alters the cpu toplogy but does not modify the guest virtual numa toplogy. by default all guest will be reproted as having 1 numa node but without requesting a numa toptopogy, directly or indirectly we will not provide any numa affintiy by default. old servers (12+ years old) with a front side bus architture had multipel sockets per numa node since the memory contoler was located on the north bridge. while this is not a common toplogy these days i woudl not expect it to have any negitve performance impacts on the vm or windwos running itn the vm. setting hw:cpu_sockets='1' woudl also likely improved the windwos guest cpu utiliastion while being more typical of a real host topology but i doubt you will see any meaning full perfromacne delta. i generally recommend setting hw:cpu_sockets equal to the number of numa nodes more out of consitancy then anything elese. if you expclitly have mulitipel numa nodes hw:numa_nodes=2 then hw:cpu_sockets='2' can help the guest kernel make better schduilg decisions but i dont think hw:cpu_sockets='2' when the guest has 1 numa node will degrade the perfroamce. > > > > > > if you do not want ot use hugepages hw:mem_page_size=small is a good > > default but just be aware that if the > > vm has a numa topology then memory over subsction is not supproted in > > openstack. i.e. you cannot use cpu pinning > > or any other feature that requriees a numa topoplogy like virtual > > persistent memory and also use memory over subscription. > > > > Got it. > > > > > > assuming these event do not corralate with vm boots then i woudl > > investiagte the cgroup memory limits you set on teh ovs and compute service > > cgroups. if they are correatlted with vm boots check if the vm is numa > > affined and if it is which page size is requested. > > ir its hw:mem_page_size=small then you might need to use the badly named > > reserved_huge_pages config option to reserve 4k pages for the host per numa > > node. > > > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_huge_pages > > e.g. reserve 4G on node 0 and 1 > > reserved_huge_pages = node:0,size:4,count:1048576 > > reserved_huge_pages = node:1,size:4,count:1048576 > > the sum of all the 4k page size reservation should equal the value of > > reserved_host_memory_mb > > > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_memory_mb > > > Currently I have reserved_host_memory_mb > > with > 64GB memory reserved for host and no oversubscription i.e memory over > provisioning factor set to 1.0 in compute nodes. ack since you are not numa ffinign the vms that should be sufficent it really does seam that this is just related to the cgroup config on the host. > > > > > > > > this is only really needed where you are usign numa instances since > > reserved_host_memory_mb dose not account > > for the host numa toplogy so it will not prevent the numa node form being > > exausted. > > > > if you are usign a amd epyc system and the NPS( numa per socket) bios > > option set to say 4 or 8 > > on a dual or single socket system respecivly then the the 1TB of ram you > > have on the host woudl be devided > > into numa nodes of 128GB each which is very close to the 121 used you have > > when you star seeing issues. > > > > Yes I am using epyc system and checked in BIOS NPS is set to 1. ack so in that case you likely are not exausting the numa node > > > > > nova currently tries to fill the numa nodes in order when you have numa > > instances too which causes the OOM issue to manifest much sooner then > > people often exepct due to the per numa nature of OOM reaper. > > > > that may not help you in your case but that is how i would approch > > tracking down this issue. > > > > This indeed helped a lot. It's been last 18 hours, and no OOM Killed > observed till now. based on what you have said tweakign the system and user slices is proably the way to adress this. it sound like your nova config is fine for how you are creating vms. im not sure how you have deployed openstack/openvswtich in this case but i suspect the cgroups limist the install or you applied as part fo the instalation are jsut a little too low and if you increase them it will work ok. > > > > > > > > Ammad > > > > From rosmaita.fossdev at gmail.com Tue Feb 22 13:41:58 2022 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 22 Feb 2022 08:41:58 -0500 Subject: [cinder] reminder: this week's meeting in video+IRC Message-ID: Quick reminder that this week's Cinder team meeting on Wednesday 23 February, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. These are the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. * The meeting will be recorded. connection info: https://bluejeans.com/3228528973 meeting agenda: https://etherpad.opendev.org/p/cinder-yoga-meetings cheers, brian From mahati.chamarthy at gmail.com Tue Feb 22 04:13:44 2022 From: mahati.chamarthy at gmail.com (Mahati Chamarthy) Date: Tue, 22 Feb 2022 09:43:44 +0530 Subject: Call for Outreachy OpenStack mentors - May 2022 round In-Reply-To: References: Message-ID: Hi Sofia, Apologies for the delayed response. We have moved on from the wiki page to the Outreachy website. Please submit your project proposals over here https://www.outreachy.org/communities/cfp/openstack/ Best, Mahati On Mon, Feb 21, 2022 at 10:52 PM Dmitry Tantsur wrote: > Hi Sofia, > > I must admit, I was not even aware of this page. I know that there is a > desire to move away from wiki, and in the end, each project has to decide > separately, if they have ideas AND free mentors. > > Dmitry > > ??, 17 ????. 2022 ?. ? 22:32, Sofia Enriquez : > >> Greetings, >> Are we going to update https://wiki.openstack.org/wiki/Internship_ideas ? >> Best Regards, >> Sofia >> >> >> On Mon, Feb 14, 2022 at 1:18 PM Mahati Chamarthy < >> mahati.chamarthy at gmail.com> wrote: >> >>> 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 >>> or Dmitry Tantsur >>> >>> Best, >>> Mahati >>> >> >> >> -- >> >> Sof?a Enriquez >> >> she/her >> >> Software Engineer >> >> Red Hat PnT >> >> IRC: @enriquetaso >> @RedHat Red Hat >> Red Hat >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.rosser at rd.bbc.co.uk Tue Feb 22 15:18:08 2022 From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser) Date: Tue, 22 Feb 2022 15:18:08 +0000 Subject: [openstack-ansible] LetsEncrypt OS Ansible Ussuri In-Reply-To: <8C92B8B1-F0AF-4CB4-9C01-FD4BAA6BA913@viarezo.fr> References: <4997625f-e36d-96c3-3a2a-6982b2c51d15@rd.bbc.co.uk> <258D844F-72E6-415A-A7CA-858491021DD8@viarezo.fr> <03f65b29-b5be-2b45-7482-4936359cedb4@rd.bbc.co.uk> <8C92B8B1-F0AF-4CB4-9C01-FD4BAA6BA913@viarezo.fr> Message-ID: Yes, in a standard deployment this would request 3 identical certificates which would be inside the rate limit. This keeps the complexity down and decouples the haproxy nodes from each other during the deployment. The compromise is requesting a fresh certificate per haproxy instance. In some situations it might be possible to add a haproxy instance specific additional domain name to each certificate by passing a templated value to haproxy_ssl_letsencrypt_setup_extra_params making each certificate unique. openstack-ansible exposes all of these role defaults for you to override through user_variables.yml as necessary. > / > / > Does that mean that the the deployment is limited to 5 HAProxy nodes ? > Normally we are safe tho, we have 3. > > Concerning, the?timeout values, we?ll make sure to check them out. > We?ll upgrade to Wallaby or Xena by the end of the year in any case. > > Thanks, > Marc-Antoine > >> Le 22 f?vr. 2022 ? 10:35, Jonathan Rosser >> a ?crit : >> >> Hi Marc-Antione, >> >> No problem. I would recommend adding --staging to >> haproxy_ssl_letsencrypt_setup_extra_params whilst you get the >> letsencrypt support working. You will not get a proper certificate >> with that flag but it will bypass the letsencrypt rate limit so you >> can have as many tests as you need. >> >> It would be also worth checking the timeout values on later branches, >> Ussuri is now in extended-maintenance so not receiving back ported >> bug fixes. >> >> See for example >> https://github.com/openstack/openstack-ansible/blob/stable/xena/inventory/group_vars/haproxy/haproxy.yml#L248-L258 >> >> On 21/02/2022 18:51, Marc-Antoine Godde wrote: >>> Thanks for your huge help. It?s is exactly what we wanted to try. >>> We?ll feel?more confident. >>> >>> Best, >>> Marc-Antoine >>> >>> >>> >>>> Le 21 f?vr. 2022 ? 18:52, Jonathan Rosser >>>> a ?crit : >>>> >>>> Hi Marc-Antoine, >>>> >>>> For setting the horizon acl, see >>>> https://docs.openstack.org/openstack-ansible/ussuri/user/security/index.html >>>> >>>> Specifically: >>>> >>>> "Copy the whole variable haproxy_default_services from >>>> /opt/openstack-ansible/inventory/group_vars/haproxy/haproxy.yml to >>>> /etc/openstack_deploy/group_vars/haproxy/haproxy_all.yml and update >>>> the section for horizon to include the ACL redirects http-01 >>>> challenges to the HAProxy letsencrypt backend as follows: ......" >>>> >>>> It is correct that this is not necessary in later releases and the >>>> letsencrypt support is more straightforward to configure in Victoria. >>>> >>>> You can also join #openstack-ansible IRC channel for some real-time >>>> help if needed. >>>> >>>> Jonathan. >>>> >>>> On 21/02/2022 17:25, Marc-Antoine Godde wrote: >>>>> Hello, >>>>> >>>>> I have a question on how to setup LetsEncrypt with OpenStack >>>>> Ansible. We are still on OpenStack Ussuri. >>>>> >>>>> We added the following variables to user_variables.yml. >>>>> >>>>> ================================================================================== >>>>> haproxy_ssl_letsencrypt_enable: True >>>>> haproxy_ssl_letsencrypt_install_method: "distro" >>>>> haproxy_ssl_letsencrypt_setup_extra_params: "--http-01-address {{ >>>>> ansible_host }} --http-01-port 8888" >>>>> haproxy_ssl_letsencrypt_email: email at example.com >>>>> haproxy_interval: 2000 >>>>> >>>>> user avatar user avatar >>>>> haproxy_extra_services: >>>>> ? # an internal only service for acme-challenge whose backend is >>>>> certbot on the haproxy host >>>>> ? - service: >>>>> haproxy_service_name: letsencrypt >>>>> haproxy_backend_nodes: >>>>> ? ? ? ? - name: localhost >>>>> ? ? ? ? ? ip_addr: {{ ansible_host }} ? ?#certbot binds to the >>>>> internal IP >>>>> ? ? ? backend_rise: 1 ?#quick rise and fall time for multinode >>>>> deployment to succeed >>>>> ? ? ? backend_fall: 2 >>>>> ? ? ? haproxy_bind: >>>>> ? ? ? ? - 127.0.0.1 ?#bind to 127.0.0.1 as the local internal >>>>> address ?will be used by certbot >>>>> ? ? ? haproxy_port: 8888 #certbot is configured with http-01-port >>>>> to be 8888 >>>>> haproxy_balance_type: http >>>>> ================================================================================== >>>>> >>>>> Yet, Horizon?config for HAproxy is?already defined in the default >>>>> vars >>>>> (https://github.com/openstack/openstack-ansible/blob/stable/ussuri/inventory/group_vars/haproxy/haproxy.yml) >>>>> and we don?t know where ta add the required ACL to redirect the >>>>> traffic from 80 port to 8888: >>>>> >>>>> ==================================== >>>>> haproxy_frontend_acls: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #use a >>>>> frontend ACL specify the backend to use for acme-challenge >>>>> ? letsencrypt-acl: >>>>> ? ? rule: "path_beg /.well-known/acme-challenge/" >>>>> ? ? backend_name: letsencrypt >>>>> ==================================== >>>>> >>>>> We know that this is fixed in OpenStack Ansible Victoria. Is it >>>>> possible with Ussuri tho ? >>>>> >>>>> Many thanks, >>>>> Best, >>>>> Marc-Antoine Godde >>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Tue Feb 22 16:56:15 2022 From: zigo at debian.org (Thomas Goirand) Date: Tue, 22 Feb 2022 17:56:15 +0100 Subject: [all] [requirements] Analysing inflation of requirements in os-brick (was: Artificially inflated requirements in os-brick) In-Reply-To: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> Message-ID: On 2/18/22 17:42, Thomas Goirand wrote: > Hi, > > I've been quite surprised to see $topic. Most requirements for os-brick > are now to be found in Yoga only. I've asked why, and I've been told > that the reason is because "we've been testing with the new versions > only for the number of months". > > Well, the reason why someone would increase a minimum requirement *must* > be only because of the need of a new feature, and should be treated with > care. Otherwise, this makes upgrading very dangerous and annoying to do. > As much as possible, I would strongly recommend that any dependency in > Stable can be found in Stable-1 (only when a new feature is mandatory, > then it's ok-ish to require that new version, though I would advocate > for a possible fallback if that's not too complex to write). > > Now, if that's the path we're taking, all is going backward 5 years ago, > and then my thinking is: we must reintroduce lower-constraints testing > ASAP. > > Your thoughts everyone? To demonstrate what I'm saying (that we got inflated versions for no reasons), I've analysed some of the version bumps by quickly reviewing the matching git commits. -oslo.concurrency>=4.4.0 # Apache-2.0 +oslo.concurrency>=4.5.0 # Apache-2.0 A single commit: "Add support for non-blocking locks" The lock() function of lockutils gained a blocking=True default param, that one has to set to False to use the new feature. A quick grep in the os-brick code shows only os_brick/initiator/utils.py uses that function, and doesn't have the "False" blocking param. -oslo.context>=3.1.1 # Apache-2.0 +oslo.context>=3.4.0 # Apache-2.0 Only this commit is relevant: https://review.opendev.org/c/openstack/oslo.context/+/800852 this is a bug fix, which was backported to all branches since Ussuri. -oslo.log>=4.4.0 # Apache-2.0 +oslo.log>=4.6.1 # Apache-2.0 - One patch that removes the u in u'' strings... - One config option typo fix. - Some "we run on Python3" commits. - More cosmetic fixes... -oslo.i18n>=5.0.1 # Apache-2.0 +oslo.i18n>=5.1.0 # Apache-2.0 - A six removal patch. - Some "we use python3" patches. - Some more "we are currently in Xena" patches. At this point I'm stopping the analysis. It's crystal clear that os-brick requirement version bumps are *NOT* beacause os-brick needs any new feature in these libs, and that it's really artificially inflated just because of the thinking that the gate isn't using older versions ... so we don't easlily know about any possible breakage. Reality checked: I don't see why it would break. However, it'd be nice to have some more automated ways to do such checks. These were easily analysed, but it would be harder for eg Eventlet to know if os-brick really needs version 0.30.1. However, it should be a way more easy for a developer of os-brick to know if his change is affecting the minimum requirements. IMO it's at this moment that the bump should happen. I do understand the "we only tests with the higher bounds", however, again, this may affect upgrades, and it's not reflecting any reality. Once more: this is not against os-brick, but a higher level thinking. Anyone (even someone not contributing in os-brick) is welcome in this discussion, as I'm trying to discuss here what the OpenStack *policy* should be. I'm now thinking: we should re-do lower constraints checks!!! Your thoughts anyone? Cheers, Thomas Goirand (zigo) From foundjem at ieee.org Tue Feb 22 17:48:02 2022 From: foundjem at ieee.org (Armstrong Foundjem) Date: Tue, 22 Feb 2022 12:48:02 -0500 Subject: SUBJECT: [ ironic][QA] Cycle With Intermediary Unreleased Deliverables References: Message-ID: Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Yoga cycle: ironic-prometheus-exporter ironic-python-agent-builder ironic-ui networking-baremetal networking-generic-switch patrole Those should be released ASAP, and in all cases before the March 10th deadline, so that we have a release to include in the final Yoga release. Best regards, Armstrong Foundjem irc: @armstrong From fungi at yuggoth.org Tue Feb 22 17:52:26 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 22 Feb 2022 17:52:26 +0000 Subject: [all] [requirements] Analysing inflation of requirements in os-brick (was: Artificially inflated requirements in os-brick) In-Reply-To: References: <92ac9777-74a7-f01c-bd7b-a8761edc6218@debian.org> Message-ID: <20220222175225.khtmkawocicqksyq@yuggoth.org> On 2022-02-22 17:56:15 +0100 (+0100), Thomas Goirand wrote: [...] > I'm now thinking: we should re-do lower constraints checks!!! > > Your thoughts anyone? The reason they were dropped is that the current way we install Python library dependencies for testing is to rely on pip, and when pip eventually grew a consistent dependency solver it quickly pointed out that we weren't testing what we thought we were. Back when pip was willing to install mutually-conflicting versions of transitive dependencies, the lower bounds we claimed to test were a convenient fiction. There is no automated tool available which can find a coherent set of lower bounds; pip is focused on finding the highest available versions which meet specified ranges. One reason such a tool doesn't exist though is that, as you choose earlier and earlier versions of packages, you also effectively travel back in time to older packaging standards with less available data for making appropriate dependency decisions (and you'll eventually hit bedrock in places where nobody was declaring minimum versions so you get foo==0.0.1 for lots of foo). It's this "time travel" aspect which is most problematic, because dependencies are declared within the packages themselves, so there is no way to go back later and update the minimum requirements for an already published version. It's probably feasible to hand curate, with lots of trial and error, a coherent lower bound set for a project with a moderate number of dependencies, but every time you update it you have to repeat that same cumbersome manual experimentation due to ripple effects from interdependencies between the packages. At OpenStack's collective scale, it borders on impossible. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From gmann at ghanshyammann.com Tue Feb 22 18:41:10 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 22 Feb 2022 12:41:10 -0600 Subject: [all][tc] Zed TC-PTG Planning Message-ID: <17f22bcc50d.dc214987454540.4578480937628902952@ghanshyammann.com> Hello Everyone, As you already know that the Zed cycle virtual PTG will be held between 4th - 8th April[1]. I have started the preparation for the Technical Committee PTG sessions. Please do the following: 1. Fill the below doodle poll as per your availability. Please fill it in soon as the deadline to book the slot is March 11th. - https://doodle.com/poll/gz4dy67vmew5wmn9 2. Add the topics you would like to discuss to the below etherpad. - https://etherpad.opendev.org/p/tc-zed-ptg NOTE: this is not limited to TC members only; I would like all community members to fill the doodle poll and, add the topics you would like or want TC members to discuss in PTG. [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027051.html -gmann From gmann at ghanshyammann.com Tue Feb 22 18:41:16 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 22 Feb 2022 12:41:16 -0600 Subject: [tc][ptl] TC + Community Leaders interaction in Zed Virtual PTG Message-ID: <17f22bcdbf2.b05d02e2454544.7809265565474276350@ghanshyammann.com> Hello Everyone, We had successful TC+Community leaders interaction sessions in the last PTG, and we will continue the same for Zed cycle PTG also. I have created the below etherpad with the draft agenda, If you as PTL or project representatives or SIG Chair and would like to attend this session, please add your name: - https://etherpad.opendev.org/p/tc-ptl-interaction-zed Also, I have created the doodle poll to select the best suitable time. It will be for two hours (single or two sessions) either on Monday or Tuesday. Please add your preference in the below doodle poll (including TC members): - https://doodle.com/poll/dcer6i3wk2b8eim3 -gmann From ozzzo at yahoo.com Tue Feb 22 21:13:15 2022 From: ozzzo at yahoo.com (Albert Braden) Date: Tue, 22 Feb 2022 21:13:15 +0000 (UTC) Subject: [kolla][rabbitmq] Trouble with RMQ 3.8 in Train References: <277218432.1566379.1645564395789.ref@mail.yahoo.com> Message-ID: <277218432.1566379.1645564395789@mail.yahoo.com> We are running kolla-ansible Train and I successfully followed the recommendations in [1] to change our RMQ settings, and our RMQ works a lot better now, but one of the recommendations is to run RMQ 3.8 and so far I haven?t been able to make it work. Our working RMQ container has these settings in the Dockerfile to force 3.7 and the appropriate erlang version: 'erlang-21.3*', 'rabbitmq-server-3.7.23*' I changed those settings to allow 3.8: 'rabbitmq-server-3.*.*el8ost*' Now my RMQ container fails to start with: {"log":"20:29:28.440 [error] Supervisor rabbit_prelaunch_sup had child prelaunch started with rabbit_prelaunch:run_prelaunch_first_phase() at undefined exit with reason no_configuration_schema_found in context start_error\r\n","stream":"stdout","time":"2022-02-22T20:29:28.441064637Z"} What am I missing? [1] https://wiki.openstack.org/wiki/Large_Scale_Configuration_Rabbit From syedammad83 at gmail.com Wed Feb 23 07:24:30 2022 From: syedammad83 at gmail.com (Ammad Syed) Date: Wed, 23 Feb 2022 12:24:30 +0500 Subject: [neutron] Stale Tap Ports Message-ID: Hi, I am using neutron 19.1 and ovn 21.09. There is a strange behavior I am seeing on compute nodes that ovs logs shows below logs 2022-02-23T06:14:06.426Z|00226|bridge|WARN|could not open network device tapea0dca9a-32 (No such device) 2022-02-23T06:14:06.428Z|00227|bridge|WARN|could not open network device tapaeaa1749-b5 (No such device) 2022-02-23T06:14:06.429Z|00228|bridge|WARN|could not open network device tap53f06ea0-70 (No such device) 2022-02-23T06:14:06.431Z|00229|bridge|WARN|could not open network device tap724cf0cc-7b (No such device) 2022-02-23T06:14:06.433Z|00230|bridge|WARN|could not open network device tap18864125-6d (No such device) In the ovs-vsctl show I also see alot of ports with these status. Port tapaeaa1749-b5 Interface tapaeaa1749-b5 error: "could not open network device tapaeaa1749-b5 (No such device)" Port tap18864125-6d Interface tap18864125-6d error: "could not open network device tap18864125-6d (No such device)" Port tap54415fc0-dd Interface tap54415fc0-dd error: "could not open network device tap54415fc0-dd (No such device)" I have checked in neutron port list and there is no port found for these tap interfaces. openstack port list --long | grep -i 18864125-6d I have checked in database in ports table, there is also no ports there with these ids. mysql> select * from ports where id like '%18864125-6d%'; These ports even show on compute node even if there is no instance running on it. Are these stale ports ? If yes, is there any tool or utility to run audit and delete these ports ? Ammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkopec at redhat.com Wed Feb 23 08:36:57 2022 From: mkopec at redhat.com (Martin Kopec) Date: Wed, 23 Feb 2022 09:36:57 +0100 Subject: [qa] Zed PTG planning Message-ID: Hi everyone, virtual PTG for the Zed cycle will be held between 4th - 8th April [1]. I've created a Doodle [2] to collect the best time slots for our team. Please fill it in rather sooner than later (the deadline for team signup is March 11th). I've also created an etherpad [3] to collect ideas/topics for the PTG sessions. If you have anything to discuss, please don't hesitate to write it there. [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027051.html [2] https://doodle.com/poll/q5yzatzh45brt5v2 [3] https://etherpad.opendev.org/p/qa-zed-ptg Thanks, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA IM: kopecmartin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Wed Feb 23 09:09:59 2022 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 23 Feb 2022 09:09:59 +0000 Subject: [kolla][rabbitmq] Trouble with RMQ 3.8 in Train In-Reply-To: <277218432.1566379.1645564395789@mail.yahoo.com> References: <277218432.1566379.1645564395789.ref@mail.yahoo.com> <277218432.1566379.1645564395789@mail.yahoo.com> Message-ID: You will need changes in kolla and kolla-ansible. You might try comparing with ussuri, since we use 3.8 in ussuri. Upgrading to ussuri and beyond would be (far) better still. Mark On Tue, 22 Feb 2022 at 21:17, Albert Braden wrote: > > We are running kolla-ansible Train and I successfully followed the recommendations in [1] to change our RMQ settings, and our RMQ works a lot better now, but one of the recommendations is to run RMQ 3.8 and so far I haven?t been able to make it work. Our working RMQ container has these settings in the Dockerfile to force 3.7 and the appropriate erlang version: > > 'erlang-21.3*', > 'rabbitmq-server-3.7.23*' > > I changed those settings to allow 3.8: > > 'rabbitmq-server-3.*.*el8ost*' > > Now my RMQ container fails to start with: > > {"log":"20:29:28.440 [error] Supervisor rabbit_prelaunch_sup had child prelaunch started with rabbit_prelaunch:run_prelaunch_first_phase() at undefined exit with reason no_configuration_schema_found in context start_error\r\n","stream":"stdout","time":"2022-02-22T20:29:28.441064637Z"} > > What am I missing? > > [1] https://wiki.openstack.org/wiki/Large_Scale_Configuration_Rabbit > From stephenfin at redhat.com Wed Feb 23 11:28:39 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Wed, 23 Feb 2022 11:28:39 +0000 Subject: [infra] Gerrit email outage? Message-ID: <07d15c3abfea5bce7fa8f256c753753d3f4027d6.camel@redhat.com> I haven't received any emails from Gerrit since midday (UTC) yesterday. Chatting on IRC, it seems I'm not alone. Has something changed in Gerrit or is this a simple outage? Cheers, Stephen From lokendrarathour at gmail.com Wed Feb 23 11:50:31 2022 From: lokendrarathour at gmail.com (Lokendra Rathour) Date: Wed, 23 Feb 2022 17:20:31 +0530 Subject: [Triple0] Upgrade Error Message-ID: Hi Team, we are trying to upgrade Triple0 Train to Ussuri. Undercloud upgrade prepare is done successfully and when we are going for overcloud upgrade getting below error: * len(inspect.getargspec(type_).args) > 1)2022-02-23 16:49:50.959 187217 INFO tripleoclient.utils.utils [-] Running Ansible playbook: /usr/share/ansible/tripleo-playbooks/cli-update-params.yaml, Working directory: /tmp/tripleoj7rvp51m, Playbook directory: /usr/share/ansible/tripleo-playbooksPLAY [Update Parameters] *******************************************************2022-02-23 16:49:51.858966 | 5254007d-0040-f631-88e7-000000000008 | TASK | Check for required inputs2022-02-23 16:49:51.895961 | 5254007d-0040-f631-88e7-000000000008 | SKIPPED | Check for required inputs | localhost2022-02-23 16:49:51.897803 | 5254007d-0040-f631-88e7-000000000008 | TIMING | Check for required inputs | localhost | 0:00:00.096595 | 0.04s2022-02-23 16:49:51.901827 | 5254007d-0040-f631-88e7-000000000009 | TASK | Set parameters fact2022-02-23 16:49:51.949091 | 5254007d-0040-f631-88e7-000000000009 | OK | Set parameters fact | localhost2022-02-23 16:49:51.951583 | 5254007d-0040-f631-88e7-000000000009 | TIMING | Set parameters fact | localhost | 0:00:00.150375 | 0.05s2022-02-23 16:49:51.956146 | 5254007d-0040-f631-88e7-00000000000b | TASK | Update parameters2022-02-23 16:50:12.542028 | 5254007d-0040-f631-88e7-00000000000b | FATAL | Update parameters | localhost | error={"changed": false, "error": "Error validating environment for plan overcloud: ERROR: Property error: resources.InternalApiVirtualIP.properties: Unknown Property DnsName\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 891, in __call__\n request, **action_args)\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in dispatch\n return method(*args, **kwargs)\n File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\", line 56, in handle_stack_method\n return handler(controller, req, **kwargs)\n File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\", line 633, in validate_template\n raise exc.HTTPBadRequest(result['Error'])\n", "msg": "Error updating parameters for plan overcloud: Error validating environment for plan overcloud: ERROR: Property error: resources.InternalApiVirtualIP.properties: Unknown Property DnsName\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 891, in __call__\n request, **action_args)\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in dispatch\n return method(*args, **kwargs)\n File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\", line 56, in handle_stack_method\n return handler(controller, req, **kwargs)\n File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\", line 633, in validate_template\n raise exc.HTTPBadRequest(result['Error'])\n", "success": false}2022-02-23 16:50:12.544560 | 5254007d-0040-f631-88e7-00000000000b | TIMING | Update parameters | localhost | 0:00:20.743350 | 20.59s* Command used to run the overcloud upgrade prepare: *(undercloud) [stack at undercloud ~]$ cat upgrade_overcloud_prepare.shopenstack overcloud upgrade prepare --templates \ -r /home/stack/templates/roles_data.yaml \ -n /home/stack/templates/network_data.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/templates/init-repo.yaml \ -e /home/stack/containers-prepare-parameter.yaml(undercloud) [stack at undercloud ~]$* *Document referred:*Upgrading to a Next Major Release ? TripleO 3.0.0 documentation (openstack.org) Any support here, please. -- ~ Lokendra skype: lokendrarathour -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Wed Feb 23 11:51:08 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 23 Feb 2022 12:51:08 +0100 Subject: [infra] Gerrit email outage? In-Reply-To: <07d15c3abfea5bce7fa8f256c753753d3f4027d6.camel@redhat.com> References: <07d15c3abfea5bce7fa8f256c753753d3f4027d6.camel@redhat.com> Message-ID: I am getting them on gmail.com - maybe redhat.com is affected? -yoctozepto On Wed, 23 Feb 2022 at 12:30, Stephen Finucane wrote: > > I haven't received any emails from Gerrit since midday (UTC) yesterday. Chatting > on IRC, it seems I'm not alone. Has something changed in Gerrit or is this a > simple outage? > > Cheers, > Stephen > > From stephenfin at redhat.com Wed Feb 23 12:03:35 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Wed, 23 Feb 2022 12:03:35 +0000 Subject: [infra] Gerrit email outage? In-Reply-To: References: <07d15c3abfea5bce7fa8f256c753753d3f4027d6.camel@redhat.com> Message-ID: On Wed, 2022-02-23 at 12:51 +0100, Rados?aw Piliszek wrote: > I am getting them on gmail.com - maybe redhat.com is affected? > > -yoctozepto Yeah, I discussed this with frickler on #opendev. Looks like a redhat.com issue. Stephen > > On Wed, 23 Feb 2022 at 12:30, Stephen Finucane wrote: > > > > I haven't received any emails from Gerrit since midday (UTC) yesterday. Chatting > > on IRC, it seems I'm not alone. Has something changed in Gerrit or is this a > > simple outage? > > > > Cheers, > > Stephen > > > > > From senrique at redhat.com Wed Feb 23 13:14:17 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 23 Feb 2022 10:14:17 -0300 Subject: [cinder] Bug deputy report for week of 02-23-2022 Message-ID: This is a bug report from 02-03-2022 to 02-23-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting The bug report is back! Today's meeting is on video. ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1960206 "[RBD] Amend the formula of retrieving total_capacity for a rbd pool." Fix proposed to master. Assigned to Gorka. - https://bugs.launchpad.net/os-brick/+bug/1961102 "NVMe-oF doesn't disconnect." Unassigned. Problem with request ID: - https://bugs.launchpad.net/cinder/+bug/1960329 "Wrong request ID on API middleware filters." Fix proposed to master. Assigned to Gorka. - https://bugs.launchpad.net/cinder/+bug/1960021 "Request to list REST API versions doesn't return the request id." Fix proposed to master. Assigned to Gorka. - https://bugs.launchpad.net/cinder/+bug/1960020 "Duplicated request ids in the logs." Fix proposed to master. Assigned to Gorka. - https://bugs.launchpad.net/cinder/+bug/1960019 "REST API responses have wrong request ID when using noauth." Fix proposed to master. Assigned to Gorka. Low - https://bugs.launchpad.net/cinder/+bug/1960315 "[IBM Storwize] Delete volume issue in reverse replication." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1960314 "[IBM Storwize] Resize issue in reverse replication." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1961548 "[Storwize] Fix multiple SVC CLI calls to create volume operation." Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1959178 "SolidFire: Error message logged when creating volume from image." Fix proposed to master. Have a +2! Wishlist - https://bugs.launchpad.net/cinder/+bug/1960574 "Provide back-end Qos support for spdk driver." Unassigned. Incomplete - https://bugs.launchpad.net/cinder/+bug/1959350 " [RBD] Volume status becomes available after force delete." Unassigned. Invalid - https://bugs.launchpad.net/cinder/+bug/1961685 "cinder-volume.service crashes: no module named 'wrapt'." If I'm missing bugs please let me know! Cheers! -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfosardo at gmail.com Wed Feb 23 13:27:35 2022 From: elfosardo at gmail.com (Riccardo Pittau) Date: Wed, 23 Feb 2022 14:27:35 +0100 Subject: SUBJECT: [ ironic][QA] Cycle With Intermediary Unreleased Deliverables In-Reply-To: References: Message-ID: Thank you for the reminder Armstrong, the ironic projects releases have been submitted Ciao Riccardo On Tue, Feb 22, 2022 at 6:53 PM Armstrong Foundjem wrote: > Quick reminder that we'll need a release very soon for a number of > deliverables following a cycle-with-intermediary release model but which > have not done *any* release yet in the Yoga cycle: > > ironic-prometheus-exporter > ironic-python-agent-builder > ironic-ui > networking-baremetal > networking-generic-switch > patrole > > Those should be released ASAP, and in all cases before the March 10th > deadline, so that we have a release to include in the final Yoga release. > > Best regards, > Armstrong Foundjem > irc: @armstrong > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Wed Feb 23 16:07:36 2022 From: amy at demarco.com (Amy Marrich) Date: Wed, 23 Feb 2022 10:07:36 -0600 Subject: [Diversity] Diversity and Inclusion Meeting -change - short notice Message-ID: Due to a conflict from another member and my decision to take PTO to play with the dogs, we are moving the March meeting to this Friday, February 25th at 16:00 UTC. The meeting will be held on video at https://meetpad.opendev.org/osf- diversity-and-inclusion as recently voted on and the agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please join us! Thanks, Amy (spotz) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjensas at redhat.com Wed Feb 23 16:20:33 2022 From: hjensas at redhat.com (Harald Jensas) Date: Wed, 23 Feb 2022 17:20:33 +0100 Subject: [TripleO] Offline Installation Support In-Reply-To: References: Message-ID: <5ff25e47-1a0d-6b42-2f49-336ba68ffba9@redhat.com> On 2/16/22 13:58, Anirudh Gupta wrote: > Hi Team, > > We have successfully done POC on deploying my TripleO Train HA Setup > with Baremetal Provisioning on Overcloud Node as well. > > We would like to thank Tripleo community members for helping us and > resolving all our concerns at all times. > > Moving?forward, we need to deploy the setup on the Lab environment for > which I need some support as well. > > We don't have internet in Lab machines, all that we have is access to a > central server (staging) which?has internet access and we can download > all the requirements over there. > > Queries: > > * Is there any feasible method to install Undercloud and Overcloud > Machines in complete offline mode? > * If yes, then > > 1. What are the steps to download all related stuff on the staging > server? I don't know the exact steps, and I am not aware of upstream documentation page explaining this. You will probalby want to use the 'rsync' tool to sync RDO RPM repositories and create a local repo on you staging machine. Sync packages, use `createrepo` tool to generate yum/dnf repo metadata. Then set up a webserver to make the repository available over HTTP. Search the internets for "Create local RPM repository / mirror", there are many generic guides that will help you. For containers you need to set up a local container registry. Then I would suggest useing the `skopeo`[1] tool to sync containers from the public registry to your local registry. > 2. What modifications would be required in undercloud/overcloud and > other configuration files to support this? > You need to set up the undercloud to use the RPM repositries on the staging server. Put config in /etc/yum.repos.d/*.repo files. Once the overcloud is deployed you would want to add the repo config there as well. You need to use a custom containers-prepare file when deploying the undercloud and overcloud, you must set the namespaces to point to your local registry. Something like this: parameter_defaults: ContainerImagePrepare: - push_destination: false set: name_prefix: openstack- name_suffix: '' namespace: staging.example.com:5000/tripleotrain neutron_driver: null tag: current-tripleo ... I would suggest generating the container prepare env file with the `openstack tripleo container image prepare` command[2] and then edit the generated file. [1] https://github.com/containers/skopeo [2] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/container_image_prepare.html From wu.wenxiang at 99cloud.net Wed Feb 23 16:29:04 2022 From: wu.wenxiang at 99cloud.net (=?UTF-8?B?5ZC05paH55u4?=) Date: Thu, 24 Feb 2022 00:29:04 +0800 Subject: [all][elections][ptl][tc][Adjutant][Freezer][Heat][Magnum][Masakari][Monasca][Murano][OpenStack_Charms][Openstack_Chef][Senlin][Skyline][Solum][Trove][Venus][Watcher][Zaqar][Zun][Combined PTL/TC Zed cycle Election Nominations Last Days In-Reply-To: <17f094147e0.f5efb8e7168864.5996896917712641978@ghanshyammann.com> References: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com> <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> <17eff8a3ff3.d7c839108685.7403613792495141625@ghanshyammann.com> <17f094147e0.f5efb8e7168864.5996896917712641978@ghanshyammann.com> Message-ID: Hello, Ghanshyam I'm so sorry we missed this mail. I had added me in this page for Skyline project: https://etherpad.opendev.org/p/zed-leaderless Thanks Best Regards Wenxiang Wu ---- On Thu, 17 Feb 2022 13:40:32 -0600 Lance Albertson wrote ---- > Apologies for the delay as I'm behind on my email. I just submitted my candidacy even though I'm a few days late. Thanks- Thanks, Lance for your nomination. As nomination is closed now, TC will appoint the PTL. I have added your late candidacy in TC etherpad https://etherpad.opendev.org/p/zed-leaderless As the next step, TC will discuss and let you about the appointment. -gmann > On Tue, Feb 15, 2022 at 2:40 PM Ghanshyam Mann wrote: > Hello Everyone, > > ~1 hr left for nomination close, I am tagging the 17 projects in ML subject which left with the nomination. > > -gmann > > ---- On Tue, 15 Feb 2022 13:07:36 -0600 Ghanshyam Mann wrote ---- > > Hello Everyone, > > > > Less than 5 hours left for nomination end and we still need nominations for 21 projects (Zun and Masakari nomination are there but not passed the validation): > > > > - Adjutant Freezer Heat Magnum Masakari Monasca Murano OpenStack_Charms Openstack_Chef Release_Management Requirements Senlin Skyline Solum Swift Tripleo Trove Venus Watcher Zaqar Zun > > > > If you are maintainer of above projects, please do not delay the nomination or motivate the one you think should add nomination. > > > > -gmann & The OpenStack Technical Election Officials > > > > ---- On Mon, 14 Feb 2022 18:20:38 -0600 Ghanshyam Mann wrote ---- > > > 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 > > > > > > > > > > > > > > > > > -- > Lance AlbertsonDirectorOregon State University | Open Source Lab From gmann at ghanshyammann.com Wed Feb 23 16:47:11 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 23 Feb 2022 10:47:11 -0600 Subject: [all][elections][ptl][tc][Adjutant][Freezer][Heat][Magnum][Masakari][Monasca][Murano][OpenStack_Charms][Openstack_Chef][Senlin][Skyline][Solum][Trove][Venus][Watcher][Zaqar][Zun][Combined PTL/TC Zed cycle Election Nominations Last Days In-Reply-To: References: <17efac0af7a.b5f15afd359184.6173978686302630337@ghanshyammann.com> <17efec87186.d3c11da22907.8470046444752162440@ghanshyammann.com> <17eff8a3ff3.d7c839108685.7403613792495141625@ghanshyammann.com> <17f094147e0.f5efb8e7168864.5996896917712641978@ghanshyammann.com> Message-ID: <17f277ac4c1.11a6558e226362.1043151090591586960@ghanshyammann.com> Thanks, Wenxiang for continuing leading Skyline. As the next step, TC will discuss the appointment as proposed in etherpad and let you know soon. -gmann ---- On Wed, 23 Feb 2022 10:29:04 -0600 ??? wrote ---- > Hello, Ghanshyam > > I'm so sorry we missed this mail. > I had added me in this page for Skyline project: https://etherpad.opendev.org/p/zed-leaderless > > Thanks > > Best Regards > Wenxiang Wu > > ---- On Thu, 17 Feb 2022 13:40:32 -0600 Lance Albertson wrote ---- > > Apologies for the delay as I'm behind on my email. I just submitted my candidacy even though I'm a few days late. Thanks- > > Thanks, Lance for your nomination. As nomination is closed now, TC will appoint the PTL. > > I have added your late candidacy in TC etherpad https://etherpad.opendev.org/p/zed-leaderless > > As the next step, TC will discuss and let you about the appointment. > > -gmann > > > On Tue, Feb 15, 2022 at 2:40 PM Ghanshyam Mann wrote: > > Hello Everyone, > > > > ~1 hr left for nomination close, I am tagging the 17 projects in ML subject which left with the nomination. > > > > -gmann > > > > ---- On Tue, 15 Feb 2022 13:07:36 -0600 Ghanshyam Mann wrote ---- > > > Hello Everyone, > > > > > > Less than 5 hours left for nomination end and we still need nominations for 21 projects (Zun and Masakari nomination are there but not passed the validation): > > > > > > - Adjutant Freezer Heat Magnum Masakari Monasca Murano OpenStack_Charms Openstack_Chef Release_Management Requirements Senlin Skyline Solum Swift Tripleo Trove Venus Watcher Zaqar Zun > > > > > > If you are maintainer of above projects, please do not delay the nomination or motivate the one you think should add nomination. > > > > > > -gmann & The OpenStack Technical Election Officials > > > > > > ---- On Mon, 14 Feb 2022 18:20:38 -0600 Ghanshyam Mann wrote ---- > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Lance AlbertsonDirectorOregon State University | Open Source Lab > > > > > From hberaud at redhat.com Wed Feb 23 17:01:05 2022 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 23 Feb 2022 18:01:05 +0100 Subject: [Oslo] Core team cleanup Message-ID: Hello, I took a look at our core team, "oslo-core" in gerrit. We have a few individuals who I feel have moved on from Oslo in their focus. I looked at the reviews from stackalytics.io for the last 180 days[2]. These individuals have no activity during the last 180 days: - Zane Bitter; - Doug Hellmann; - Sean McGinnis. These individuals have publicly expressed that they are moving on from Oslo: - Ken Guisti; - Mois?s Guimar?es De Medeiros. I'd like to propose we remove these folks from our core team, while thanking them for their contributions. I'll also note that I'd still value +1/-1 from these folks with a lot of significance, and encourage them to review their areas of expertise! If anyone on the list plans to start reviewing in Oslo again, then I also think we can postpone the removal for the time being and re-evaluate later. Please let me know if that's the case. Please reply and let me know any agreements or concerns with this change. Thank you! [1] https://review.opendev.org/admin/groups/106,members [2] https://www.stackalytics.io/report/contribution?module=oslo-group&project_type=openstack&days=180 -- 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: From firebirdmars at yahoo.com Wed Feb 23 04:01:34 2022 From: firebirdmars at yahoo.com (yahoo yahho) Date: Wed, 23 Feb 2022 04:01:34 +0000 (UTC) Subject: [Tempest] OpenSack Powered * vs OpeStack Compatible References: <1280013007.2009002.1645588894238.ref@mail.yahoo.com> Message-ID: <1280013007.2009002.1645588894238@mail.yahoo.com> Sent from Yahoo Mail on Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Feb 24 04:06:56 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 23 Feb 2022 22:06:56 -0600 Subject: [all][tc] Technical Committee next weekly meeting on Feb 24th at 1500 UTC In-Reply-To: <17f1e24bc0b.c42360a5371741.4976648255459197392@ghanshyammann.com> References: <17f1e24bc0b.c42360a5371741.4976648255459197392@ghanshyammann.com> Message-ID: <17f29e91ae5.129d5421542414.1113613565590926331@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 cycle Technical Elections ** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027311.html ** Leaderless projects *** https://etherpad.opendev.org/p/zed-leaderless * PTG Preparation ** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027381.html ** https://etherpad.opendev.org/p/tc-zed-ptg ** TC + Community Leaders Interaction *** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027382.html *Dropping tags framework - next steps (yoctozepto) * "Artificially inflated requirements in os-brick?" (rosmaita) ** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027343.html ** https://review.opendev.org/c/openstack/os-brick/+/828802 ** Cinder project would like to get a sense of what the TC thinks about this for Yoga (because we plan to make the Yoga release cinderclient and cinder minima consistent with os-brick) * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Mon, 21 Feb 2022 15:16:38 -0600 Ghanshyam Mann wrote ---- > Hello Everyone, > > Technical Committee's next weekly meeting is scheduled for Feb 24th at 1500 UTC. > > If you would like to add topics for discussion, please add them to the below wiki page by > Wednesday, Feb 23rd, at 2100 UTC. > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > -gmann > > > From amonster369 at gmail.com Thu Feb 24 12:59:22 2022 From: amonster369 at gmail.com (A Monster) Date: Thu, 24 Feb 2022 13:59:22 +0100 Subject: No IP address in VMs instances ( neutron dhcp ) on fresh kolla-ansible deployment Message-ID: I've deployed an all in one Openstack on Centos 8 stream using kolla-ansible following the tutorial in openstack kolla website. After the deployment, I used the int-runonce script to create networks and stuff, but after launching a cirros VM, I found that the network interfaces inside the VM didn't get IP addresses from the neutron DHCP agent, therefore that instance was not reachable from nowhere. The docker container of the dhcp agent is up and running, but VMs don't receive any data from it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Thu Feb 24 13:18:06 2022 From: smooney at redhat.com (Sean Mooney) Date: Thu, 24 Feb 2022 13:18:06 +0000 Subject: No IP address in VMs instances ( neutron dhcp ) on fresh kolla-ansible deployment In-Reply-To: References: Message-ID: On Thu, 2022-02-24 at 13:59 +0100, A Monster wrote: > I've deployed an all in one Openstack on Centos 8 stream using > kolla-ansible following the tutorial in openstack kolla website. > After the deployment, I used the int-runonce script to create networks and > stuff, but after launching a cirros VM, I found that the network interfaces > inside the VM didn't get IP addresses from the neutron DHCP agent, > therefore that instance was not reachable from nowhere. > The docker container of the dhcp agent is up and running, but VMs don't > receive any data from it. which network did you use. the default external network that is created has dhcp disabled. https://github.com/openstack/kolla-ansible/blob/master/tools/init-runonce#L88-L95 so if you used the public1 network they will not recive dhcp adresses in the vms. From andrew.west-contractor at CGG.COM Thu Feb 24 14:29:25 2022 From: andrew.west-contractor at CGG.COM (west, andrew) Date: Thu, 24 Feb 2022 14:29:25 +0000 Subject: Xena and CEPH RBD backend (show_image_direct_url status ) Message-ID: Hello experts Currently using openstack Xena and Ceph backend (Pacific 16.2.7) It seems there is a bug (since Wallaby?) where the efficient use of a CEPH Pacific RBD backend (i.e with copy-on-write-cloning) is not working . Show_image_direct_url needs to be False to create volumes (or ephemeral volumes for nova) This can of course be tremendously slow (Nova , ephemeral root disk) without copy-on-write cloning feature of Ceph. As Ceph RBD is THE most favourite backend for block storage in openstack I am wondering how others are coping (or workarounds found ?) Which combinations of Openstack and Ceph are known to work well with copy-on-write-cloning? How is the noted GRAVE Security RISK of enabling Show_image_direct_url mitigated ? (i.e I think , for CEPH RBD, it needs to be True to get cloning to work efficiently) See another report of this issue here: Re: Ceph Pacifif and Openstack Wallaby - ERROR cinder.scheduler.flows.create_volume - CEPH Filesystem Users (spinics.net) Thanks for any help or pointers, Andrew West Openstack consulting CGG France ________________________________ "This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of the email by others is strictly prohibited. If you are not the intended recipient, you must not review, disclose, copy, distribute or use this e-mail; please delete it from your system and notify the sender immediately." -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Thu Feb 24 15:11:34 2022 From: marios at redhat.com (Marios Andreou) Date: Thu, 24 Feb 2022 17:11:34 +0200 Subject: [TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby Message-ID: Hello TripleO o/ During the last period the tripleo-ci team has been working on getting tripleo CI jobs to run centos-9. On master branches across all TripleO repos we now run C9 exclusively (since [1]). On Wallaby branches, after the work at [2] (in particular after https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we will run both C8 and C9 jobs. I started an etherpad at [3] thinking this would be a PTG topic, but I think we'll want to have this conversation way before then. There is a tripleo-heat-templates example in the etherpad that shows what we can expect from the job runs (note the exact jobs that run will vary per repo and even between changes depending on the files touched - but generally there will be duplication between 8 and 9 jobs). The current proposal is that we keep a minimal subset on C8 Wallaby, with C9 wallaby having the full set of jobs. Two factors that will affect our decisions are (there may be more?) i) Upgrades requirements - are we supporting upgrading to Wallaby on 8? For example, the coming undercloud-upgrade-ffu job will be train 8 to wallaby 8. In which case we definitely need to keep at least some subset of 8 jobs (and can't entertain the removal of 8 from Wallaby completely). ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8 but this will soon switch. For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone (no scenarios? some subset of them?), undercloud-ffu, minor update. This is just to start the conversation so please reply if you have thoughts or comments about any of the above. We are planning to discuss this in the coming tripleo-ci community call this coming Tuesday at 1330 UTC - meeting link at [4] so please join us if you can and would like to participate, regards, marios [1] https://review.opendev.org/q/topic:c8_teardown_master [2] https://review.opendev.org/q/topic:c9_wallaby_gates [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9 [4] https://meet.google.com/bqx-xwht-wky From fungi at yuggoth.org Thu Feb 24 19:41:27 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 24 Feb 2022 19:41:27 +0000 Subject: [api=sig][i18n][infra][tc] Cleaning up more defunct mailing lists Message-ID: <20220224194126.3nh7karpemefjfvu@yuggoth.org> A quick audit of the mailing lists we host at lists.openstack.org turned up the following 11 which have had no new posts for at least three years now: * openstack-api-consumers * openstack-de * openstack-el * openstack-i18n-fr * openstack-ir * openstack-personas * openstack-ru * openstack-sos * openstack-tw * openstack-vi * third-party-announce I'd like to clean them up by removing their list configurations, but leaving any public archives intact. Are there any objections? Should any of the above have future messages redirected to a different list (though since they haven't had any for years, that's probably unnecessary)? -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From katonalala at gmail.com Thu Feb 24 19:52:30 2022 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 24 Feb 2022 20:52:30 +0100 Subject: [neutron] Drivers meeting agenda - 25.02.2022. Message-ID: Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. * [RFE][L3][OVS] use controller (ovs-agent) send (packet-out) RA to (VMs) ports (https://bugs.launchpad.net/neutron/+bug/1961011 ) * [RFE][OVN] Support DNS subdomains at a network level ( https://bugs.launchpad.net/neutron/+bug/1960850 ) * Gratuitous ARPs are not sent during master transition: ( https://bugs.launchpad.net/neutron/+bug/1952907) ** For this one there are a few wip patches: ** https://review.opendev.org/c/openstack/neutron/+/821434 ** https://review.opendev.org/c/openstack/neutron/+/821433 ** https://review.opendev.org/c/openstack/neutron/+/712474 [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda See you at the meeting tomorrow. Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Thu Feb 24 19:58:09 2022 From: mnaser at vexxhost.com (Mohammed Naser) Date: Thu, 24 Feb 2022 14:58:09 -0500 Subject: [api=sig][i18n][infra][tc] Cleaning up more defunct mailing lists In-Reply-To: <20220224194126.3nh7karpemefjfvu@yuggoth.org> References: <20220224194126.3nh7karpemefjfvu@yuggoth.org> Message-ID: +1 though might want to resend with subject updated to be `api-sig` in case someone is watching for it. Mohammed On Thu, Feb 24, 2022 at 2:49 PM Jeremy Stanley wrote: > > A quick audit of the mailing lists we host at lists.openstack.org > turned up the following 11 which have had no new posts for at least > three years now: > > * openstack-api-consumers > * openstack-de > * openstack-el > * openstack-i18n-fr > * openstack-ir > * openstack-personas > * openstack-ru > * openstack-sos > * openstack-tw > * openstack-vi > * third-party-announce > > I'd like to clean them up by removing their list configurations, but > leaving any public archives intact. Are there any objections? Should > any of the above have future messages redirected to a different list > (though since they haven't had any for years, that's probably > unnecessary)? > -- > Jeremy Stanley -- Mohammed Naser VEXXHOST, Inc. From fungi at yuggoth.org Thu Feb 24 20:31:36 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 24 Feb 2022 20:31:36 +0000 Subject: [api-sig][i18n][infra][tc] Cleaning up more defunct mailing lists In-Reply-To: References: <20220224194126.3nh7karpemefjfvu@yuggoth.org> Message-ID: <20220224203135.64lzkh6zblcpmhdi@yuggoth.org> On 2022-02-24 14:58:09 -0500 (-0500), Mohammed Naser wrote: > On Thu, Feb 24, 2022 at 2:49 PM Jeremy Stanley wrote: > > A quick audit of the mailing lists we host at lists.openstack.org > > turned up the following 11 which have had no new posts for at least > > three years now: > > > > * openstack-api-consumers > > * openstack-de > > * openstack-el > > * openstack-i18n-fr > > * openstack-ir > > * openstack-personas > > * openstack-ru > > * openstack-sos > > * openstack-tw > > * openstack-vi > > * third-party-announce > > > > I'd like to clean them up by removing their list configurations, but > > leaving any public archives intact. Are there any objections? Should > > any of the above have future messages redirected to a different list > > (though since they haven't had any for years, that's probably > > unnecessary)? > > +1 > > though might want to resend with subject updated to be `api-sig` in > case someone is watching for it. Thanks, and yeah I spotted that immediately after I sent the message, but I've corrected it in my reply here in case there are still any active members of the API SIG around these days. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From gmann at ghanshyammann.com Thu Feb 24 21:00:17 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 24 Feb 2022 15:00:17 -0600 Subject: [api-sig][i18n][infra][tc] Cleaning up more defunct mailing lists In-Reply-To: <20220224203135.64lzkh6zblcpmhdi@yuggoth.org> References: <20220224194126.3nh7karpemefjfvu@yuggoth.org> <20220224203135.64lzkh6zblcpmhdi@yuggoth.org> Message-ID: <17f2d88d9cd.e6cc6ed2108254.5876839370362248918@ghanshyammann.com> ---- On Thu, 24 Feb 2022 14:31:36 -0600 Jeremy Stanley wrote ---- > On 2022-02-24 14:58:09 -0500 (-0500), Mohammed Naser wrote: > > On Thu, Feb 24, 2022 at 2:49 PM Jeremy Stanley wrote: > > > A quick audit of the mailing lists we host at lists.openstack.org > > > turned up the following 11 which have had no new posts for at least > > > three years now: > > > > > > * openstack-api-consumers > > > * openstack-de > > > * openstack-el > > > * openstack-i18n-fr > > > * openstack-ir > > > * openstack-personas > > > * openstack-ru > > > * openstack-sos > > > * openstack-tw > > > * openstack-vi > > > * third-party-announce > > > > > > I'd like to clean them up by removing their list configurations, but > > > leaving any public archives intact. Are there any objections? Should > > > any of the above have future messages redirected to a different list > > > (though since they haven't had any for years, that's probably > > > unnecessary)? > > > > +1 > > > > though might want to resend with subject updated to be `api-sig` in > > case someone is watching for it. > > Thanks, and yeah I spotted that immediately after I sent the > message, but I've corrected it in my reply here in case there are > still any active members of the API SIG around these days. +1, and we are dying those are merged in openstack-discuss ML right? If anyone using those ML can send email to openstack-discuss. -gmann > -- > Jeremy Stanley > From fungi at yuggoth.org Thu Feb 24 21:05:00 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 24 Feb 2022 21:05:00 +0000 Subject: [api-sig][i18n][infra][tc] Cleaning up more defunct mailing lists In-Reply-To: <17f2d88d9cd.e6cc6ed2108254.5876839370362248918@ghanshyammann.com> References: <20220224194126.3nh7karpemefjfvu@yuggoth.org> <20220224203135.64lzkh6zblcpmhdi@yuggoth.org> <17f2d88d9cd.e6cc6ed2108254.5876839370362248918@ghanshyammann.com> Message-ID: <20220224210500.f66olyg4tm7l2c2l@yuggoth.org> On 2022-02-24 15:00:17 -0600 (-0600), Ghanshyam Mann wrote: > On Thu, Feb 24, 2022 at 2:49 PM Jeremy Stanley wrote: [...] > > I'd like to clean them up by removing their list configurations, but > > leaving any public archives intact. Are there any objections? Should > > any of the above have future messages redirected to a different list > > (though since they haven't had any for years, that's probably > > unnecessary)? > > +1, and we are dying those are merged in openstack-discuss ML right? If anyone > using those ML can send email to openstack-discuss. Sorry, that's what I was asking in the quoted paragraph. By default, any messages to those addresses would just be rejected. We can direct them to an active mailing list, though I'm not sure that's warranted since nobody seems to have sent anything to them for 3 years or more. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From gmann at ghanshyammann.com Thu Feb 24 21:39:57 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 24 Feb 2022 15:39:57 -0600 Subject: [api-sig][i18n][infra][tc] Cleaning up more defunct mailing lists In-Reply-To: <20220224210500.f66olyg4tm7l2c2l@yuggoth.org> References: <20220224194126.3nh7karpemefjfvu@yuggoth.org> <20220224203135.64lzkh6zblcpmhdi@yuggoth.org> <17f2d88d9cd.e6cc6ed2108254.5876839370362248918@ghanshyammann.com> <20220224210500.f66olyg4tm7l2c2l@yuggoth.org> Message-ID: <17f2dad2aad.128395b08109018.938799009896220269@ghanshyammann.com> ---- On Thu, 24 Feb 2022 15:05:00 -0600 Jeremy Stanley wrote ---- > On 2022-02-24 15:00:17 -0600 (-0600), Ghanshyam Mann wrote: > > On Thu, Feb 24, 2022 at 2:49 PM Jeremy Stanley wrote: > [...] > > > I'd like to clean them up by removing their list configurations, but > > > leaving any public archives intact. Are there any objections? Should > > > any of the above have future messages redirected to a different list > > > (though since they haven't had any for years, that's probably > > > unnecessary)? > > > > +1, and we are dying those are merged in openstack-discuss ML right? If anyone > > using those ML can send email to openstack-discuss. > > Sorry, that's what I was asking in the quoted paragraph. By default, > any messages to those addresses would just be rejected. We can > direct them to an active mailing list, though I'm not sure that's > warranted since nobody seems to have sent anything to them for 3 > years or more. I think you are right, as they have not been used for 3 years, nobody will use them in future or people aware of openstack-discuss ML. I agree on just letting them go. -gmann > -- > Jeremy Stanley > From gmann at ghanshyammann.com Thu Feb 24 23:06:08 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 24 Feb 2022 17:06:08 -0600 Subject: [all][elections][ptl] Project Team Lead Zed Election Conclusion and Results Message-ID: <17f2dfc115f.aeb212a5110488.1934832482892965656@ghanshyammann.com> Thank you to the all candidates who put their names forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability. Thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Barbican : Douglas Mendiz?bal * Blazar : Pierre Riteau * Cinder : Rajat Dhasmana * Cloudkitty : Rafael Weingartner * Cyborg : Bailin Zhang * Designate : Michael Johnson * Ec2 Api : Andrey Pavlov * Glance : Abhishek Kekane * Horizon : Vishal Manchanda * Ironic : Iury Gregory Melo Ferreira * Keystone : Douglas Mendiz?bal * Kolla : Michal Nasiadka * Kuryr : Maysa de Macedo Souza * Manila : Carlos Silva * Neutron : Lajos Katona * Nova : Sylvain Bauza * Octavia : Gregory Thiemonge * OpenStack Helm : Gage Hugo * OpenStackAnsible : Dmitriy Rabotyagov * OpenStackSDK : Artem Goncharov * Puppet OpenStack : Takashi Kajinami * Quality Assurance : Martin Kopec * Rally : Andrey Kurilin * Release Management : Elod Illes * Requirements : Matthew Thode * Sahara : Fossen Qiu * Storlets : Takashi Kajinami * Swift : Tim Burke * Tacker : Yasufumi Ogawa * Telemetry : Matthias Runge * Tripleo : James Slagle * Vitrage : Eyal Bar-Ilan * Winstackers : Lucian Petrut For remaining projects (without PTL candaidates), TC will work on the appointment. Elections: no election required. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process -gmann, on behalf of the OpenStack Technical Election Officials From gmann at ghanshyammann.com Thu Feb 24 23:08:58 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 24 Feb 2022 17:08:58 -0600 Subject: [all][elections][tc] Technical Committee Election Results Message-ID: <17f2dfea790.b48fcc2d110533.5395567599828715540@ghanshyammann.com> For 5 TC open seats, there were 5 candidates so no election was required. Please join me in congratulating the 5 newly elected members of the Technical Committee (TC). Amy Marrich (spotz) Arne Wiebalck (arnewiebalck) Kristi Nikolla (knikolla) Brian Rosmaita (rosmaita) S?awek Kap?o?ski (slaweq) Full results: no election required. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you for another great round. -gmann, on behalf of the OpenStack Technical Election Officials From iurygregory at gmail.com Thu Feb 24 23:47:06 2022 From: iurygregory at gmail.com (Iury Gregory) Date: Thu, 24 Feb 2022 20:47:06 -0300 Subject: [all][elections][tc] Technical Committee Election Results In-Reply-To: <17f2dfea790.b48fcc2d110533.5395567599828715540@ghanshyammann.com> References: <17f2dfea790.b48fcc2d110533.5395567599828715540@ghanshyammann.com> Message-ID: Congratulations everyone! On Thu, Feb 24, 2022, 8:09 PM Ghanshyam Mann wrote: > For 5 TC open seats, there were 5 candidates so no election was required. > > Please join me in congratulating the 5 newly elected members of the > Technical Committee (TC). > > Amy Marrich (spotz) > Arne Wiebalck (arnewiebalck) > Kristi Nikolla (knikolla) > Brian Rosmaita (rosmaita) > S?awek Kap?o?ski (slaweq) > > Full results: no election required. > > Election process details and results are also available here: > https://governance.openstack.org/election/ > > Thank you to all of the candidates, having a good group of candidates > helps engage the community in our democratic process. > > Thank you for another great round. > > -gmann, on behalf of the OpenStack Technical Election Officials > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Fri Feb 25 07:20:18 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 25 Feb 2022 08:20:18 +0100 Subject: [api-sig][i18n][infra][tc] Cleaning up more defunct mailing lists In-Reply-To: <17f2dad2aad.128395b08109018.938799009896220269@ghanshyammann.com> References: <20220224194126.3nh7karpemefjfvu@yuggoth.org> <20220224210500.f66olyg4tm7l2c2l@yuggoth.org> <17f2dad2aad.128395b08109018.938799009896220269@ghanshyammann.com> Message-ID: <1884806.PYKUYFuaPT@p1> Hi, On czwartek, 24 lutego 2022 22:39:57 CET Ghanshyam Mann wrote: > ---- On Thu, 24 Feb 2022 15:05:00 -0600 Jeremy Stanley > wrote ---- > > On 2022-02-24 15:00:17 -0600 (-0600), Ghanshyam Mann wrote: > > > On Thu, Feb 24, 2022 at 2:49 PM Jeremy Stanley wrote: > > [...] > > > > > > I'd like to clean them up by removing their list configurations, but > > > > leaving any public archives intact. Are there any objections? Should > > > > any of the above have future messages redirected to a different list > > > > (though since they haven't had any for years, that's probably > > > > unnecessary)? > > > > > > +1, and we are dying those are merged in openstack-discuss ML right? If > > > anyone using those ML can send email to openstack-discuss. > > > > Sorry, that's what I was asking in the quoted paragraph. By default, > > any messages to those addresses would just be rejected. We can > > direct them to an active mailing list, though I'm not sure that's > > warranted since nobody seems to have sent anything to them for 3 > > years or more. > > I think you are right, as they have not been used for 3 years, nobody will > use them in future or people aware of openstack-discuss ML. I agree on just > letting them go. > > -gmann +1. If those lists were not used for so long, I don't think they will be used in the future by anyone. -- 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: From lokendrarathour at gmail.com Fri Feb 25 07:21:33 2022 From: lokendrarathour at gmail.com (Lokendra Rathour) Date: Fri, 25 Feb 2022 12:51:33 +0530 Subject: [Triple0] Upgrade Error In-Reply-To: References: Message-ID: Hi Team, Please help share any updates on the same. We have Train as the base release and we wish to upgrade to Ussuri. Thanks once again for the all-time support. -Lokendra On Wed, Feb 23, 2022 at 5:20 PM Lokendra Rathour wrote: > Hi Team, > we are trying to upgrade Triple0 Train to Ussuri. > Undercloud upgrade prepare is done successfully and when we are going for > overcloud upgrade getting below error: > > > > > > > > > > > > > > > * len(inspect.getargspec(type_).args) > 1)2022-02-23 16:49:50.959 187217 > INFO tripleoclient.utils.utils [-] Running Ansible playbook: > /usr/share/ansible/tripleo-playbooks/cli-update-params.yaml, Working > directory: /tmp/tripleoj7rvp51m, Playbook directory: > /usr/share/ansible/tripleo-playbooksPLAY [Update Parameters] > *******************************************************2022-02-23 > 16:49:51.858966 | 5254007d-0040-f631-88e7-000000000008 | TASK | Check > for required inputs2022-02-23 16:49:51.895961 | > 5254007d-0040-f631-88e7-000000000008 | SKIPPED | Check for required > inputs | localhost2022-02-23 16:49:51.897803 | > 5254007d-0040-f631-88e7-000000000008 | TIMING | Check for required > inputs | localhost | 0:00:00.096595 | 0.04s2022-02-23 16:49:51.901827 | > 5254007d-0040-f631-88e7-000000000009 | TASK | Set parameters > fact2022-02-23 16:49:51.949091 | 5254007d-0040-f631-88e7-000000000009 | > OK | Set parameters fact | localhost2022-02-23 16:49:51.951583 | > 5254007d-0040-f631-88e7-000000000009 | TIMING | Set parameters fact | > localhost | 0:00:00.150375 | 0.05s2022-02-23 16:49:51.956146 | > 5254007d-0040-f631-88e7-00000000000b | TASK | Update > parameters2022-02-23 16:50:12.542028 | 5254007d-0040-f631-88e7-00000000000b > | FATAL | Update parameters | localhost | error={"changed": false, > "error": "Error validating environment for plan overcloud: ERROR: Property > error: resources.InternalApiVirtualIP.properties: Unknown Property > DnsName\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", > line 891, in __call__\n request, **action_args)\n File > \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in > dispatch\n return method(*args, **kwargs)\n File > \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\", line > 56, in handle_stack_method\n return handler(controller, req, **kwargs)\n > File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\", > line 633, in validate_template\n raise > exc.HTTPBadRequest(result['Error'])\n", "msg": "Error updating parameters > for plan overcloud: Error validating environment for plan overcloud: ERROR: > Property error: resources.InternalApiVirtualIP.properties: Unknown Property > DnsName\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", > line 891, in __call__\n request, **action_args)\n File > \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in > dispatch\n return method(*args, **kwargs)\n File > \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\", line > 56, in handle_stack_method\n return handler(controller, req, **kwargs)\n > File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\", > line 633, in validate_template\n raise > exc.HTTPBadRequest(result['Error'])\n", "success": false}2022-02-23 > 16:50:12.544560 | 5254007d-0040-f631-88e7-00000000000b | TIMING | > Update parameters | localhost | 0:00:20.743350 | 20.59s* > > Command used to run the overcloud upgrade prepare: > > > > > > > > > > > > > > > > > *(undercloud) [stack at undercloud ~]$ cat > upgrade_overcloud_prepare.shopenstack overcloud upgrade prepare --templates > \ -r /home/stack/templates/roles_data.yaml \ -n > /home/stack/templates/network_data.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/templates/init-repo.yaml \ -e > /home/stack/containers-prepare-parameter.yaml(undercloud) [stack at undercloud > ~]$* > > *Document referred:*Upgrading to a Next Major Release ? TripleO 3.0.0 > documentation (openstack.org) > > > Any support here, please. > > -- > ~ Lokendra > skype: lokendrarathour > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Fri Feb 25 08:50:42 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 25 Feb 2022 09:50:42 +0100 Subject: [all][elections][tc] Technical Committee Election Results In-Reply-To: <17f2dfea790.b48fcc2d110533.5395567599828715540@ghanshyammann.com> References: <17f2dfea790.b48fcc2d110533.5395567599828715540@ghanshyammann.com> Message-ID: Woohoo! Go, go, TC! Congratulations to all! -yoctozepto On Fri, 25 Feb 2022 at 00:09, Ghanshyam Mann wrote: > > For 5 TC open seats, there were 5 candidates so no election was required. > > Please join me in congratulating the 5 newly elected members of the Technical Committee (TC). > > Amy Marrich (spotz) > Arne Wiebalck (arnewiebalck) > Kristi Nikolla (knikolla) > Brian Rosmaita (rosmaita) > S?awek Kap?o?ski (slaweq) > > Full results: no election required. > > Election process details and results are also available here: https://governance.openstack.org/election/ > > Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. > > Thank you for another great round. > > -gmann, on behalf of the OpenStack Technical Election Officials > > From lokendrarathour at gmail.com Fri Feb 25 11:21:49 2022 From: lokendrarathour at gmail.com (Lokendra Rathour) Date: Fri, 25 Feb 2022 16:51:49 +0530 Subject: Fwd: [Triple0] Upgrade Error In-Reply-To: References: Message-ID: Hi Team, we are trying to upgrade *Triple0 Train to Ussuri.* Undercloud upgrade is done successfully. *OverCloud Upgrade:* As a first step in overcloud upgrade, we are running " *openstack overcloud upgrade prepare* " command. which is throwing following error: * len(inspect.getargspec(type_).args) > 1)2022-02-23 16:49:50.959 187217 INFO tripleoclient.utils.utils [-] Running Ansible playbook: /usr/share/ansible/tripleo-playbooks/cli-update-params.yaml, Working directory: /tmp/tripleoj7rvp51m, Playbook directory: /usr/share/ansible/tripleo-playbooksPLAY [Update Parameters] *******************************************************2022-02-23 16:49:51.858966 | 5254007d-0040-f631-88e7-000000000008 | TASK | Check for required inputs2022-02-23 16:49:51.895961 | 5254007d-0040-f631-88e7-000000000008 | SKIPPED | Check for required inputs | localhost2022-02-23 16:49:51.897803 | 5254007d-0040-f631-88e7-000000000008 | TIMING | Check for required inputs | localhost | 0:00:00.096595 | 0.04s2022-02-23 16:49:51.901827 | 5254007d-0040-f631-88e7-000000000009 | TASK | Set parameters fact2022-02-23 16:49:51.949091 | 5254007d-0040-f631-88e7-000000000009 | OK | Set parameters fact | localhost2022-02-23 16:49:51.951583 | 5254007d-0040-f631-88e7-000000000009 | TIMING | Set parameters fact | localhost | 0:00:00.150375 | 0.05s2022-02-23 16:49:51.956146 | 5254007d-0040-f631-88e7-00000000000b | TASK | Update parameters2022-02-23 16:50:12.542028 | 5254007d-0040-f631-88e7-00000000000b | FATAL | Update parameters | localhost | error={"changed": false, "error": "Error validating environment for plan overcloud: ERROR: Property error: resources.InternalApiVirtualIP.properties: Unknown Property DnsName\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 891, in __call__\n request, **action_args)\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in dispatch\n return method(*args, **kwargs)\n File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\", line 56, in handle_stack_method\n return handler(controller, req, **kwargs)\n File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\", line 633, in validate_template\n raise exc.HTTPBadRequest(result['Error'])\n", "msg": "Error updating parameters for plan overcloud: Error validating environment for plan overcloud: ERROR: Property error: resources.InternalApiVirtualIP.properties: Unknown Property DnsName\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 891, in __call__\n request, **action_args)\n File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in dispatch\n return method(*args, **kwargs)\n File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\", line 56, in handle_stack_method\n return handler(controller, req, **kwargs)\n File \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\", line 633, in validate_template\n raise exc.HTTPBadRequest(result['Error'])\n", "success": false}2022-02-23 16:50:12.544560 | 5254007d-0040-f631-88e7-00000000000b | TIMING | Update parameters | localhost | 0:00:20.743350 | 20.59s* *Command used to run the overcloud upgrade prepare:* *(undercloud) [stack at undercloud ~]$ cat upgrade_overcloud_prepare.shopenstack overcloud upgrade prepare --templates \ -r /home/stack/templates/roles_data.yaml \ -n /home/stack/templates/network_data.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/templates/init-repo.yaml \ -e /home/stack/containers-prepare-parameter.yaml(undercloud) [stack at undercloud ~]$* *Document referred:*Upgrading to a Next Major Release ? TripleO 3.0.0 documentation (openstack.org) Any support here, please. Please suggest if any other documents needs to be followed for ugrade. -- ~ Lokendra skype: lokendrarathour -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aija.Jaunteva at dell.com Fri Feb 25 11:41:55 2022 From: Aija.Jaunteva at dell.com (Jaunteva, Aija) Date: Fri, 25 Feb 2022 11:41:55 +0000 Subject: [hwsig] sushy-oem-idrac for Hardware Vendor SIG Message-ID: Hi, I would like to propose moving sushy-oem-idrac [1] that is used in Ironic project to Hardware Vendor SIG. sushy-oem-idrac is iDRAC specific OEM extension of vendor-independent sushy [2] library and both use Redfish to communicate with BMCs. Any feedback welcome. Regards, Aija [1] https://opendev.org/x/sushy-oem-idrac/ [2] https://opendev.org/openstack/sushy Internal Use - Confidential -------------- next part -------------- An HTML attachment was scrubbed... URL: From bshewale at redhat.com Fri Feb 25 12:44:08 2022 From: bshewale at redhat.com (Bhagyashri Shewale) Date: Fri, 25 Feb 2022 18:14:08 +0530 Subject: [TripleO] Gate blocker - centos-9 standalone and multinode Message-ID: Hi All, We have an issue affecting standalone and multinode centos-9 check/gate jobs due to tempest test failure. Details: https://bugs.launchpad.net/tripleo/+bug/1962298 We are currently deciding on the best course of action for unblocking this issue. We will post an update once the check/gate is clear. Until then, please hold on rechecking. Thanks and Regards Bhagyashri Shewale -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at danplanet.com Fri Feb 25 14:41:53 2022 From: dms at danplanet.com (Dan Smith) Date: Fri, 25 Feb 2022 06:41:53 -0800 Subject: [api=sig][i18n][infra][tc] Cleaning up more defunct mailing lists In-Reply-To: <20220224194126.3nh7karpemefjfvu@yuggoth.org> (Jeremy Stanley's message of "Thu, 24 Feb 2022 19:41:27 +0000") References: <20220224194126.3nh7karpemefjfvu@yuggoth.org> Message-ID: > * openstack-sos > I'd like to clean them up by removing their list configurations, but > leaving any public archives intact. Are there any objections? Should > any of the above have future messages redirected to a different list > (though since they haven't had any for years, that's probably > unnecessary)? Yes, please, I had asked for -sos to be deleted years ago. FWIW, there were less than ten mails ever sent to that list, and they were all about non-openstack things that are long out of date. I'd say no point in keeping the archives, unless it's more work to handle differently from the others. --Dan From massimo.sgaravatto at gmail.com Fri Feb 25 15:50:22 2022 From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto) Date: Fri, 25 Feb 2022 16:50:22 +0100 Subject: [ops][nova] How to update from N to N+3 (and manage nova services that don't start because they find too old compute nodes...) In-Reply-To: References: Message-ID: I had the chance to repeat this test So the scenario is: 1) controller and compute nodes running train 2) all services stopped in compute nodes 3) controller updated: train-->ussuri-->victoria--> wallaby After that nova conductor and nova scheduler refuses to start [*] At that moment nova-compute services were not running on the compute nodes And this was the status on the services table: mysql> select * from services where topic="compute"; +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ | created_at | updated_at | deleted_at | id | host | binary | topic | report_count | disabled | deleted | disabled_reason | last_seen_up | forced_down | version | uuid | +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ | 2018-01-11 17:20:34 | 2022-02-25 09:09:17 | NULL | 17 | compute-01.cloud.pd.infn.it | nova-compute | compute | 10250811 | 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:09:13 | 0 | 40 | 2f56b8cf-1190-4999-af79-6bcee695c653 | | 2018-01-11 17:26:39 | 2022-02-25 09:09:49 | NULL | 23 | compute-02.cloud.pd.infn.it | nova-compute | compute | 10439622 | 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:09:49 | 0 | 40 | fbe37dfd-4a6c-4da1-96e0-407f7f98c4c4 | | 2018-01-11 17:27:12 | 2022-02-25 09:10:02 | NULL | 24 | compute-03.cloud.pd.infn.it | nova-compute | compute | 10361295 | 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:10:02 | 0 | 40 | 3675f324-81dd-445a-b4eb-510726104be3 | | 2021-04-06 12:54:42 | 2022-02-25 09:10:02 | NULL | 25 | compute-04.cloud.pd.infn.it | nova-compute | compute | 1790955 | 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:10:02 | 0 | 40 | e3e7af4d-b25b-410c-983e-8128a5e97219 | +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ 4 rows in set (0.00 sec) Only after manually setting the version field of these entries to '54', nova-conductor and nova-scheduler were able to start Regards, Massimo [*] 2022-02-25 15:06:03.992 591600 CRITICAL nova [req-cc20f294-cced-434b-98cd-5bdf228a2a22 - - - - -] Unhandled error: nova.exception.TooOldComputeService: Current Nova ve rsion does not support computes older than Wallaby but the minimum compute service level in your system is 40 and the oldest supported service level is 54. 2022-02-25 15:06:03.992 591600 ERROR nova Traceback (most recent call last): 2022-02-25 15:06:03.992 591600 ERROR nova File "/usr/bin/nova-conductor", line 10, in 2022-02-25 15:06:03.992 591600 ERROR nova sys.exit(main()) 2022-02-25 15:06:03.992 591600 ERROR nova File "/usr/lib/python3.6/site-packages/nova/cmd/conductor.py", line 46, in main 2022-02-25 15:06:03.992 591600 ERROR nova topic=rpcapi.RPC_TOPIC) 2022-02-25 15:06:03.992 591600 ERROR nova File "/usr/lib/python3.6/site-packages/nova/service.py", line 264, in create 2022-02-25 15:06:03.992 591600 ERROR nova utils.raise_if_old_compute() 2022-02-25 15:06:03.992 591600 ERROR nova File "/usr/lib/python3.6/site-packages/nova/utils.py", line 1098, in raise_if_old_compute 2022-02-25 15:06:03.992 591600 ERROR nova oldest_supported_service=oldest_supported_service_level) 2022-02-25 15:06:03.992 591600 ERROR nova nova.exception.TooOldComputeService: Current Nova version does not support computes older than Wallaby but the minimum comput e service level in your system is 40 and the oldest supported service level is 54. 2022-02-25 15:06:03.992 591600 ERROR nova On Mon, Jan 10, 2022 at 6:00 PM Massimo Sgaravatto < massimo.sgaravatto at gmail.com> wrote: > Dear all > > When we upgraded our Cloud from Rocky to Train we followed the following > procedure: > > 1) Shutdown of all services on the controller and compute nodes > 2) Update from Rocky to Stein of controller (just to do the dbsyncs) > 3) Update from Stein to Train of controller > 4) Update from Rocky to Train of compute nodes > > We are trying to do the same to update from Train to Xena, but now there > is a problem because > nova services on the controller node refuse to start since they find too > old compute nodes (this is indeed a new feature, properly documented in the > release notes). > As a workaround we had to manually modify the "version" field of the > compute nodes in the nova.services table. > > Is it ok, or is there a cleaner way to manage the issue ? > > Thanks, Massimo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Fri Feb 25 16:07:47 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Fri, 25 Feb 2022 17:07:47 +0100 Subject: [release] Release countdown for week R-4, Feb 28 - Mar 04 Message-ID: Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the Yogadeliverables can be proposed, well ahead of the final Yogarelease date. General Information ------------------- We are still finishing up processing a few release requests, but the Yogarelease requirements are now frozen. If new library releases are needed to fix release-critical bugs in Yoga, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in Yoga that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: ??????? [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By March 24th, 2022this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/yogabranches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for Yoga changes should be added there to make sure the consumers of your release notes see them. Finally, if you haven't proposed Yogacycle-highlights yet, you are already late to the party. Please see our email for details: http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027361.html Upcoming Deadlines & Dates -------------------------- RC1 deadline: March 10th, 2022(R-3 week) Final RC deadline: March 24th, 2022(R-1 week) Final Yogarelease: March 30th, 2022 Next PTG: April 4 - 8, 2022 (virtual) El?dIll?s irc: elodilles -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Fri Feb 25 16:14:48 2022 From: smooney at redhat.com (Sean Mooney) Date: Fri, 25 Feb 2022 16:14:48 +0000 Subject: [ops][nova] How to update from N to N+3 (and manage nova services that don't start because they find too old compute nodes...) In-Reply-To: References: Message-ID: <2a10186d792e8ace7a3753f5c86686ac0e4af873.camel@redhat.com> On Fri, 2022-02-25 at 16:50 +0100, Massimo Sgaravatto wrote: > I had the chance to repeat this test > So the scenario is: > > 1) controller and compute nodes running train > 2) all services stopped in compute nodes > 3) controller updated: train-->ussuri-->victoria--> wallaby > > After that nova conductor and nova scheduler refuses to start [*] yes nova does not offially support n to n+3 upgrade we started enforcing that a few release ago. there is a workaround config option that we recently added that turns the error into a waring?https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_compute_service_check_for_ffu that is one option or you can implement or before you upgrade the contoler you can force-down all the comptue nodes > > At that moment nova-compute services were not running on the compute nodes > And this was the status on the services table: > > mysql> select * from services where topic="compute"; > +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ > > created_at | updated_at | deleted_at | id | host > | binary | topic | report_count | disabled | > deleted | disabled_reason | last_seen_up | > forced_down | version | uuid | > +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ > > 2018-01-11 17:20:34 | 2022-02-25 09:09:17 | NULL | 17 | > compute-01.cloud.pd.infn.it | nova-compute | compute | 10250811 | > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:09:13 | > 0 | 40 | 2f56b8cf-1190-4999-af79-6bcee695c653 | > > 2018-01-11 17:26:39 | 2022-02-25 09:09:49 | NULL | 23 | > compute-02.cloud.pd.infn.it | nova-compute | compute | 10439622 | > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:09:49 | > 0 | 40 | fbe37dfd-4a6c-4da1-96e0-407f7f98c4c4 | > > 2018-01-11 17:27:12 | 2022-02-25 09:10:02 | NULL | 24 | > compute-03.cloud.pd.infn.it | nova-compute | compute | 10361295 | > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:10:02 | > 0 | 40 | 3675f324-81dd-445a-b4eb-510726104be3 | > > 2021-04-06 12:54:42 | 2022-02-25 09:10:02 | NULL | 25 | > compute-04.cloud.pd.infn.it | nova-compute | compute | 1790955 | > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:10:02 | > 0 | 40 | e3e7af4d-b25b-410c-983e-8128a5e97219 | > +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ > 4 rows in set (0.00 sec) > > > > Only after manually setting the version field of these entries to '54', > nova-conductor and nova-scheduler were able to start > > Regards, Massimo > > > [*] > 2022-02-25 15:06:03.992 591600 CRITICAL nova > [req-cc20f294-cced-434b-98cd-5bdf228a2a22 - - - - -] Unhandled error: > nova.exception.TooOldComputeService: Current Nova ve > rsion does not support computes older than Wallaby but the minimum compute > service level in your system is 40 and the oldest supported service level > is 54. > 2022-02-25 15:06:03.992 591600 ERROR nova Traceback (most recent call last): > 2022-02-25 15:06:03.992 591600 ERROR nova File "/usr/bin/nova-conductor", > line 10, in > 2022-02-25 15:06:03.992 591600 ERROR nova sys.exit(main()) > 2022-02-25 15:06:03.992 591600 ERROR nova File > "/usr/lib/python3.6/site-packages/nova/cmd/conductor.py", line 46, in main > 2022-02-25 15:06:03.992 591600 ERROR nova topic=rpcapi.RPC_TOPIC) > 2022-02-25 15:06:03.992 591600 ERROR nova File > "/usr/lib/python3.6/site-packages/nova/service.py", line 264, in create > 2022-02-25 15:06:03.992 591600 ERROR nova utils.raise_if_old_compute() > 2022-02-25 15:06:03.992 591600 ERROR nova File > "/usr/lib/python3.6/site-packages/nova/utils.py", line 1098, in > raise_if_old_compute > 2022-02-25 15:06:03.992 591600 ERROR nova > oldest_supported_service=oldest_supported_service_level) > 2022-02-25 15:06:03.992 591600 ERROR nova > nova.exception.TooOldComputeService: Current Nova version does not support > computes older than Wallaby but the minimum comput > e service level in your system is 40 and the oldest supported service level > is 54. > 2022-02-25 15:06:03.992 591600 ERROR nova > > > > On Mon, Jan 10, 2022 at 6:00 PM Massimo Sgaravatto < > massimo.sgaravatto at gmail.com> wrote: > > > Dear all > > > > When we upgraded our Cloud from Rocky to Train we followed the following > > procedure: > > > > 1) Shutdown of all services on the controller and compute nodes > > 2) Update from Rocky to Stein of controller (just to do the dbsyncs) > > 3) Update from Stein to Train of controller > > 4) Update from Rocky to Train of compute nodes > > > > We are trying to do the same to update from Train to Xena, but now there > > is a problem because > > nova services on the controller node refuse to start since they find too > > old compute nodes (this is indeed a new feature, properly documented in the > > release notes). > > As a workaround we had to manually modify the "version" field of the > > compute nodes in the nova.services table. > > > > Is it ok, or is there a cleaner way to manage the issue ? > > > > Thanks, Massimo > > From massimo.sgaravatto at gmail.com Fri Feb 25 16:57:26 2022 From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto) Date: Fri, 25 Feb 2022 17:57:26 +0100 Subject: [ops][nova] How to update from N to N+3 (and manage nova services that don't start because they find too old compute nodes...) In-Reply-To: <2a10186d792e8ace7a3753f5c86686ac0e4af873.camel@redhat.com> References: <2a10186d792e8ace7a3753f5c86686ac0e4af873.camel@redhat.com> Message-ID: Thanks This "disable_compute_service_check_for_ffu" option is not available in xena, correct ? Cheers, Massimo On Fri, Feb 25, 2022 at 5:15 PM Sean Mooney wrote: > On Fri, 2022-02-25 at 16:50 +0100, Massimo Sgaravatto wrote: > > I had the chance to repeat this test > > So the scenario is: > > > > 1) controller and compute nodes running train > > 2) all services stopped in compute nodes > > 3) controller updated: train-->ussuri-->victoria--> wallaby > > > > After that nova conductor and nova scheduler refuses to start [*] > > yes nova does not offially support n to n+3 upgrade > we started enforcing that a few release ago. > there is a workaround config option that we recently added that turns > the error into a waring > https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_compute_service_check_for_ffu > that is one option or you can implement or before you upgrade the contoler > you can force-down all the comptue nodes > > > > > > > At that moment nova-compute services were not running on the compute > nodes > > And this was the status on the services table: > > > > mysql> select * from services where topic="compute"; > > > +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ > > > created_at | updated_at | deleted_at | id | host > > | binary | topic | report_count | disabled | > > deleted | disabled_reason | last_seen_up | > > forced_down | version | uuid | > > > +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ > > > 2018-01-11 17:20:34 | 2022-02-25 09:09:17 | NULL | 17 | > > compute-01.cloud.pd.infn.it | nova-compute | compute | 10250811 | > > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:09:13 > | > > 0 | 40 | 2f56b8cf-1190-4999-af79-6bcee695c653 | > > > 2018-01-11 17:26:39 | 2022-02-25 09:09:49 | NULL | 23 | > > compute-02.cloud.pd.infn.it | nova-compute | compute | 10439622 | > > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:09:49 > | > > 0 | 40 | fbe37dfd-4a6c-4da1-96e0-407f7f98c4c4 | > > > 2018-01-11 17:27:12 | 2022-02-25 09:10:02 | NULL | 24 | > > compute-03.cloud.pd.infn.it | nova-compute | compute | 10361295 | > > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:10:02 > | > > 0 | 40 | 3675f324-81dd-445a-b4eb-510726104be3 | > > > 2021-04-06 12:54:42 | 2022-02-25 09:10:02 | NULL | 25 | > > compute-04.cloud.pd.infn.it | nova-compute | compute | 1790955 | > > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 09:10:02 > | > > 0 | 40 | e3e7af4d-b25b-410c-983e-8128a5e97219 | > > > +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ > > 4 rows in set (0.00 sec) > > > > > > > > Only after manually setting the version field of these entries to '54', > > nova-conductor and nova-scheduler were able to start > > > > Regards, Massimo > > > > > > [*] > > 2022-02-25 15:06:03.992 591600 CRITICAL nova > > [req-cc20f294-cced-434b-98cd-5bdf228a2a22 - - - - -] Unhandled error: > > nova.exception.TooOldComputeService: Current Nova ve > > rsion does not support computes older than Wallaby but the minimum > compute > > service level in your system is 40 and the oldest supported service level > > is 54. > > 2022-02-25 15:06:03.992 591600 ERROR nova Traceback (most recent call > last): > > 2022-02-25 15:06:03.992 591600 ERROR nova File > "/usr/bin/nova-conductor", > > line 10, in > > 2022-02-25 15:06:03.992 591600 ERROR nova sys.exit(main()) > > 2022-02-25 15:06:03.992 591600 ERROR nova File > > "/usr/lib/python3.6/site-packages/nova/cmd/conductor.py", line 46, in > main > > 2022-02-25 15:06:03.992 591600 ERROR nova topic=rpcapi.RPC_TOPIC) > > 2022-02-25 15:06:03.992 591600 ERROR nova File > > "/usr/lib/python3.6/site-packages/nova/service.py", line 264, in create > > 2022-02-25 15:06:03.992 591600 ERROR nova > utils.raise_if_old_compute() > > 2022-02-25 15:06:03.992 591600 ERROR nova File > > "/usr/lib/python3.6/site-packages/nova/utils.py", line 1098, in > > raise_if_old_compute > > 2022-02-25 15:06:03.992 591600 ERROR nova > > oldest_supported_service=oldest_supported_service_level) > > 2022-02-25 15:06:03.992 591600 ERROR nova > > nova.exception.TooOldComputeService: Current Nova version does not > support > > computes older than Wallaby but the minimum comput > > e service level in your system is 40 and the oldest supported service > level > > is 54. > > 2022-02-25 15:06:03.992 591600 ERROR nova > > > > > > > > On Mon, Jan 10, 2022 at 6:00 PM Massimo Sgaravatto < > > massimo.sgaravatto at gmail.com> wrote: > > > > > Dear all > > > > > > When we upgraded our Cloud from Rocky to Train we followed the > following > > > procedure: > > > > > > 1) Shutdown of all services on the controller and compute nodes > > > 2) Update from Rocky to Stein of controller (just to do the dbsyncs) > > > 3) Update from Stein to Train of controller > > > 4) Update from Rocky to Train of compute nodes > > > > > > We are trying to do the same to update from Train to Xena, but now > there > > > is a problem because > > > nova services on the controller node refuse to start since they find > too > > > old compute nodes (this is indeed a new feature, properly documented > in the > > > release notes). > > > As a workaround we had to manually modify the "version" field of the > > > compute nodes in the nova.services table. > > > > > > Is it ok, or is there a cleaner way to manage the issue ? > > > > > > Thanks, Massimo > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernandoperches at gmail.com Fri Feb 25 20:12:01 2022 From: fernandoperches at gmail.com (Fernando Ferraz) Date: Fri, 25 Feb 2022 17:12:01 -0300 Subject: [manila] Yoga FFE request Message-ID: Hi Team, I'd like to request a FFE for the following changes we have been working on for the Yoga cycle. They are all part of the effort to partially implement spec *Add spec for multiple subnet share servers* *[1]* in Manila.: 826928: Support multiple subnets per AZ https://review.opendev.org/c/openstack/python-manilaclient/+/826928 826462: Container: Multiple subnets per AZ https://review.opendev.org/c/openstack/manila/+/826462 825155: NetApp ONTAP: Add support to multiple subnets per AZ https://review.opendev.org/c/openstack/manila/+/825155 826928: Support multiple subnets per AZ https://review.opendev.org/c/openstack/python-manilaclient/+/826928 All changes were submitted in time and there has been significant progress in reviews until this point. [1] https://review.opendev.org/c/openstack/manila-specs/+/619925 Regards, Fernando -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Feb 25 22:19:58 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 25 Feb 2022 16:19:58 -0600 Subject: [all][tc] What's happening in Technical Committee: summary 25th Feb, 21: Reading: 5 min Message-ID: <17f32f82936.d4bbbc43174720.8640609979346638738@ghanshyammann.com> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on 24th. 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-24-15.00.log.html * Next week's meeting is on 4th March Thursday 15:00 UTC, feel free to add the topic on the agenda[1] by 3rd March. 2. What we completed this week: ========================= * Zed cycle technical election[2] * Switch Keystone back to PTL model[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 ----------------- * Eight open reviews for ongoing activities[5]. Zed cycle Leaderless projects ---------------------------------- As elections are closed, 17 projects are missing the nomination and out of those 11 have the late nomination. 6 projects are still seeking leaders. As the next step, TC will work on the assignment of leaders if we find any other steps on these leaderless projects[6]. Zed cycle testing runtime ------------------------------ I started the Zed cycle testing runtime, please check and give any objection if there is any[7] PTG Preparation -------------------- I have started the etherpad for TC PTG[8] preparation as well as for TC+Community Leaders sessions[9]. Also, doodle poll to select the slots[10] Testing and bumping the lower bounds in requirements.txt --------------------------------------------------------------------- Brian brought this topic while there was discussion on os-bricks bumping the minimum in requirements.rst[11]. As we do not test the lower bounds, we are not sure if existing lower bounds work or not. Telling anyone to reply on those is no guarantee that they will work or not. As TC, we agreed to give more clear direction on lower bounds and that is why we will discuss this topic in Zed PTG. Meanwhile, os-brick bumping the minimum is fine. Release identification and release name ----------------------------------------------- The proposal is under review and updates [12] Dropping tags framework ------------------------------ part1 of this is merged[13], part-2 of updating release script and other tags migration is under-progress. TC position on release cadence ------------------------------------- The proposal is under review and updates [14]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[15]. Project updates ------------------- * Retire js-openstack-lib (waiting on Adjutant to have new PTL/maintainer) [16] 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[17]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [18] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027412.html http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411.html [3] https://review.opendev.org/c/openstack/governance/+/829037 [4] https://etherpad.opendev.org/p/tc-yoga-tracker [5] https://review.opendev.org/q/projects:openstack/governance+status:open [6] https://etherpad.opendev.org/p/zed-leaderless [7] https://review.opendev.org/c/openstack/governance/+/830454 [8] https://etherpad.opendev.org/p/tc-zed-ptg [9] https://etherpad.opendev.org/p/tc-ptl-interaction-zed [10] https://doodle.com/poll/gz4dy67vmew5wmn9 https://doodle.com/poll/dcer6i3wk2b8eim3 [11] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027343.html https://review.opendev.org/c/openstack/os-brick/+/828802 [12] https://review.opendev.org/c/openstack/governance/+/829563 [13] https://review.opendev.org/c/openstack/governance/+/822900 [14] https://review.opendev.org/c/openstack/governance/+/828777 [15] https://etherpad.opendev.org/p/zuul-config-error-openstack [16] https://review.opendev.org/c/openstack/governance/+/798540 [17] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [18] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann From gouthampravi at gmail.com Fri Feb 25 22:34:46 2022 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Fri, 25 Feb 2022 14:34:46 -0800 Subject: [manila] Yoga FFE request In-Reply-To: References: Message-ID: On Fri, Feb 25, 2022 at 12:20 PM Fernando Ferraz wrote: > > Hi Team, > > I'd like to request a FFE for the following changes we have been working on for the Yoga cycle. They are all part of the effort to partially implement spec Add spec for multiple subnet share servers [1] in Manila. > > 826928: Support multiple subnets per AZ > https://review.opendev.org/c/openstack/python-manilaclient/+/826928 Thanks for bringing attention to this. I've a question regarding the manila client patch below -- but I think you meant to link the server-side patch here: https://review.opendev.org/c/openstack/manila/+/825110 > > 826462: Container: Multiple subnets per AZ > https://review.opendev.org/c/openstack/manila/+/826462 > > 825155: NetApp ONTAP: Add support to multiple subnets per AZ > https://review.opendev.org/c/openstack/manila/+/825155 +1 I am okay granting an FFE for the three patches above knowing that we've been reviewing these patches closely for the past few weeks, fixing any major issues. User feedback has been very welcome in designing and vetting the feature implementation, and I appreciate the efforts you have been putting into maintaining the regression testing and covering the new functionality with a good number of e2e tests. The impact of this FFE would mean lesser time for folks to report issues before our RC1 build (due March 10th 2022). So, let's try to keep that in mind. > > 826928: Support multiple subnets per AZ > https://review.opendev.org/c/openstack/python-manilaclient/+/826928 We've made the final manilaclient release for the Yoga cycle: http://lists.openstack.org/pipermail/release-announce/2022-February/012574.html So this FFE here would affect the lib freeze; what are the disadvantages of waiting for the Z cycle for this one? Just a couple of weeks away - and users could always use newer clients with older servers. > > All changes were submitted in time and there has been significant progress in reviews until this point. > > [1] https://review.opendev.org/c/openstack/manila-specs/+/619925 > > Regards, > Fernando From gouthampravi at gmail.com Fri Feb 25 23:12:41 2022 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Fri, 25 Feb 2022 15:12:41 -0800 Subject: [manila] RC1 bugsquash next week, no weekly IRC meetings until 17th March 2022 Message-ID: Hello there zorillas, It's time again to gather and squash some bugs together! We're hosting a bugsquash week between 3rd March 2022 and 10th March 2022. We've a preliminary list of bugs scoped out [1]. We'd love for you to participate by claiming a bug or two to fix during the week and reviewing bug fixes. Some of these bug fixes are in-progress, and we'll be conducting collaborative reviews to merge them during the week. If you'd like to work on something, please add it to the list [1] We'll use meetpad [2] to hang out opportunistically during the week at different times to review code or brainstorm, please watch the chatter on OFTC's #openstack-manila. However, a few scheduled events: * We'll have a kick-off at 1500 UTC on 3rd March 2022 * A "almost there" check in on 8th March 2022 at 1600 UTC on 8th March 2022 * A collab-review for S-RBAC tempest tests [3] at 1430 UTC on 10th March 2022 * A wrap up for the bugsquash week at 1530 UTC on 10th March 2022 All these will occur in the meetpad room; and these times overlap with our weekly IRC meetings - so we'll skip those. If you have any topics to discuss, please call our attention on this mailing list or on OFTC's #openstack-manila. Thanks, and hope to see you there! Goutham [1] https://ethercalc.openstack.org/t727llczm00f [2] https://meetpad.opendev.org/ManilaYogaRC1Bugsquash [3] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027329.html From gouthampravi at gmail.com Fri Feb 25 23:15:56 2022 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Fri, 25 Feb 2022 15:15:56 -0800 Subject: [Manila] Manila Collaborative Review Session - Thursday, March 10th In-Reply-To: References: Message-ID: On Thu, Feb 17, 2022 at 5:18 AM Liron Kuchlani wrote: > > Hi all, > > We are planning a Manila collaborative review session on Thursday, March 10th, to walk through the following proposed feature: > > Add S-RBAC tests for manila [1] > > The session will start at 14:30 UTC and continue through the first half of the weekly upstream manila community meeting as needed. > We will use an etherpad [2] during the session to capture notes and discussions. Thanks for setting this up, Liron.. Since this coincides with the end of the bugsquash week we were planning, we can stick to one meetpad room: https://meetpad.opendev.org/ManilaYogaRC1Bugsquash Hope that's alright with you. Feel free to add/take any notes in a section on the same pad. > > Hope you can all join us, > > > [1] https://review.opendev.org/c/openstack/manila-tempest-plugin/+/805938 > [2] https://etherpad.opendev.org/p/Manila-S-RBAC-collaborative-review -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernandoperches at gmail.com Sat Feb 26 03:02:28 2022 From: fernandoperches at gmail.com (Fernando Ferraz) Date: Sat, 26 Feb 2022 00:02:28 -0300 Subject: [manila] Yoga FFE request In-Reply-To: References: Message-ID: Hi Goutham! sorry for the mistake. Yes, I meant the server-side patch https://review.opendev.org/c/openstack/manila/+/825110 but miscopied the link. Regarding the CLI patch, I'm ok with deferring it to the next release. I believe that there is no harm in waiting for Z since all functionalities will be available through APIs. Regards, Fernando Em sex., 25 de fev. de 2022 ?s 19:34, Goutham Pacha Ravi < gouthampravi at gmail.com> escreveu: > On Fri, Feb 25, 2022 at 12:20 PM Fernando Ferraz > wrote: > > > > Hi Team, > > > > I'd like to request a FFE for the following changes we have been working > on for the Yoga cycle. They are all part of the effort to partially > implement spec Add spec for multiple subnet share servers [1] in Manila. > > > > 826928: Support multiple subnets per AZ > > https://review.opendev.org/c/openstack/python-manilaclient/+/826928 > > Thanks for bringing attention to this. > > I've a question regarding the manila client patch below -- but I think > you meant to link the server-side patch here: > https://review.opendev.org/c/openstack/manila/+/825110 > > > > > 826462: Container: Multiple subnets per AZ > > https://review.opendev.org/c/openstack/manila/+/826462 > > > > 825155: NetApp ONTAP: Add support to multiple subnets per AZ > > https://review.opendev.org/c/openstack/manila/+/825155 > > +1 I am okay granting an FFE for the three patches above knowing that > we've been reviewing these patches closely for the past few weeks, > fixing any major issues. User feedback has been very welcome in > designing and vetting the feature implementation, and I appreciate the > efforts you have been putting into maintaining the regression testing > and covering the new functionality with a good number of e2e tests. > > The impact of this FFE would mean lesser time for folks to report > issues before our RC1 build (due March 10th 2022). So, let's try to > keep that in mind. > > > > > 826928: Support multiple subnets per AZ > > https://review.opendev.org/c/openstack/python-manilaclient/+/826928 > > We've made the final manilaclient release for the Yoga cycle: > > http://lists.openstack.org/pipermail/release-announce/2022-February/012574.html > So this FFE here would affect the lib freeze; what are the > disadvantages of waiting for the Z cycle for this one? Just a couple > of weeks away - and users could always use newer clients with older > servers. > > > > > All changes were submitted in time and there has been significant > progress in reviews until this point. > > > > [1] https://review.opendev.org/c/openstack/manila-specs/+/619925 > > > > Regards, > > Fernando > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sat Feb 26 04:05:52 2022 From: satish.txt at gmail.com (Satish Patel) Date: Fri, 25 Feb 2022 23:05:52 -0500 Subject: [Magnum] heat-container-agent not able to talk to keystone Message-ID: Folks, I am trying to deploy k8s cluster using magnum on openstack and found cluster creation stuck during kube master heat deployment and when i look into logs i found following Feb 25 22:09:26 k8s-foo-jqpxkt2y7e46-master-0 heat-container-agent[2342]: Authorization failed: Unable to establish connection to http://192.168.75.100:5000/v3/auth/tokens Feb 25 22:09:26 k8s-foo-jqpxkt2y7e46-master-0 heat-container-agent[2342]: Source [heat] Unavailable. Feb 25 22:09:26 k8s-foo-jqpxkt2y7e46-master-0 podman[2311]: Authorization failed: Unable to establish connection to http://192.168.75.100:5000/v3/auth/tokens Feb 25 22:09:26 k8s-foo-jqpxkt2y7e46-master-0 podman[2311]: Source [heat] Unavailable. In my deployment it's a private cloud so all control plane components running on private address space and k8s cluster created their own private network which is not routable so the kube master node can't talk to keystone. I can't put my HAProxy on a public address. In that case what are the options I have? I am running OVN for networking deployed by kolla-ansible. ~S -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Sat Feb 26 12:54:21 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sat, 26 Feb 2022 12:54:21 +0000 Subject: [Manila] Manila Collaborative Review Session - Thursday, March 10th In-Reply-To: References: Message-ID: <20220226125420.7r66uk6xglsepbqo@yuggoth.org> On 2022-02-25 15:15:56 -0800 (-0800), Goutham Pacha Ravi wrote: [...] > Since this coincides with the end of the bugsquash week we were > planning, we can stick to one meetpad room: > https://meetpad.opendev.org/ManilaYogaRC1Bugsquash > Hope that's alright with you. Feel free to add/take any notes in a > section on the same pad. [...] Be aware that, due to differences in case-sensitivity of URLs between Jitsi-Meet and Etherpad, the corresponding pad URL for that Meetpad room is going to be https://etherpad.opendev.org/p/manilayogarc1bugsquash (all lower-case). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From rosmaita.fossdev at gmail.com Sat Feb 26 16:32:26 2022 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Sat, 26 Feb 2022 11:32:26 -0500 Subject: [cinder] Yoga FEATURE FREEZE in effect Message-ID: Hello Argonauts, Having passed Milestone-3 this week (and yes, it was painful), let's evaluate where we are with cinder Yoga features: - https://blueprints.launchpad.net/cinder/yoga Note: You must apply for a Feature Freeze Exception (FFE) by 17:00 UTC on Tuesday 1 March. Features granted an FFE must be in the gate by 20:00 UTC on Monday 7 March. Being granted an FFE is not a guarantee that your feature will be included in Yoga. Note to reviewers: please concentrate on the below over the next week. 1. Complete transition to Alembic - https://blueprints.launchpad.net/cinder/+spec/complete-transition-to-alembic - this is essential technical debt elimination - has a Feature Freeze Exception 2. Reset State Robustification - https://blueprints.launchpad.net/cinder/+spec/reset-state-robustification - Tushar has been working patiently on this forever - not a destabilizing change - has a Feature Freeze Exception - let's prioritize getting the base patch reviewed and merged, and we can see how far we can work up the stack before 7 March. - https://review.opendev.org/c/openstack/cinder/+/773985/ Driver features 3. HPE Nimble driver rename - https://blueprints.launchpad.net/cinder/+spec/nimble-change-location - https://review.opendev.org/c/openstack/cinder/+/786054 - has one +2 - patch has passed third party CI configured with the old name *and* with the rename - has an FFE Hitachi VSP driver The below require this non-feature patch, which addresses followup issues - https://review.opendev.org/c/openstack/cinder/+/827259/ - has one +2 - doesn't need an FFE because it's a bugfix, but let's get it reviewed and merged! 4. Support AIX as host OS type for VSP Driver - https://blueprints.launchpad.net/cinder/+spec/hitachi-vsp-aix-os-type - https://review.opendev.org/c/openstack/cinder/+/828061 - has one +2 - has an FFE 5. Target Port Assignment for VSP Driver - https://blueprints.launchpad.net/cinder/+spec/hitachi-vsp-tgt-port-asgn - https://review.opendev.org/c/openstack/cinder/+/828060 - has one +2 - has an FFE Questionable: 1. The Return of Make Cinder Consistent and Secure RBAC Ready - https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-y - community goal - I will meet with the cinder Zed PTL to discuss what to do about this one (may give a FFE for just part) 2. Hitachi: Port Scheduler for VSP Driver - https://blueprints.launchpad.net/cinder/+spec/hitachi-vsp-port-scheduler - https://review.opendev.org/c/openstack/cinder/+/828696 - Code and tests look mostly fine, and CI is passing - some really minor issues and needs a release note - needs to be rebased on latest version of 828060 - not giving an auto-FFE because it hasn't had a +2 yet - must apply for an FFE 3. ibm-svf-portset - https://blueprints.launchpad.net/cinder/+spec/ibm-svf-portset - https://review.opendev.org/c/openstack/cinder/+/817351 - no +2s because third-party CI isn't passing - let's face it, no one is going to review this with failing CI even if it gets an FFE - must apply for an FFE From gouthampravi at gmail.com Sat Feb 26 23:06:01 2022 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Sat, 26 Feb 2022 15:06:01 -0800 Subject: [Manila] Manila Collaborative Review Session - Thursday, March 10th In-Reply-To: <20220226125420.7r66uk6xglsepbqo@yuggoth.org> References: <20220226125420.7r66uk6xglsepbqo@yuggoth.org> Message-ID: On Sat, Feb 26, 2022 at 5:04 AM Jeremy Stanley wrote: > On 2022-02-25 15:15:56 -0800 (-0800), Goutham Pacha Ravi wrote: > [...] > > Since this coincides with the end of the bugsquash week we were > > planning, we can stick to one meetpad room: > > https://meetpad.opendev.org/ManilaYogaRC1Bugsquash > > Hope that's alright with you. Feel free to add/take any notes in a > > section on the same pad. > [...] > > Be aware that, due to differences in case-sensitivity of URLs > between Jitsi-Meet and Etherpad, the corresponding pad URL for that > Meetpad room is going to be > https://etherpad.opendev.org/p/manilayogarc1bugsquash (all > lower-case). Woah!! Very glad you clarified that :) I thought something was funky about this. > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eduardo.experimental at gmail.com Sat Feb 26 23:31:19 2022 From: eduardo.experimental at gmail.com (Eduardo Santos) Date: Sat, 26 Feb 2022 23:31:19 +0000 Subject: [devstack][openstack-qa] DevStack upgrade betweem major releases Message-ID: Hello folks, What is the procedure for upgrading a DevSack deployment from one major release to another? I didn't find any information on this in the official documentation. [1] My team maintains DevStack deployments used to provision virtual machines to developers. How can we, let's say, upgrade a stable/xena DevStack to stable/yoga, when it's released? Best regards, Eduardo Santos [1] https://docs.openstack.org/devstack/latest/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From berndbausch at gmail.com Sun Feb 27 00:22:09 2022 From: berndbausch at gmail.com (Bernd Bausch) Date: Sun, 27 Feb 2022 09:22:09 +0900 Subject: [devstack][openstack-qa] DevStack upgrade betweem major releases In-Reply-To: References: Message-ID: <443347A4-F8CB-46CF-A402-440B44EC12F9@gmail.com> From the documentation: It is used interactively as a development environment and as the basis for much of the OpenStack project?s functional testing. "Development environment" means an environment for developing OpenStack software, not for running VMs that are used for generic development. It's purpose is to be set up quickly and destroyed after you are done with your development or test. Devstack can't even be rebooted out of the box; I can't imagine that there is a procedure to upgrade Devstack. Perhaps the documentation page should make it clear that it must not be used as a platform for business-critical tasks. Bernd > On Feb 27, 2022, at 8:31, Eduardo Santos wrote: > > Hello folks, > > What is the procedure for upgrading a DevSack deployment from one major release to another? I didn't find any information on this in the official documentation. [1] > > My team maintains DevStack deployments used to provision virtual machines to developers. How can we, let's say, upgrade a stable/xena DevStack to stable/yoga, when it's released? > > Best regards, > Eduardo Santos > > [1] https://docs.openstack.org/devstack/latest/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjensas at redhat.com Sun Feb 27 01:20:39 2022 From: hjensas at redhat.com (Harald Jensas) Date: Sun, 27 Feb 2022 02:20:39 +0100 Subject: Fwd: [Triple0] Upgrade Error In-Reply-To: References: Message-ID: <87333433-63c3-6b52-ab36-8de16dff277d@redhat.com> On 2/25/22 12:21, Lokendra Rathour wrote: > Hi Team, > > we are trying to upgrade *Triple0 Train to Ussuri.* > Undercloud upgrade is done successfully. > *_OverCloud Upgrade:_* > As a first step in overcloud upgrade, we are running " *openstack > overcloud upgrade prepare*? "? command. > which is throwing following error: > > overcloud: ERROR: Property error: > resources.InternalApiVirtualIP.properties: Unknown Property DnsName\n > ?File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line > 891, in __call__\n ? ?request, **action_args)\n ?File > \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in > dispatch\n ? ?return method(*args, **kwargs)\n ?File > \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\", line > 56, in handle_stack_method\n ? ?return handler(controller, req, > **kwargs)\n ?File > \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\", > line 633, in validate_template\n ? ?raise > exc.HTTPBadRequest(result['Error'])\n", "success": false}* > The DnsName property was added to templats in Ussuri, this change: https://review.opendev.org/c/openstack/tripleo-heat-templates/+/715883 Somewhere in you environment files you are mapping `OS::TripleO::Network::Ports::InternalApiVipPort` to a local template file instead of using the in-tree template. You either need to add DnsName paramter to your local VipPort template, or change the resource_registry so that you map to the in-tree port template. `/usr/share/openstack-tripleo-heat-template/network/ports/internal_api.yaml` is the in-tree template you want. > *_Command used to run the overcloud upgrade prepare:_* > > *(undercloud) [stack at undercloud ~]$ cat upgrade_overcloud_prepare.sh > openstack overcloud upgrade prepare --templates \ > ? ? -r /home/stack/templates/roles_data.yaml \ > ? ? -n /home/stack/templates/network_data.yaml \ > ? ? -e /home/stack/templates/environment.yaml \ > ? ? -e /home/stack/templates/environments/network-isolation.yaml \ Most likely the mapping is in this network-isolation.yaml. If you use the in-tree environment `/usr/share/openstack-tripleo-heat-tempaltes/envioronments/network-isolation.yaml` instead you should not run into these type of issues on upgrade. > ? ? -e /home/stack/templates/environments/network-environment.yaml \ I would also recommend to use the in-tree network-environment.yaml -e /usr/share/openstack-tripleo-heat-tempaltes/envioronments/network-environment.yaml Then add another file to override anything in the in-tree network-environment.yaml. -e /home/stack/templates/environments/network-environment-overrides.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/templates/init-repo.yaml \ > ? ? -e /home/stack/containers-prepare-parameter.yaml -- Harald From rlandy at redhat.com Sun Feb 27 15:37:22 2022 From: rlandy at redhat.com (Ronelle Landy) Date: Sun, 27 Feb 2022 10:37:22 -0500 Subject: [TripleO] Gate blocker - centos-9 standalone and multinode In-Reply-To: References: Message-ID: On Fri, Feb 25, 2022 at 7:49 AM Bhagyashri Shewale wrote: > Hi All, > > We have an issue affecting standalone and multinode > centos-9 check/gate jobs due to tempest test failure. > > Details: https://bugs.launchpad.net/tripleo/+bug/1962298 > > We are currently deciding on the best course of action for unblocking > this issue. We will post an update once the check/gate is clear. > > Until then, please hold on rechecking. > A workaround was implemented in https://review.opendev.org/c/openstack/tripleo-quickstart/+/830996. More investigation is needed to decide on a permanent solution. The gate should be operational again. Thanks > > Thanks and Regards > Bhagyashri Shewale > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Sun Feb 27 17:25:14 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Sun, 27 Feb 2022 11:25:14 -0600 Subject: [devstack][openstack-qa] DevStack upgrade betweem major releases In-Reply-To: <443347A4-F8CB-46CF-A402-440B44EC12F9@gmail.com> References: <443347A4-F8CB-46CF-A402-440B44EC12F9@gmail.com> Message-ID: <17f3c370a43.ec63f60c206092.3469593369820396625@ghanshyammann.com> ---- On Sat, 26 Feb 2022 18:22:09 -0600 Bernd Bausch wrote ---- > From the documentation: > It is used interactively as a development environment and as the basis for much of the OpenStack project?s functional testing. > "Development environment" means an environment for developing OpenStack software, not for running VMs that are used for generic development. It's purpose is to be set up quickly and destroyed after you are done with your development or test. Devstack can't even be rebooted out of the box; I can't imagine that there is a procedure to upgrade Devstack. > Perhaps the documentation page should make it clear that it must not be used as a platform for business-critical tasks. > > Bernd > On Feb 27, 2022, at 8:31, Eduardo Santos wrote: > > Hello folks, > What is the procedure for upgrading a DevSack deployment from one major release to another? I didn't find any information on this in the official documentation. [1] > My team maintains DevStack deployments used to provision virtual machines to developers. How can we, let's say, upgrade a stable/xena DevStack to stable/yoga, when it's released? Yes, there is no upgrade procedure for DevStack. And yes, it is intended to be used for OpenStack testing as mentioned in doc also. I am not 100% sure about your usage of DevStack for developers if that is for their development env for any other software or OpenStack dev/testing. But in any case, If you want to move to the latest version of DevStack, the best way is to clone the latest (or specific release) source code and install it as fresh. If you try to update the existing devstack to the latest release code and run ./stach.sh again, it is no guarantee that it will work. If you want to create the permanent dev env for the developer, I will suggest you try some other deployment project like Kolla, OSA etc. -gmann > > Best regards,Eduardo Santos > [1] https://docs.openstack.org/devstack/latest/ From hanguangyu2 at gmail.com Mon Feb 28 08:28:58 2022 From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=) Date: Mon, 28 Feb 2022 16:28:58 +0800 Subject: [Ironic] No suitable device was found for deployment In-Reply-To: References: <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch> Message-ID: Hi Arne, I didn't find hardware RAID config option during the initial boot sequence. Ctrl+H is unresponsive in this computer. I just saw "Press Del to enter firmware configuration, press F3 to enter boot menu, and press F12 to enter network boot". And I press 'Del' to enter the BIOS. But I didn't find RAID config menu in BIOS. Sorry that I have poor knowledge about this. And now, even though I installed the operating system manually using a USB stick, I still couldn't find the hard drive. Is there anything that ironic-agent did in the clean phase that would have caused this problem? I wonder if this is a thinking pointto solve the problem. Now, my idea is to first find a way to manually configure RAID. Do you agree with this? And than, whether RAID configurations are still cleared in the Clean phase if clean phase will do this? Sorry that I have so much confuse. love you, Guangyu Arne Wiebalck ?2022?2?14??? 15:59??? > > 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 > > > 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 ?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 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 ?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 arne.wiebalck at cern.ch Mon Feb 28 09:12:27 2022 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Mon, 28 Feb 2022 10:12:27 +0100 Subject: [Ironic] No suitable device was found for deployment In-Reply-To: References: <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch> Message-ID: <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch> Hi Guangyu, I am not aware of anything in the Ironic Python Agent that would remove disks from the system in a way that they would not be visible after a reboot (apart from, as mentioned before, the clean up of a hardware RAID in a way the IPA is not able to see any devices after). How about trying to access and configure the hardware RAID with the corresponding tool from the RAM disk you booted into from the USB stick? Install the tool and see if it detects the controller. The very first step before doing anything with Ironic is to get the disks back or understand why they are not visible. Cheers, Arne On 28.02.22 09:28, ??? wrote: > Hi Arne, > > I didn't find hardware RAID config option during the initial boot > sequence. Ctrl+H is unresponsive in this computer. I just saw "Press > Del to enter firmware configuration, press F3 to enter boot menu, and > press F12 to enter network boot". And I press 'Del' to enter the BIOS. > But I didn't find RAID config menu in BIOS. Sorry that I have poor > knowledge about this. > > And now, even though I installed the operating system manually using a > USB stick, I still couldn't find the hard drive. Is there anything > that ironic-agent did in the clean phase that would have caused this > problem? > > I wonder if this is a thinking pointto solve the problem. Now, my idea > is to first find a way to manually configure RAID. Do you agree with > this? And than, whether RAID configurations are still cleared in the > Clean phase if clean phase will do this? > > Sorry that I have so much confuse. > > love you, > Guangyu > > Arne Wiebalck ?2022?2?14??? 15:59??? >> >> 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 >>> >> 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 ?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 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 ?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 hanguangyu2 at gmail.com Mon Feb 28 09:22:29 2022 From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=) Date: Mon, 28 Feb 2022 17:22:29 +0800 Subject: [Ironic] No suitable device was found for deployment In-Reply-To: <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch> References: <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch> <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch> Message-ID: Hi Arne, Yes, your idea is so good. I will try to "install tool in RAM disk" and "access and configure the hardware RAID with the corresponding tool from the RAM disk" Best wishes to you. Cheers, Guangyu Arne Wiebalck ?2022?2?28??? 17:12??? > > Hi Guangyu, > > I am not aware of anything in the Ironic Python Agent that > would remove disks from the system in a way that they would > not be visible after a reboot (apart from, as mentioned before, > the clean up of a hardware RAID in a way the IPA is not able > to see any devices after). > > How about trying to access and configure the hardware RAID with > the corresponding tool from the RAM disk you booted into from the > USB stick? Install the tool and see if it detects the controller. > > The very first step before doing anything with Ironic is to > get the disks back or understand why they are not visible. > > Cheers, > Arne > > On 28.02.22 09:28, ??? wrote: > > Hi Arne, > > > > I didn't find hardware RAID config option during the initial boot > > sequence. Ctrl+H is unresponsive in this computer. I just saw "Press > > Del to enter firmware configuration, press F3 to enter boot menu, and > > press F12 to enter network boot". And I press 'Del' to enter the BIOS. > > But I didn't find RAID config menu in BIOS. Sorry that I have poor > > knowledge about this. > > > > And now, even though I installed the operating system manually using a > > USB stick, I still couldn't find the hard drive. Is there anything > > that ironic-agent did in the clean phase that would have caused this > > problem? > > > > I wonder if this is a thinking pointto solve the problem. Now, my idea > > is to first find a way to manually configure RAID. Do you agree with > > this? And than, whether RAID configurations are still cleared in the > > Clean phase if clean phase will do this? > > > > Sorry that I have so much confuse. > > > > love you, > > Guangyu > > > > Arne Wiebalck ?2022?2?14??? 15:59??? > >> > >> 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 > >>> >>> 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 ?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 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 ?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 balazs.gibizer at est.tech Mon Feb 28 11:14:54 2022 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 28 Feb 2022 12:14:54 +0100 Subject: [ops][nova] How to update from N to N+3 (and manage nova services that don't start because they find too old compute nodes...) In-Reply-To: References: <2a10186d792e8ace7a3753f5c86686ac0e4af873.camel@redhat.com> Message-ID: On Fri, Feb 25 2022 at 05:57:26 PM +0100, Massimo Sgaravatto wrote: > Thanks > This "disable_compute_service_check_for_ffu" option is not available > in xena, correct ? Not yet. But now I've proposed the backport of that fix to stable/xena[1] Cheers, gibi [1] https://review.opendev.org/c/openstack/nova/+/831174 > Cheers, Massimo > > On Fri, Feb 25, 2022 at 5:15 PM Sean Mooney > wrote: >> On Fri, 2022-02-25 at 16:50 +0100, Massimo Sgaravatto wrote: >> > I had the chance to repeat this test >> > So the scenario is: >> > >> > 1) controller and compute nodes running train >> > 2) all services stopped in compute nodes >> > 3) controller updated: train-->ussuri-->victoria--> wallaby >> > >> > After that nova conductor and nova scheduler refuses to start [*] >> >> yes nova does not offially support n to n+3 upgrade >> we started enforcing that a few release ago. >> there is a workaround config option that we recently added that >> turns >> the error into a waring >> https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_compute_service_check_for_ffu >> that is one option or you can implement or before you upgrade the >> contoler you can force-down all the comptue nodes >> >> >> >> > >> > At that moment nova-compute services were not running on the >> compute nodes >> > And this was the status on the services table: >> > >> > mysql> select * from services where topic="compute"; >> > >> +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ >> > > created_at | updated_at | deleted_at | id | >> host >> > | binary | topic | report_count | >> disabled | >> > deleted | disabled_reason | last_seen_up >> | >> > forced_down | version | uuid | >> > >> +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ >> > > 2018-01-11 17:20:34 | 2022-02-25 09:09:17 | NULL | 17 | >> > compute-01.cloud.pd.infn.it | nova-compute | compute | >> 10250811 | >> > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 >> 09:09:13 | >> > 0 | 40 | 2f56b8cf-1190-4999-af79-6bcee695c653 | >> > > 2018-01-11 17:26:39 | 2022-02-25 09:09:49 | NULL | 23 | >> > compute-02.cloud.pd.infn.it | nova-compute | compute | >> 10439622 | >> > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 >> 09:09:49 | >> > 0 | 40 | fbe37dfd-4a6c-4da1-96e0-407f7f98c4c4 | >> > > 2018-01-11 17:27:12 | 2022-02-25 09:10:02 | NULL | 24 | >> > compute-03.cloud.pd.infn.it | nova-compute | compute | >> 10361295 | >> > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 >> 09:10:02 | >> > 0 | 40 | 3675f324-81dd-445a-b4eb-510726104be3 | >> > > 2021-04-06 12:54:42 | 2022-02-25 09:10:02 | NULL | 25 | >> > compute-04.cloud.pd.infn.it | nova-compute | compute | >> 1790955 | >> > 1 | 0 | AUTO: Connection to libvirt lost: 1 | 2022-02-25 >> 09:10:02 | >> > 0 | 40 | e3e7af4d-b25b-410c-983e-8128a5e97219 | >> > >> +---------------------+---------------------+------------+----+-----------------------------+--------------+---------+--------------+----------+---------+-------------------------------------+---------------------+-------------+---------+--------------------------------------+ >> > 4 rows in set (0.00 sec) >> > >> > >> > >> > Only after manually setting the version field of these entries to >> '54', >> > nova-conductor and nova-scheduler were able to start >> > >> > Regards, Massimo >> > >> > >> > [*] >> > 2022-02-25 15:06:03.992 591600 CRITICAL nova >> > [req-cc20f294-cced-434b-98cd-5bdf228a2a22 - - - - -] Unhandled >> error: >> > nova.exception.TooOldComputeService: Current Nova ve >> > rsion does not support computes older than Wallaby but the >> minimum compute >> > service level in your system is 40 and the oldest supported >> service level >> > is 54. >> > 2022-02-25 15:06:03.992 591600 ERROR nova Traceback (most recent >> call last): >> > 2022-02-25 15:06:03.992 591600 ERROR nova File >> "/usr/bin/nova-conductor", >> > line 10, in >> > 2022-02-25 15:06:03.992 591600 ERROR nova sys.exit(main()) >> > 2022-02-25 15:06:03.992 591600 ERROR nova File >> > "/usr/lib/python3.6/site-packages/nova/cmd/conductor.py", line >> 46, in main >> > 2022-02-25 15:06:03.992 591600 ERROR nova >> topic=rpcapi.RPC_TOPIC) >> > 2022-02-25 15:06:03.992 591600 ERROR nova File >> > "/usr/lib/python3.6/site-packages/nova/service.py", line 264, in >> create >> > 2022-02-25 15:06:03.992 591600 ERROR nova >> utils.raise_if_old_compute() >> > 2022-02-25 15:06:03.992 591600 ERROR nova File >> > "/usr/lib/python3.6/site-packages/nova/utils.py", line 1098, in >> > raise_if_old_compute >> > 2022-02-25 15:06:03.992 591600 ERROR nova >> > oldest_supported_service=oldest_supported_service_level) >> > 2022-02-25 15:06:03.992 591600 ERROR nova >> > nova.exception.TooOldComputeService: Current Nova version does >> not support >> > computes older than Wallaby but the minimum comput >> > e service level in your system is 40 and the oldest supported >> service level >> > is 54. >> > 2022-02-25 15:06:03.992 591600 ERROR nova >> > >> > >> > >> > On Mon, Jan 10, 2022 at 6:00 PM Massimo Sgaravatto < >> > massimo.sgaravatto at gmail.com> wrote: >> > >> > > Dear all >> > > >> > > When we upgraded our Cloud from Rocky to Train we followed the >> following >> > > procedure: >> > > >> > > 1) Shutdown of all services on the controller and compute nodes >> > > 2) Update from Rocky to Stein of controller (just to do the >> dbsyncs) >> > > 3) Update from Stein to Train of controller >> > > 4) Update from Rocky to Train of compute nodes >> > > >> > > We are trying to do the same to update from Train to Xena, but >> now there >> > > is a problem because >> > > nova services on the controller node refuse to start since >> they find too >> > > old compute nodes (this is indeed a new feature, properly >> documented in the >> > > release notes). >> > > As a workaround we had to manually modify the "version" field >> of the >> > > compute nodes in the nova.services table. >> > > >> > > Is it ok, or is there a cleaner way to manage the issue ? >> > > >> > > Thanks, Massimo >> > > >> From amonster369 at gmail.com Mon Feb 28 11:44:23 2022 From: amonster369 at gmail.com (A Monster) Date: Mon, 28 Feb 2022 12:44:23 +0100 Subject: Fluentd error with Kolla ansible deployment Message-ID: I'm getting the following error while trying to deploy openstack using kolla-ansible. I've set up a local docker registry and enabled insecure registries in daemon.json file and I even tried to pull fluentd docker image but I still get the following error TASK [common : Ensure fluentd image is present for label check] fatal: [localhost]: FAILED! => {"changed": true, "msg": "'Traceback (most recent call last):\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http+docker://localhost/v1.41/images/create?tag=xena&fromImage=quay.io%2Fkolla%2Fcentos-source-fluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 1241, in main\\n File \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 1116, in ensure_image\\n File \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 692, in pull_image\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n self._raise_for_status(response)\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.APIError: 500 Server Error for http+docker://localhost/v1.41/images/create?tag=xena&fromImage=quay.io%2Fkolla%2Fcentos-source-fluentd: Internal Server Error (\"unauthorized: access to the requested resource is not authorized\")\\n'"} -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Mon Feb 28 13:20:56 2022 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 28 Feb 2022 14:20:56 +0100 Subject: [neutron] Bug deputy report for week of 21. 02. 2022 Message-ID: Hi Neutron Team I was bug deputy in neutron last week. It was a very quiet week again. Needs More attention ================= * Duplicate IP address on LSPs in the same LS lead to unpredictable flow output (https://bugs.launchpad.net/neutron/+bug/1961046 ) * [ovn-octavia-provider] OVN NB DB timeouts ( https://bugs.launchpad.net/neutron/+bug/1961874 ) ** perhaps not Neutron related, but more a pkg version problem. Critical ====== * Network interface not found in namespace https://bugs.launchpad.net/neutron/+bug/1961740 ** In progress: https://review.opendev.org/c/openstack/neutron/+/830622 High ==== * Transition to SQLAlchemy 2.0 ( https://bugs.launchpad.net/neutron/+bug/1962153) * [Prefix Delegation] router add segment fails with Subnet for router interface must have a gateway IP ( https://bugs.launchpad.net/neutron/+bug/1962306 ) * [ntp] "test_network_attached_with_two_routers" randomly failing ( https://bugs.launchpad.net/neutron/+bug/1962167) ** In progress: https://review.opendev.org/c/openstack/neutron/+/830813 Low ==== * There may be a typo in the neutron document whose the title is 'Manual install & Configuration' (https://bugs.launchpad.net/neutron/+bug/1962324) Invalid ====== * generate_config_file_samples.sh fails with invalid literal for int() with base 10 (https://bugs.launchpad.net/neutron/+bug/1961906) Regards Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Mon Feb 28 13:22:03 2022 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 28 Feb 2022 14:22:03 +0100 Subject: [largescale-sig] Next meeting: Mar 2nd, 15utc Message-ID: <7e4962b0-b479-9ed7-5d69-72a68bcf7a73@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=20220302T15 Feel free to add topics to the agenda: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez From eblock at nde.ag Mon Feb 28 14:04:33 2022 From: eblock at nde.ag (Eugen Block) Date: Mon, 28 Feb 2022 14:04:33 +0000 Subject: Xena and CEPH RBD backend (show_image_direct_url status ) In-Reply-To: Message-ID: <20220228140433.Horde.HqHowF97yyXPEK-I97zzVWP@webmail.nde.ag> Hi, it's disappointing that this is still an issue. We're currently using OpenStack Ussuri with Ceph Nautilus (we plan the Upgrade to Octopus soon) which works fine without enabling show_image_direct_url. The same goes for Victoria and Octopus (one of our customers uses this combination). > How is the noted GRAVE Security RISK of enabling > Show_image_direct_url mitigated ? (i.e I think , for CEPH RBD, it > needs to be True to get cloning to work efficiently) I'm also wondering in which case the location contains credentials, I haven't seen that yet. Depending on how your cloud is used (is it a public or private cloud) maybe enabling the option is not that big of a risk? Regards, Eugen Zitat von "west, andrew" : > Hello experts > > Currently using openstack Xena and Ceph backend (Pacific 16.2.7) > > It seems there is a bug (since Wallaby?) where the efficient use of > a CEPH Pacific RBD backend (i.e with copy-on-write-cloning) is not > working . > Show_image_direct_url needs to be False to create volumes (or > ephemeral volumes for nova) > > This can of course be tremendously slow (Nova , ephemeral root > disk) without copy-on-write cloning feature of Ceph. > > As Ceph RBD is THE most favourite backend for block storage in > openstack I am wondering how others are coping (or workarounds found > ?) > Which combinations of Openstack and Ceph are known to work well > with copy-on-write-cloning? > > How is the noted GRAVE Security RISK of enabling > Show_image_direct_url mitigated ? (i.e I think , for CEPH RBD, it > needs to be True to get cloning to work efficiently) > > > See another report of this issue here: > Re: Ceph Pacifif and Openstack Wallaby - ERROR > cinder.scheduler.flows.create_volume - CEPH Filesystem Users > (spinics.net) > > Thanks for any help or pointers, > > Andrew West > Openstack consulting > CGG France > > > ________________________________ > "This e-mail and any accompanying attachments are confidential. The > information is intended solely for the use of the individual to whom > it is addressed. Any review, disclosure, copying, distribution, or > use of the email by others is strictly prohibited. If you are not > the intended recipient, you must not review, disclose, copy, > distribute or use this e-mail; please delete it from your system and > notify the sender immediately." From katonalala at gmail.com Mon Feb 28 14:38:41 2022 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 28 Feb 2022 15:38:41 +0100 Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas Bolivar for ovn-octavia-provider core reviewer Message-ID: Hi I would like to propose Luis Tomas Bolivar (ltomasbo) as a core reviewer to the ovn-octavia-provider project. Luis is very active in the project (see [1] and [2]) and has experience with Kuryr side also which uses ovn-octavia-provider. As ovn-octavia-provider is a link between Neutron and Octavia I ask both Neutron and Octavia cores to vote by answering to this thread, to have a final decision. Thanks for your consideration [1]: https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master [2]: https://www.stackalytics.io/report/contribution?module=neutron-group&project_type=openstack&days=60 Cheers Lajos -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Mon Feb 28 15:37:27 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 28 Feb 2022 16:37:27 +0100 Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas Bolivar for ovn-octavia-provider core reviewer In-Reply-To: References: Message-ID: <2232641.ElGaqSPkdT@p1> Hi, On poniedzia?ek, 28 lutego 2022 15:38:41 CET Lajos Katona wrote: > Hi > > I would like to propose Luis Tomas Bolivar (ltomasbo) as a core reviewer to > the ovn-octavia-provider project. > Luis is very active in the project (see [1] and [2]) and has experience > with Kuryr side also which uses ovn-octavia-provider. > > As ovn-octavia-provider is a link between Neutron and Octavia I ask both > Neutron and Octavia cores to vote by answering to this thread, to have a > final decision. > Thanks for your consideration > > [1]: > https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master > [2]: > https://www.stackalytics.io/report/contribution?module=neutron-group&project_ > type=openstack&days=60 > > Cheers > Lajos +1. Luis will be great in the ovn-octavia-provider team for sure :) -- 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: From mathilde.hermet at ovhcloud.com Mon Feb 28 08:45:47 2022 From: mathilde.hermet at ovhcloud.com (Mathilde Hermet) Date: Mon, 28 Feb 2022 09:45:47 +0100 Subject: [horizon][customization] Message-ID: <3aa4a3df-fab3-ccc0-5bc3-821cdb80ce67@ovhcloud.com> Hello Openstack team, I'm currently working on customizing the Horizon (xena) dashboard to use the OVHcloud assets: logo.svg and logo-splash.svg. I've been following this documentation https://docs.openstack.org/horizon/latest/configuration/themes.html I added the ovhcloud theme in horizon/openstack_dashboard/local/local_settings.py in AVAILABLE_THEMES, I created the subdir ovhcloud in horizon/openstack_dashboard/themes and I created a ovhcloud/img with logo.svg and logo-splash.svg in it. I put a _variables.scss and a _styles.scss in /themes/ovhcloud/ Then I executed python manage.py collectstatic It put all the files in horizon-sources/horizon.../static/themes/ovhcloud But then when trying to connect with the session cookie theme="ovhcloud", I have a 500 error. i don't think it comes from images because i've been puting it in /horizon-souurces/horizon.../static/dashbaord.img and they were displayed correctly. Do you have any idea about the misconfiguration I've done ? Best regards, Mathilde Hermet From kennelson11 at gmail.com Mon Feb 28 16:29:13 2022 From: kennelson11 at gmail.com (Kendall Nelson) Date: Mon, 28 Feb 2022 08:29:13 -0800 Subject: [PTLs][release] Yoga Cycle Highligts In-Reply-To: References: Message-ID: Thank you to Blazar, Designate, Glance, Horizon, Ironic, Kuryr, Manila, Neutron and Ocatavia for getting it done! To everyone else! Even if you missed the deadline, it's still REALLY good to get them added to the page for posterity and future reference. We use the page[1] in a lot of release promotions so there is still a point :) -Kendall Nelson (diablo_rojo) [1] https://releases.openstack.org/yoga/highlights.html On Mon, Feb 21, 2022 at 11:53 AM El?d Ill?s wrote: > Hi, > > This is a reminder, that *this week* is the week for Cycle highlights > [1][2]! They need to be added to deliverable yamls so that they can be > included in release marketing preparations. (See the details about how > to add them at the project team guide [3].) > > [1] https://releases.openstack.org/yoga/schedule.html > [2] https://releases.openstack.org/yoga/schedule.html#y-cycle-highlights > [3] > > https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights > > Thanks, > > El?d Ill?s > irc: elodilles > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralonsoh at redhat.com Mon Feb 28 16:33:04 2022 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Mon, 28 Feb 2022 17:33:04 +0100 Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas Bolivar for ovn-octavia-provider core reviewer In-Reply-To: <2232641.ElGaqSPkdT@p1> References: <2232641.ElGaqSPkdT@p1> Message-ID: +1. Luis has a good knowledge of the ovn-octavia-provider project and he is an active collaborator. On Mon, Feb 28, 2022 at 4:45 PM Slawek Kaplonski wrote: > Hi, > > On poniedzia?ek, 28 lutego 2022 15:38:41 CET Lajos Katona wrote: > > Hi > > > > I would like to propose Luis Tomas Bolivar (ltomasbo) as a core reviewer > to > > the ovn-octavia-provider project. > > Luis is very active in the project (see [1] and [2]) and has experience > > with Kuryr side also which uses ovn-octavia-provider. > > > > As ovn-octavia-provider is a link between Neutron and Octavia I ask both > > Neutron and Octavia cores to vote by answering to this thread, to have a > > final decision. > > Thanks for your consideration > > > > [1]: > > https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master > > [2]: > > > https://www.stackalytics.io/report/contribution?module=neutron-group&project_ > > type=openstack&days=60 > > > > Cheers > > Lajos > > +1. Luis will be great in the ovn-octavia-provider team for sure :) > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From gthiemonge at redhat.com Mon Feb 28 16:45:13 2022 From: gthiemonge at redhat.com (Gregory Thiemonge) Date: Mon, 28 Feb 2022 17:45:13 +0100 Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas Bolivar for ovn-octavia-provider core reviewer In-Reply-To: References: Message-ID: +1 from me On Mon, Feb 28, 2022 at 3:44 PM Lajos Katona wrote: > Hi > > I would like to propose Luis Tomas Bolivar (ltomasbo) as a core reviewer > to the ovn-octavia-provider project. > Luis is very active in the project (see [1] and [2]) and has experience > with Kuryr side also which uses ovn-octavia-provider. > > As ovn-octavia-provider is a link between Neutron and Octavia I ask both > Neutron and Octavia cores to vote by answering to this thread, to have a > final decision. > Thanks for your consideration > > [1]: > https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master > [2]: > https://www.stackalytics.io/report/contribution?module=neutron-group&project_type=openstack&days=60 > > Cheers > Lajos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Mon Feb 28 16:50:40 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 28 Feb 2022 10:50:40 -0600 Subject: [all][tc] Technical Committee next weekly meeting on Mar 4th at 1500 UTC Message-ID: <17f413dc13b.1112c1076280164.9078145143439661308@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Mar 4th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Mar 3rd, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From mthode at mthode.org Mon Feb 28 16:56:09 2022 From: mthode at mthode.org (Matthew Thode) Date: Mon, 28 Feb 2022 10:56:09 -0600 Subject: [nova][octavia][masakari][designate][oslo][requirements] oslo.context>=4.0.0 seems to need updated tests Message-ID: <20220228165609.zzz7ur2mktfrqmue@mthode.org> The update to see what's breaking is here https://review.opendev.org/829599 Feel free to make that patch depend on your fix to test (with rechecks) -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Molka.Gharbaoui at santannapisa.it Mon Feb 28 16:58:50 2022 From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui) Date: Mon, 28 Feb 2022 16:58:50 +0000 Subject: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi Message-ID: Hi all, I installed devstack and ceilometer by adding the following lines in the local.conf file: enable_plugin ceilometer https://opendev.org/openstack/ceilometer.git CEILOMETER_BACKEND=gnocchi Devstack (yoga) works correctly (I am able to create images, instances, etc.). The problem is that I cannot visualize the metrics. Using "gnocchi metric list" and "gnocchi resource list" commands the result is empty. When I use the "--debug" option, no errors are plotted but the body response is empty. "ceilometer-upgrade" gives the following error: DEBUG ceilometer.cmd.storage Upgrade Gnocchi resource types upgrade /opt/stack/ceilometer/ceilometer/cmd/storage.py:42 "ceilometer-polling" prints "The resource could not be found". I have a running instance. Could you help me in retrieving the metrics from openstack? -------------- next part -------------- An HTML attachment was scrubbed... URL: From haailani at in.ibm.com Mon Feb 28 17:02:24 2022 From: haailani at in.ibm.com (Harsha Ailani) Date: Mon, 28 Feb 2022 17:02:24 +0000 Subject: [cinder] Yoga FEATURE FREEZE in effect Message-ID: Hello Argonauts, Having passed Milestone-3 this week (and yes, it was painful), let's evaluate where we are with cinder Yoga features: - https://blueprints.launchpad.net/cinder/yoga Note: You must apply for a Feature Freeze Exception (FFE) by 17:00 UTC on Tuesday 1 March. Features granted an FFE must be in the gate by 20:00 UTC on Monday 7 March. Being granted an FFE is not a guarantee that your feature will be included in Yoga. FFE Details: ------------------ ibm-svf-portset - https://blueprints.launchpad.net/cinder/+spec/ibm-svf-portset - https://review.opendev.org/c/openstack/cinder/+/817351 - no +2s because third-party CI isn't passing - let's face it, no one is going to review this with failing CI even if it gets an FFE - must apply for an FFE The Third-Party CI for this review is IBM Storage CI. As the storage was done last week the CI failed. But today Zuul and IBM Storage CI both passed successfully. The portset has been tested throughly and reviewed by several reviewers in the last 2 months. All the comments are addressed and tested. The review has received a +2 from Rajat and +1 from Eric and Brian. The review is ready to be merged. Thanks and Regards, Harsh Ailani -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Mon Feb 28 17:13:12 2022 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Mon, 28 Feb 2022 12:13:12 -0500 Subject: [cinder] Yoga FEATURE FREEZE in effect In-Reply-To: References: Message-ID: <7bc49e88-77b1-fb2e-ff0e-21a0857c2637@gmail.com> On 2/28/22 12:02 PM, Harsha Ailani wrote: [snip] > FFE Details: > ------------------ > ibm-svf-portset > - https://blueprints.launchpad.net/cinder/+spec/ibm-svf-portset > > - https://review.opendev.org/c/openstack/cinder/+/817351 > > - no +2s because third-party CI isn't passing > - let's face it, no one is going to review this with failing CI even if > it gets an FFE > - must apply for an FFE > > > The Third-Party CI for this review is IBM Storage CI. As the storage was > done last week the CI failed. But today Zuul and IBM Storage CI both > passed successfully. > The portset has been tested throughly and reviewed by several reviewers > in the last 2 months. All the comments are addressed and tested. > The review has received a +2 from Rajat and +1 from Eric and Brian. > > The review is ready to be merged. Since the main holdups on this patch was the third-party CI, and that has been addressed, you can have an FFE. Features granted an FFE must be in the gate by 20:00 UTC on Monday 7 March. > > > Thanks and Regards, > Harsh Ailani From johnsomor at gmail.com Mon Feb 28 18:09:00 2022 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 28 Feb 2022 10:09:00 -0800 Subject: [nova][octavia][masakari][designate][oslo][requirements] oslo.context>=4.0.0 seems to need updated tests In-Reply-To: <20220228165609.zzz7ur2mktfrqmue@mthode.org> References: <20220228165609.zzz7ur2mktfrqmue@mthode.org> Message-ID: This is a legit API change in oslo.context (Thus the major version bump). It's been a long time coming too. I will get started on the required code changes to Designate. Maybe Octavia as well if someone else doesn't get to it before I do. Michael On Mon, Feb 28, 2022 at 9:04 AM Matthew Thode wrote: > > The update to see what's breaking is here > https://review.opendev.org/829599 > > Feel free to make that patch depend on your fix to test (with rechecks) > > -- > Matthew Thode From mrunge at matthias-runge.de Mon Feb 28 18:37:20 2022 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 28 Feb 2022 19:37:20 +0100 Subject: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi In-Reply-To: References: Message-ID: <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de> On 2/28/22 17:58, Molka Gharbaoui wrote: > Hi all, > > I installed devstack and ceilometer by adding the following lines in the > local.conf file: > > enable_plugin ceilometer https://opendev.org/openstack/ceilometer.git > CEILOMETER_BACKEND=gnocchi > > Devstack (yoga) works correctly (I am able to create images, instances, > etc.). The problem is that I cannot visualize the metrics. Using > "gnocchi metric list" and "gnocchi resource list" commands the result is > empty. > > When I use the "--debug" option, no errors are plotted but the body > response is empty. > > "ceilometer-upgrade" gives the following error: DEBUG > ceilometer.cmd.storage Upgrade Gnocchi resource types upgrade > /opt/stack/ceilometer/ceilometer/cmd/storage.py:42 > > "ceilometer-polling" prints "The resource could not be found". > > I have a running instance. > > Could you help me in retrieving the metrics from openstack? That means, that ceilometer apparently either doesn't get any updates from the underlying services OR it doesn't send the metrics over to gnocchi. You should check the ceilometer logs for errors. Also gnocchi logs could reveal issues. Matthias From smooney at redhat.com Mon Feb 28 18:37:55 2022 From: smooney at redhat.com (Sean Mooney) Date: Mon, 28 Feb 2022 18:37:55 +0000 Subject: [nova][octavia][masakari][designate][oslo][requirements] oslo.context>=4.0.0 seems to need updated tests In-Reply-To: References: <20220228165609.zzz7ur2mktfrqmue@mthode.org> Message-ID: On Mon, 2022-02-28 at 10:09 -0800, Michael Johnson wrote: > This is a legit API change in oslo.context (Thus the major version > bump). It's been a long time coming too. we are currently pass m3 in the rc period. i dont know if we can do a breaking change like this in yoga at this point depending on how invaise it is. we might need to hold this until after RC1 is out ideally this type of change would happen very erarly in the cycle before the ptg or m1 not at the very end on the nova side there is only one failing unit test https://6b96a36d22f450141095-9e4eb9f05513870f0e5456f29474f6b2.ssl.cf5.rackcdn.com/829599/1/check/cross-nova-py38/60113ea/testr_results.html but i need to also run the func tests to see if there is other impact tempest-full-py3 passed so nova iteslf is likely fine. ill try running it locally and see if that is the only impact or not. > > I will get started on the required code changes to Designate. Maybe > Octavia as well if someone else doesn't get to it before I do. > > Michael > > On Mon, Feb 28, 2022 at 9:04 AM Matthew Thode wrote: > > > > The update to see what's breaking is here > > https://review.opendev.org/829599 > > > > Feel free to make that patch depend on your fix to test (with rechecks) > > > > -- > > Matthew Thode > From smooney at redhat.com Mon Feb 28 18:43:19 2022 From: smooney at redhat.com (Sean Mooney) Date: Mon, 28 Feb 2022 18:43:19 +0000 Subject: [nova][octavia][masakari][designate][oslo][requirements] oslo.context>=4.0.0 seems to need updated tests In-Reply-To: References: <20220228165609.zzz7ur2mktfrqmue@mthode.org> Message-ID: <60238d97d4f9d44413441ec75e0b893e47bb9f6f.camel@redhat.com> On Mon, 2022-02-28 at 18:37 +0000, Sean Mooney wrote: > On Mon, 2022-02-28 at 10:09 -0800, Michael Johnson wrote: > > This is a legit API change in oslo.context (Thus the major version > > bump). It's been a long time coming too. > we are currently pass m3 in the rc period. > i dont know if we can do a breaking change like this in yoga at this point depending on how invaise it is. > we might need to hold this until after RC1 is out ideally this type of change would happen very erarly in the cycle before the ptg or m1 > not at the very end on the nova side there is only one failing unit test > https://6b96a36d22f450141095-9e4eb9f05513870f0e5456f29474f6b2.ssl.cf5.rackcdn.com/829599/1/check/cross-nova-py38/60113ea/testr_results.html > but i need to also run the func tests to see if there is other impact > tempest-full-py3 passed so nova iteslf is likely fine. > > ill try running it locally and see if that is the only impact or not. gmann beat me too it. https://review.opendev.org/c/openstack/nova/+/831244 so ya it is apprently just the one unit test so i dont think this should be an issue for nova > > > > > I will get started on the required code changes to Designate. Maybe > > Octavia as well if someone else doesn't get to it before I do. > > > > Michael > > > > On Mon, Feb 28, 2022 at 9:04 AM Matthew Thode wrote: > > > > > > The update to see what's breaking is here > > > https://review.opendev.org/829599 > > > > > > Feel free to make that patch depend on your fix to test (with rechecks) > > > > > > -- > > > Matthew Thode > > > From haleyb.dev at gmail.com Mon Feb 28 22:09:44 2022 From: haleyb.dev at gmail.com (Brian Haley) Date: Mon, 28 Feb 2022 17:09:44 -0500 Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas Bolivar for ovn-octavia-provider core reviewer In-Reply-To: References: Message-ID: <96c49d33-fc30-2380-fe82-8247fffc264f@gmail.com> +1 from me, Luis has been great at finding and fixing issues in this repo for a while. -Brian On 2/28/22 09:38, Lajos Katona wrote: > Hi > > I would like to propose?Luis Tomas Bolivar (ltomasbo) as a core reviewer > to the ovn-octavia-provider project. > Luis is very active in the project (see [1] and [2]) and has experience > with Kuryr side also which uses ovn-octavia-provider. > > As ovn-octavia-provider is a link between Neutron and Octavia I ask both > Neutron and Octavia cores to vote by answering to this thread, to have a > final decision. > Thanks for your consideration > > [1]: > https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master > > [2]: > https://www.stackalytics.io/report/contribution?module=neutron-group&project_type=openstack&days=60 > > > Cheers > Lajos From mkopec at redhat.com Mon Feb 28 23:00:44 2022 From: mkopec at redhat.com (Martin Kopec) Date: Tue, 1 Mar 2022 00:00:44 +0100 Subject: [qa][devstack] Proposing Dan Smith to devstack core In-Reply-To: References: <17ee122855b.ca10488e79864.8737427503451386666@ghanshyammann.com> Message-ID: Dan has been added to the devstack-core group, sorry, I forgot to send this email sooner. Dan, welcome to the team! On Thu, 10 Feb 2022 at 08:01, Rados?aw Piliszek wrote: > +1 > > On Thu, Feb 10, 2022, 01:58 Ghanshyam Mann > wrote: > >> ---- On Wed, 09 Feb 2022 17:46:31 -0600 Martin Kopec >> 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 >> > >> > >> >> -- Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurentfdumont at gmail.com Mon Feb 28 23:25:28 2022 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Mon, 28 Feb 2022 18:25:28 -0500 Subject: [horizon][customization] In-Reply-To: <3aa4a3df-fab3-ccc0-5bc3-821cdb80ce67@ovhcloud.com> References: <3aa4a3df-fab3-ccc0-5bc3-821cdb80ce67@ovhcloud.com> Message-ID: Salut! A 500 from Horizon is a bit strange. What do the Horizon logs say? If you remove your customization and restart Horizon, does it recover? On Mon, Feb 28, 2022 at 11:17 AM Mathilde Hermet < mathilde.hermet at ovhcloud.com> wrote: > Hello Openstack team, > > > I'm currently working on customizing the Horizon (xena) dashboard to use > the OVHcloud assets: logo.svg and logo-splash.svg. > > I've been following this documentation > https://docs.openstack.org/horizon/latest/configuration/themes.html > > I added the ovhcloud theme in > horizon/openstack_dashboard/local/local_settings.py in AVAILABLE_THEMES, > > I created the subdir ovhcloud in horizon/openstack_dashboard/themes and > I created a ovhcloud/img with logo.svg and logo-splash.svg in it. > > I put a _variables.scss and a _styles.scss in /themes/ovhcloud/ > > Then I executed python manage.py collectstatic > > It put all the files in horizon-sources/horizon.../static/themes/ovhcloud > > > But then when trying to connect with the session cookie > theme="ovhcloud", I have a 500 error. > > i don't think it comes from images because i've been puting it in > /horizon-souurces/horizon.../static/dashbaord.img and they were > displayed correctly. > > > Do you have any idea about the misconfiguration I've done ? > > > Best regards, > > > Mathilde Hermet > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurentfdumont at gmail.com Mon Feb 28 23:26:45 2022 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Mon, 28 Feb 2022 18:26:45 -0500 Subject: Fluentd error with Kolla ansible deployment In-Reply-To: References: Message-ID: Can you pull from that registry manually? If that doesn't work, Kolla won't work either. On Mon, Feb 28, 2022 at 6:47 AM A Monster wrote: > I'm getting the following error while trying to deploy openstack using > kolla-ansible. > I've set up a local docker registry and enabled insecure registries in > daemon.json file and I even tried to pull fluentd docker image but I still > get the following error > > TASK [common : Ensure fluentd image is present for label check] > fatal: [localhost]: FAILED! => {"changed": true, "msg": "'Traceback (most > recent call last):\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, > in _raise_for_status\\n response.raise_for_status()\\n File > \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in > raise_for_status\\n raise HTTPError(http_error_msg, > response=self)\\nrequests.exceptions.HTTPError: 500 Server Error: Internal > Server Error for url: > http+docker://localhost/v1.41/images/create?tag=xena&fromImage=quay.io%2Fkolla%2Fcentos-source-fluentd\\n\\nDuring > handling of the above exception, another exception occurred:\\n\\nTraceback > (most recent call last):\\n File > \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 1241, in main\\n File > \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 1116, in ensure_image\\n File > \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 692, in pull_image\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, > in pull\\n self._raise_for_status(response)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, > in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n > File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, > in create_api_error_from_http_exception\\n raise cls(e, > response=response, explanation=explanation)\\ndocker.errors.APIError: 500 > Server Error for > http+docker://localhost/v1.41/images/create?tag=xena&fromImage=quay.io%2Fkolla%2Fcentos-source-fluentd: > Internal Server Error (\"unauthorized: access to the requested resource is > not authorized\")\\n'"} > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkajinam at redhat.com Mon Feb 28 23:27:56 2022 From: tkajinam at redhat.com (Takashi Kajinami) Date: Tue, 1 Mar 2022 08:27:56 +0900 Subject: [nova][octavia][masakari][designate][oslo][requirements] oslo.context>=4.0.0 seems to need updated tests In-Reply-To: <60238d97d4f9d44413441ec75e0b893e47bb9f6f.camel@redhat.com> References: <20220228165609.zzz7ur2mktfrqmue@mthode.org> <60238d97d4f9d44413441ec75e0b893e47bb9f6f.camel@redhat.com> Message-ID: I hope the issue with Octavia was resolved by https://review.opendev.org/c/openstack/octavia/+/801860 . (Thank you Michael for merging this !) AFAIK Mistral is still dependent on the old arguments and we need https://review.opendev.org/c/openstack/mistral/+/801853 to fix it. It'd be nice if somebody from Mistral team can merge this (and the series of clean up patches) On Tue, Mar 1, 2022 at 3:47 AM Sean Mooney wrote: > On Mon, 2022-02-28 at 18:37 +0000, Sean Mooney wrote: > > On Mon, 2022-02-28 at 10:09 -0800, Michael Johnson wrote: > > > This is a legit API change in oslo.context (Thus the major version > > > bump). It's been a long time coming too. > > we are currently pass m3 in the rc period. > > i dont know if we can do a breaking change like this in yoga at this > point depending on how invaise it is. > > we might need to hold this until after RC1 is out ideally this type of > change would happen very erarly in the cycle before the ptg or m1 > > not at the very end on the nova side there is only one failing unit test > > > https://6b96a36d22f450141095-9e4eb9f05513870f0e5456f29474f6b2.ssl.cf5.rackcdn.com/829599/1/check/cross-nova-py38/60113ea/testr_results.html > > but i need to also run the func tests to see if there is other impact > > tempest-full-py3 passed so nova iteslf is likely fine. > > > > ill try running it locally and see if that is the only impact or not. > > gmann beat me too it. > https://review.opendev.org/c/openstack/nova/+/831244 > so ya it is apprently just the one unit test so i dont think this should > be an issue for nova > > > > > > > > > I will get started on the required code changes to Designate. Maybe > > > Octavia as well if someone else doesn't get to it before I do. > > > > > > Michael > > > > > > On Mon, Feb 28, 2022 at 9:04 AM Matthew Thode > wrote: > > > > > > > > The update to see what's breaking is here > > > > https://review.opendev.org/829599 > > > > > > > > Feel free to make that patch depend on your fix to test (with > rechecks) > > > > > > > > -- > > > > Matthew Thode > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: