From mdulko at redhat.com Wed Dec 1 08:55:52 2021 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Wed, 01 Dec 2021 09:55:52 +0100 Subject: [kuryr] Propose to EOL stable branches (Stein, Rocky and Queens) for all the kuryr scope In-Reply-To: References:

Message-ID: <3c2cbd0af92ff7dffb3fae4ce6c30015abd94b6b.camel@redhat.com> Yes, let's remove them. It has little sense to keep these versions and we're actually actively working to keep the compatibility with older OpenStack versions anyway. On Fri, 2021-11-26 at 23:50 +0100, Maysa De Macedo Souza wrote: > Hello again, > > We also have Pike as a stable branch[0], so that is the older one, > which would also be EOL. > > [0] > https://review.opendev.org/q/(project:%255Eopenstack/kuryr.*)AND((branch:stable/queens)OR(branch:stable/rocky)OR(branch:stable/stein)OR(branch:stable/pike)) > > Cheers, > Maysa. > > On Fri, Nov 26, 2021 at 11:42 PM Maysa De Macedo Souza > wrote: > > Hello, > > > > We have plenty of stable branches in Kuryr repositories still open > > with the oldest being stable/queens. > > We haven't seen many backports[0] proposed to Stein, Rocky and > > Queens, so I would like to propose retiring these branches. > > > > Let me know if anybody is interested in keeping any of those > > branches. > > > > [0] > > https://review.opendev.org/q/(project:%255Eopenstack/kuryr.*)AND((branch:stable/queens)OR(branch:stable/rocky)OR(branch:stable/stein)) > > > > Thank you, > > Maysa Macedo. From Iain.Stott at thehutgroup.com Wed Dec 1 11:17:03 2021 From: Iain.Stott at thehutgroup.com (Iain Stott) Date: Wed, 1 Dec 2021 11:17:03 +0000 Subject: [ceilometer][octavia][Victoria] No metrics from octavia loadbalancer Message-ID: Has anyone had any progress on this? We are currently in the same situation, we can see if loadblancers exists, but unable to see a way to configure the polling agent to poll endpoints like v2/lbaas/loadbalancers/[ID]/stats Cheers, Iain > OK. I have some progress. I created meters.d and pollster.d (in pollsters.d I?ve created octavia.yaml with sample type gauge and unit load balancer) and now I can see some measures, but only if load balancer exists or not. > Is there any way to force dynamic pollster to ask for url v2/lbaas/loadbalancers/[ID]/stats? > Best regards > Adam Iain Stott OpenStack Engineer The Hut Group Tel: Email: Iain.Stott at thehutgroup.com For the purposes of this email, the "company" means The Hut Group Limited, a company registered in England and Wales (company number 6539496) whose registered office is at Fifth Floor, Voyager House, Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its respective subsidiaries. Confidentiality Notice This e-mail is confidential and intended for the use of the named recipient only. If you are not the intended recipient please notify us by telephone immediately on +44(0)1606 811888 or return it to us by e-mail. Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of the company. Encryptions and Viruses Please note that this e-mail and any attachments have not been encrypted. They may therefore be liable to be compromised. Please also note that it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail. Monitoring Activity and use of the company's systems is monitored to secure its effective use and operation and for other lawful business purposes. Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes. hgvyjuv -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Wed Dec 1 13:08:59 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 1 Dec 2021 08:08:59 -0500 Subject: [cinder] reminder: yoga R-17 midcycle today at 1400 utc Message-ID: he Cinder Yoga R-17 virtual midcycle will be held: DATE: Today, Wednesday 1 December 2021 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. The midcycle etherpad is here: https://etherpad.opendev.org/p/cinder-yoga-midcycles cheers, brian From geguileo at redhat.com Wed Dec 1 13:58:46 2021 From: geguileo at redhat.com (Gorka Eguileor) Date: Wed, 1 Dec 2021 14:58:46 +0100 Subject: [cinder] : SAN migration In-Reply-To: References: Message-ID: <20211201135846.7vdnzse6vrejstql@localhost> On 03/11, Gauurav Sabharwal1 wrote: > > > Hi Experts , > > I need some expert advise of one of the scenario, I have multiple isolated > OpenStack cluster running with train & rocky edition. Each OpenStack > cluster environment have it's own isolated infrastructure of SAN ( CISCO > fabric ) & Storage ( HP, EMC & IBM). > > Now company planning to refresh their SAN infrastructure. By procuring new > Brocade SAN switches. But there are some migration relevant challenges we > have. > > As we understand under one cinder instance only one typer of FC zone > manager is supported . Currently customer configured & managing CISCO . > Is it possible to configure two different vendor FC Zone manager under > one cinder instance. Hi, No, it's not currently supported. As you mention, Cinder only supports a single zone manager for all the backends from a single cinder-volume parent process. But there are things that can be done, like running a second cinder-volume service with the new Zone Manager configuration. > Migration of SAN zoning is supposedly going to be happen offline way > from OpenStack point of view. We will be migrating all ports of each > existing cisco fabric to Brocade with zone configuration using brocade > CLI. Our main concern is that after migration How CINDER DB update > new zone info & path via Brocade SAN. When you say that the update is going to happen offline, does it mean all instances will be shutdowwn and have the cinder volumes detached from the VMs? If cinder volumes are detached from instances then everything will be fine. If volumes are still attached (even if VM is shelved) then it's a different story, though it should still be doable with the right procedure. Though I definitely don't feel comfortable providing the procedure since I have never done it and would require appropriate on-site testing. Cheers, Gorka. > > > Regards > Gauurav Sabharwal > IBM India Pvt. Ltd. > IBM towers > Ground floor, Block -A , Plot number 26, > Sector 62, Noida > Gautam budhnagar UP-201307. > Email:gauurav.sabharwal at in.ibm.com > Mobile No.: +91-9910159277 From amy at demarco.com Wed Dec 1 14:52:34 2021 From: amy at demarco.com (Amy Marrich) Date: Wed, 1 Dec 2021 08:52:34 -0600 Subject: [RDO][Meeting] December Meeting Hiatus (12/22 and 12/29) Message-ID: In today's RDO meeting we decided to cancel the meetings which would have been held on 12/22 and 12/29. We will still be holding meetings the other weeks in December in the #RDO channel on OFTC and hope to see you there. Thanks, Amy (spotz) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Wed Dec 1 14:53:16 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 1 Dec 2021 15:53:16 +0100 Subject: [ceilometer][octavia][Victoria] No metrics from octavia loadbalancer In-Reply-To: References: Message-ID: <4acead5e-a812-f7ed-412b-4874af0a4186@debian.org> On 12/1/21 12:17 PM, Iain Stott wrote: > Has anyone had any progress on this? We are currently in the same situation, we can see if loadblancers exists, but unable to see a way to configure the polling agent to poll endpoints like > > v2/lbaas/loadbalancers/[ID]/stats > > > Cheers, > Iain Hi, We do have loadbalancer stats in our public cloud (ie: on the Infomaniak public cloud) going from Ceilometer to Gnocchi storage. Customers are even able to see how many requests are made to the LBs. Our dynamic pollster: # cat /etc/ceilometer/pollsters.d/ik_loadbalancer.yaml --- - name: "ik_loadbalancer" sample_type: "gauge" unit: "loadbalancer" endpoint_type: "load-balancer" url_path: "/loadbalance/v2.0/lbaas/loadbalancers" value_attribute: "provisioning_status" response_entries_key: "loadbalancers" project_id_attribute: "project_id" value_mapping: ACTIVE: "1" ERROR: "0" metadata_fields: - "name" - "description" - "vip_address" I hope this helps, Cheers, Thomas Goirand (zigo) From zbitter at redhat.com Wed Dec 1 15:13:02 2021 From: zbitter at redhat.com (Zane Bitter) Date: Wed, 1 Dec 2021 10:13:02 -0500 Subject: python_requires >= 3.8 during Yoga In-Reply-To: <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com> References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com> Message-ID: On 26/11/21 10:29, Ghanshyam Mann wrote: > ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur wrote ---- > > > > > > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley wrote: > > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote: > > [...] > > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9. > > [...] > > > > Is this still true for CentOS Stream 9? The TC decision was to > > support that instead of CentOS Stream 8 in Yoga. > > > > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?). > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing > > - https://review.opendev.org/c/openstack/governance/+/815851/3..6/reference/runtimes/yoga.rst The guidelines the TC have set are not that something exists, but that it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide, and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable LTS releases. It's not clear to me why CentOS Stream is the only distro being treated differently. The only difference is there is no plan for a CentOS-branded release to define a point in time where Stream 9 becomes an LTS release. However, other parties do have such plans, but pointedly have not done so: RHEL9 is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to release a version based on Stream 9. Presumably RDO folks were consulted about this decision and were OK with the time frame. However, there are other users out there, and from a Metal? perspective this is a giant PITA, requiring us to move from a LTS distro to a beta one, that was dropped on us in the middle of a release cycle in flagrant violation of the TC's own guidelines that the stable distibutions must be chosen from among those available at the *beginning* of the release cycle (which CentOS Stream 9 was not). cheers, Zane. From abraden at verisign.com Wed Dec 1 16:01:28 2021 From: abraden at verisign.com (Braden, Albert) Date: Wed, 1 Dec 2021 16:01:28 +0000 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com> Message-ID: It appears that Centos is no longer a viable platform for production Openstack clusters. Of course we have to continue supporting those who are not yet able to move to another distro, but I think we should be clear-eyed about the fact that these are stopgap measures that only need to be implemented while people work on moving. Is anyone contemplating continuing to use Centos long-term? If so, I would be interested to hear your reasoning. -----Original Message----- From: Zane Bitter Sent: Wednesday, December 1, 2021 10:13 AM To: openstack-discuss at lists.openstack.org Subject: [EXTERNAL] Re: python_requires >= 3.8 during Yoga 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. On 26/11/21 10:29, Ghanshyam Mann wrote: > ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur wrote ---- > > > > > > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley wrote: > > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote: > > [...] > > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9. > > [...] > > > > Is this still true for CentOS Stream 9? The TC decision was to > > support that instead of CentOS Stream 8 in Yoga. > > > > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?). > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing > > - https://secure-web.cisco.com/1l5YAwIy_Kf9i8nZRj01Av73trnFQMqoxRgz_2n5WHVL6dc2mfcz-we8VRFvRToxc9yvnpH8QhTDlo2oJoiPHPBheqzFvIaRh40w5Ib3WUxBlvdAfSSNFxyJmXgPOxrq_AwWW27UvaTeFD_ycxhRyngSr_hY7Hji2WkdMMsFl19QfRhk20MI9giWNQk6uMAKlsLKRl4Zuod2cfgERb8Fwm5qwZkfA8NkOU9gZr4IF-nbSgg5aLbgowl4imparhsKS/https%3A%2F%2Freview.opendev.org%2Fc%2Fopenstack%2Fgovernance%2F%2B%2F815851%2F3..6%2Freference%2Fruntimes%2Fyoga.rst The guidelines the TC have set are not that something exists, but that it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide, and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable LTS releases. It's not clear to me why CentOS Stream is the only distro being treated differently. The only difference is there is no plan for a CentOS-branded release to define a point in time where Stream 9 becomes an LTS release. However, other parties do have such plans, but pointedly have not done so: RHEL9 is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to release a version based on Stream 9. Presumably RDO folks were consulted about this decision and were OK with the time frame. However, there are other users out there, and from a Metal? perspective this is a giant PITA, requiring us to move from a LTS distro to a beta one, that was dropped on us in the middle of a release cycle in flagrant violation of the TC's own guidelines that the stable distibutions must be chosen from among those available at the *beginning* of the release cycle (which CentOS Stream 9 was not). cheers, Zane. From gmann at ghanshyammann.com Wed Dec 1 16:06:02 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 01 Dec 2021 10:06:02 -0600 Subject: [all][qa][triplo] Help need to maintain OpenStack health dashboard Message-ID: <17d76bee71c.cfa2c4c1178950.6715520613968754830@ghanshyammann.com> Hello Everyone, In the QA meeting[1], we discussed the help needed to maintain the OpenStack health dashboard which is broken currently and the QA team does not have the JS developer and bandwidth to fix it. While discussing it meeting, we found that the TripleO team might be working on a similar dashboard for their CI results. If that is the case, can we collaborate on maintaining the existing dashboard? OpenStack health dashboard: https://opendev.org/openstack/openstack-health Repo: http://status.openstack.org/openstack-health/#/ [1] https://meetings.opendev.org/meetings/qa/2021/qa.2021-11-16-15.00.log.html#l-71 -gmann From aschultz at redhat.com Wed Dec 1 16:13:07 2021 From: aschultz at redhat.com (Alex Schultz) Date: Wed, 1 Dec 2021 09:13:07 -0700 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com> Message-ID: On Wed, Dec 1, 2021 at 9:04 AM Braden, Albert wrote: > > It appears that Centos is no longer a viable platform for production Openstack clusters. Of course we have to continue supporting those who are not yet able to move to another distro, but I think we should be clear-eyed about the fact that these are stopgap measures that only need to be implemented while people work on moving. > I'm not certain why this is how it's being interpreted. CentOS stream is perfectly viable but it is (as has always been) reliant on packaging. I believe Cloud SIG will still exist and RDO will be publishing packages. In fact CentOS stream is generally better than the previous release cadence that caused all sort of issues when point releases dropped with breaking changes. The difference in stream vs legacy method was the volume of changes over time. Stream you get smaller changes sooner (along with fixes) where as the legacy method you'd only really get updates at point release time and it was always terrible troubleshooting these failures. CentOS Stream 9 will have 3.9 as the default but we need to make sure that we can get it available to the various projects for testing. Right now Puppet OpenStack primarily relies on CentOS for testing (because Ubuntu jobs have been broken for a few years now with no one jumping in to fix). So bumping the minimum version without having a way to deploy for us would directly impact this project. IMHO the issue with this thread is timing on being able to bump a minimum python version requirement. I personally wouldn't want to bump to something that excludes 3.6 at this time without a really good reason. Are there features we require that will suddenly make developer/operator lives easier (e.g. switching to asyncio or something)? If not, what is the driving factor? I think pushing it off to Z would be best to allow for the initial standup required to have *all* the projects able to support the switch. > Is anyone contemplating continuing to use Centos long-term? If so, I would be interested to hear your reasoning. > > -----Original Message----- > From: Zane Bitter > Sent: Wednesday, December 1, 2021 10:13 AM > To: openstack-discuss at lists.openstack.org > Subject: [EXTERNAL] Re: python_requires >= 3.8 during Yoga > > 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. > > On 26/11/21 10:29, Ghanshyam Mann wrote: > > ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur wrote ---- > > > > > > > > > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley wrote: > > > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote: > > > [...] > > > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9. > > > [...] > > > > > > Is this still true for CentOS Stream 9? The TC decision was to > > > support that instead of CentOS Stream 8 in Yoga. > > > > > > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?). > > > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is > > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing > > > > - https://secure-web.cisco.com/1l5YAwIy_Kf9i8nZRj01Av73trnFQMqoxRgz_2n5WHVL6dc2mfcz-we8VRFvRToxc9yvnpH8QhTDlo2oJoiPHPBheqzFvIaRh40w5Ib3WUxBlvdAfSSNFxyJmXgPOxrq_AwWW27UvaTeFD_ycxhRyngSr_hY7Hji2WkdMMsFl19QfRhk20MI9giWNQk6uMAKlsLKRl4Zuod2cfgERb8Fwm5qwZkfA8NkOU9gZr4IF-nbSgg5aLbgowl4imparhsKS/https%3A%2F%2Freview.opendev.org%2Fc%2Fopenstack%2Fgovernance%2F%2B%2F815851%2F3..6%2Freference%2Fruntimes%2Fyoga.rst > > The guidelines the TC have set are not that something exists, but that > it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide, > and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable > LTS releases. It's not clear to me why CentOS Stream is the only distro > being treated differently. > > The only difference is there is no plan for a CentOS-branded release to > define a point in time where Stream 9 becomes an LTS release. However, > other parties do have such plans, but pointedly have not done so: RHEL9 > is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to > release a version based on Stream 9. > > Presumably RDO folks were consulted about this decision and were OK with > the time frame. However, there are other users out there, and from a > Metal? perspective this is a giant PITA, requiring us to move from a LTS > distro to a beta one, that was dropped on us in the middle of a release > cycle in flagrant violation of the TC's own guidelines that the stable > distibutions must be chosen from among those available at the > *beginning* of the release cycle (which CentOS Stream 9 was not). > > cheers, > Zane. > > From gmann at ghanshyammann.com Wed Dec 1 16:28:15 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 01 Dec 2021 10:28:15 -0600 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com> Message-ID: <17d76d33dc7.113f517f7180736.3792235396720560154@ghanshyammann.com> ---- On Wed, 01 Dec 2021 09:13:02 -0600 Zane Bitter wrote ---- > On 26/11/21 10:29, Ghanshyam Mann wrote: > > ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur wrote ---- > > > > > > > > > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley wrote: > > > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote: > > > [...] > > > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9. > > > [...] > > > > > > Is this still true for CentOS Stream 9? The TC decision was to > > > support that instead of CentOS Stream 8 in Yoga. > > > > > > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?). > > > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is > > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing > > > > - https://review.opendev.org/c/openstack/governance/+/815851/3..6/reference/runtimes/yoga.rst > > The guidelines the TC have set are not that something exists, but that > it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide, > and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable > LTS releases. It's not clear to me why CentOS Stream is the only distro > being treated differently. > > The only difference is there is no plan for a CentOS-branded release to > define a point in time where Stream 9 becomes an LTS release. However, > other parties do have such plans, but pointedly have not done so: RHEL9 > is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to > release a version based on Stream 9. > > Presumably RDO folks were consulted about this decision and were OK with > the time frame. However, there are other users out there, and from a > Metal? perspective this is a giant PITA, requiring us to move from a LTS > distro to a beta one, that was dropped on us in the middle of a release > cycle in flagrant violation of the TC's own guidelines that the stable > distibutions must be chosen from among those available at the > *beginning* of the release cycle (which CentOS Stream 9 was not). Those are good points. We were discussing with the RDO team on the start of Yoga cycle itself whether to move to CentOS Stream9 or not. Yes, there is a clear confusion on what is stable or not in CentOS Stream distro. Like other distro has, is there any document we as TC can refer to in the future on checking if the CentOS Stream *X* version is stable/LTS or not? I cannot find it for CentOS Stream 8 also, is that stable or LTS? If we have such official documentation or announcement in RDO community then we can avoid such situations in future where we get to know the distro version stability well before trying it in OpenStack testing? - https://centos.org/download/ -gmann > > cheers, > Zane. > > > From cboylan at sapwetik.org Wed Dec 1 16:31:43 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 01 Dec 2021 08:31:43 -0800 Subject: [all][qa][triplo] Help need to maintain OpenStack health dashboard In-Reply-To: <17d76bee71c.cfa2c4c1178950.6715520613968754830@ghanshyammann.com> References: <17d76bee71c.cfa2c4c1178950.6715520613968754830@ghanshyammann.com> Message-ID: <64474420-8cc9-4db8-aec7-5a788c5cf762@www.fastmail.com> On Wed, Dec 1, 2021, at 8:06 AM, Ghanshyam Mann wrote: > Hello Everyone, > > In the QA meeting[1], we discussed the help needed to maintain the > OpenStack health dashboard which is > broken currently and the QA team does not have the JS developer and > bandwidth to fix it. While discussing > it meeting, we found that the TripleO team might be working on a > similar dashboard for their CI results. If that > is the case, can we collaborate on maintaining the existing dashboard? Note, this will also require operational assistance to deploy the subunit2sql processing pipeline, the subunit2sql database backend, and the health api service. These services are planned to be turned off at the end of the current cycle per prior discussion with the TC. > > OpenStack health dashboard: https://opendev.org/openstack/openstack-health > Repo: http://status.openstack.org/openstack-health/#/ > > [1] > https://meetings.opendev.org/meetings/qa/2021/qa.2021-11-16-15.00.log.html#l-71 > > -gmann From aschultz at redhat.com Wed Dec 1 16:43:10 2021 From: aschultz at redhat.com (Alex Schultz) Date: Wed, 1 Dec 2021 09:43:10 -0700 Subject: python_requires >= 3.8 during Yoga In-Reply-To: <17d76d33dc7.113f517f7180736.3792235396720560154@ghanshyammann.com> References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com> <17d76d33dc7.113f517f7180736.3792235396720560154@ghanshyammann.com> Message-ID: On Wed, Dec 1, 2021 at 9:30 AM Ghanshyam Mann wrote: > > ---- On Wed, 01 Dec 2021 09:13:02 -0600 Zane Bitter wrote ---- > > On 26/11/21 10:29, Ghanshyam Mann wrote: > > > ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur wrote ---- > > > > > > > > > > > > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley wrote: > > > > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote: > > > > [...] > > > > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9. > > > > [...] > > > > > > > > Is this still true for CentOS Stream 9? The TC decision was to > > > > support that instead of CentOS Stream 8 in Yoga. > > > > > > > > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?). > > > > > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is > > > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing > > > > > > - https://review.opendev.org/c/openstack/governance/+/815851/3..6/reference/runtimes/yoga.rst > > > > The guidelines the TC have set are not that something exists, but that > > it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide, > > and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable > > LTS releases. It's not clear to me why CentOS Stream is the only distro > > being treated differently. > > > > The only difference is there is no plan for a CentOS-branded release to > > define a point in time where Stream 9 becomes an LTS release. However, > > other parties do have such plans, but pointedly have not done so: RHEL9 > > is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to > > release a version based on Stream 9. > > > > Presumably RDO folks were consulted about this decision and were OK with > > the time frame. However, there are other users out there, and from a > > Metal? perspective this is a giant PITA, requiring us to move from a LTS > > distro to a beta one, that was dropped on us in the middle of a release > > cycle in flagrant violation of the TC's own guidelines that the stable > > distibutions must be chosen from among those available at the > > *beginning* of the release cycle (which CentOS Stream 9 was not). > > Those are good points. We were discussing with the RDO team on the start > of Yoga cycle itself whether to move to CentOS Stream9 or not. > > Yes, there is a clear confusion on what is stable or not in CentOS Stream distro. > Like other distro has, is there any document we as TC can refer to in the future on > checking if the CentOS Stream *X* version is stable/LTS or not? I cannot find it > for CentOS Stream 8 also, is that stable or LTS? > I guess what's the definition of LTS? Support > 1 year? https://www.centos.org/cl-vs-cs/ CentOS Stream 8 is to be supported till 2024 and 9 is estimated until 2027. That seems pretty LTS to me. Additionally what is the definition of stable in this case? My understanding is that there still won't be major version bumps to core software similar to how CentOS used to operate. So it'd be a similar stability as previously existed in the non stream 7/8. What changes is that fixes will be available sooner, but it would have been the same that would have been released at a previous point release in the old method. > If we have such official documentation or announcement in RDO community > then we can avoid such situations in future where we get to know the distro > version stability well before trying it in OpenStack testing? > > - https://centos.org/download/ > > -gmann > > > > > cheers, > > Zane. > > > > > > > From gmann at ghanshyammann.com Wed Dec 1 16:43:46 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 01 Dec 2021 10:43:46 -0600 Subject: [all][qa][triplo] Help need to maintain OpenStack health dashboard In-Reply-To: <64474420-8cc9-4db8-aec7-5a788c5cf762@www.fastmail.com> References: <17d76bee71c.cfa2c4c1178950.6715520613968754830@ghanshyammann.com> <64474420-8cc9-4db8-aec7-5a788c5cf762@www.fastmail.com> Message-ID: <17d76e17422.103578670181902.6372441011959447878@ghanshyammann.com> ---- On Wed, 01 Dec 2021 10:31:43 -0600 Clark Boylan wrote ---- > On Wed, Dec 1, 2021, at 8:06 AM, Ghanshyam Mann wrote: > > Hello Everyone, > > > > In the QA meeting[1], we discussed the help needed to maintain the > > OpenStack health dashboard which is > > broken currently and the QA team does not have the JS developer and > > bandwidth to fix it. While discussing > > it meeting, we found that the TripleO team might be working on a > > similar dashboard for their CI results. If that > > is the case, can we collaborate on maintaining the existing dashboard? > > Note, this will also require operational assistance to deploy the subunit2sql processing pipeline, the subunit2sql database backend, and the health api service. These services are planned to be turned off at the end of the current cycle per prior discussion with the TC. +1, if the TripleO team working on a similar setup or so then we can reuse the existing dashboard or operational assistance. Otherwise, along with services shutdown what Clark mentioned above, the QA team will also start (have no choice) the repo retirement process also (which will impact anyone using it for downstream usage). -gmann > > > > > OpenStack health dashboard: https://opendev.org/openstack/openstack-health > > Repo: http://status.openstack.org/openstack-health/#/ > > > > [1] > > https://meetings.opendev.org/meetings/qa/2021/qa.2021-11-16-15.00.log.html#l-71 > > > > -gmann > > From rlandy at redhat.com Wed Dec 1 16:46:26 2021 From: rlandy at redhat.com (Ronelle Landy) Date: Wed, 1 Dec 2021 11:46:26 -0500 Subject: [all][qa][triplo] Help need to maintain OpenStack health dashboard In-Reply-To: <17d76bee71c.cfa2c4c1178950.6715520613968754830@ghanshyammann.com> References: <17d76bee71c.cfa2c4c1178950.6715520613968754830@ghanshyammann.com> Message-ID: On Wed, Dec 1, 2021 at 11:11 AM Ghanshyam Mann wrote: > Hello Everyone, > > In the QA meeting[1], we discussed the help needed to maintain the > OpenStack health dashboard which is > broken currently and the QA team does not have the JS developer and > bandwidth to fix it. While discussing > it meeting, we found that the TripleO team might be working on a similar > dashboard for their CI results. If that > is the case, can we collaborate on maintaining the existing dashboard? > We had a discussion with Martin Kopec about collaboration with QA in maintaining a TripleO focused dashboard. We have two dashboards in progress at the moment - one focused on jobs running in https://review.rdoproject.org/zuul/status - http://ci-health-rdo.tripleo.org/ and one where we are starting to track failures in select jobs running on https://zuul.openstack.org/ - http://ci-health.tripleo.org/ If you would like to collaborate on this work, please ping us on #oooq on (OFTC) join our community call on Tuesdays at 1:30pm UTC and we can discuss further. Thanks! > > OpenStack health dashboard: https://opendev.org/openstack/openstack-health > Repo: http://status.openstack.org/openstack-health/#/ > > [1] > https://meetings.opendev.org/meetings/qa/2021/qa.2021-11-16-15.00.log.html#l-71 > > -gmann > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Wed Dec 1 17:05:34 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 01 Dec 2021 17:05:34 +0000 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

Message-ID: On Wed, 2021-12-01 at 09:13 -0700, Alex Schultz wrote: > On Wed, Dec 1, 2021 at 9:04 AM Braden, Albert wrote: > > > > It appears that Centos is no longer a viable platform for production Openstack clusters. Of course we have to continue supporting those who are not yet able to move to another distro, but I think we should be clear-eyed about the fact that these are stopgap measures that only need to be implemented while people work on moving. > > > > I'm not certain why this is how it's being interpreted. CentOS stream > is perfectly viable but it is (as has always been) reliant on > packaging. I believe Cloud SIG will still exist and RDO will be > publishing packages. In fact CentOS stream is generally better than > the previous release cadence that caused all sort of issues when point > releases dropped with breaking changes. The difference in stream vs > legacy method was the volume of changes over time. Stream you get > smaller changes sooner (along with fixes) where as the legacy method > you'd only really get updates at point release time and it was always > terrible troubleshooting these failures. CentOS Stream 9 will have > 3.9 as the default but we need to make sure that we can get it > available to the various projects for testing. Right now Puppet > OpenStack primarily relies on CentOS for testing (because Ubuntu jobs > have been broken for a few years now with no one jumping in to fix). > So bumping the minimum version without having a way to deploy for us > would directly impact this project. at least internally earlier this year i reached out about rhel9/centos9 supprot specifcly related to py 3.9 support and eventlets. my understandwing was there was already some basic rhel9/centos9 ci happening the puppet moduels since eventlet supprot was tested using a puppet module job. > > IMHO the issue with this thread is timing on being able to bump a > minimum python version requirement. I personally wouldn't want to > bump to something that excludes 3.6 at this time without a really good > reason. > there is/was an expecation that rdo woudl backport support for cento 9 and py39 to stable wababy at some point since our downstream osp 17 product will be based on rhel 9 on stable/walaby. im not directly involved in that packaging effort but i had assumed perhaps incorreectly that redhat would do that work upstream in rdo? is this not the case? at least form a downstram perspective unless we cahnge direction and decided to build OSP 17 using ubi8 images instead fo ubi9 we will need to do all this packaging work anyway so im surprised there is this much push back to moving to centos 9 and py39. > Are there features we require that will suddenly make > developer/operator lives easier (e.g. switching to asyncio or > something)? > actuly they are a few nice libary enhanchments but that is not the main driving factor. many do not want to support deploying the openstack project on python version we do not test. so either we keep 3.6 support and test it in every porject or we drop it and test with 3.8 and 3.9. > If not, what is the driving factor? > i have been pushing for 3.9 testing to become required for all project because centos/rhel 9 will only ship 3.9+ and it will be what our downstream product will be based on and i belive 3.9 is already used on debian 11 and 3.10 i belive is slated for ubuntu 22.04 which will be the next ubuntu lts and will supprot/ship openstack yoga. so haveing at least 3.9 support in yoga will be imporatn for multiple distros and to help use test that i and proably others suggested raising the minium python version to 3.8 so that we only have to test with 2 version in the gate instead of 3.(3.6 3.8 and 3.9) continuting to support py36 aslo puts a burden on developers not just on our ci infrastucre as it will becomre harder to test wtih going froward as it stops being shipped in distros and as it exits security support the end of life for python 3.6 is planned for this month https://www.python.org/dev/peps/pep-0494/#lifespan speficically (23 Dec 2021) based on https://endoflife.date/python i dont think we shoudl be releasing yoga on an end of life python version. if we raise the minium to 3.8 that will be supported until at least 14 Oct 2024 which is after the stabel branch will be retired. not support python 3.9 and 3.10 for yoga will make packaging openstack very hard for many ditros but since we cant realticaly test 4 verions properly we have to increase the minium verions at some point. > I think pushing it > off to Z would be best to allow for the initial standup required to > have *all* the projects able to support the switch. all project where ment to start adding 3.9 support already it has been a non vovting test requiremtn for 2? cycles i belvie since we knew it was gong to be used in debian 11 and centos 9 for well over a year. i do agree that its unfortunet that centos 9 missed it release target and did not release before the start of the yoga cycle but a better way to adress the upgrade issue i think woudl be to support xena/wallaby on centos 8 and 9 and make yoga 9 only. if we need to supprot yoga on centos 8 because that is not possibel then we coudl keep 3.6 support for one addtional release i guss but that wont be something that we just get for free and it will require use to reinstaet all 3.6 based ci and acnockolage that by the time yoga is released 3.6 will be EOL. > > > Is anyone contemplating continuing to use Centos long-term? If so, I would be interested to hear your reasoning. > > > > -----Original Message----- > > From: Zane Bitter > > Sent: Wednesday, December 1, 2021 10:13 AM > > To: openstack-discuss at lists.openstack.org > > Subject: [EXTERNAL] Re: python_requires >= 3.8 during Yoga > > > > 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. > > > > On 26/11/21 10:29, Ghanshyam Mann wrote: > > > ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur wrote ---- > > > > > > > > > > > > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley wrote: > > > > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote: > > > > [...] > > > > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9. > > > > [...] > > > > > > > > Is this still true for CentOS Stream 9? The TC decision was to > > > > support that instead of CentOS Stream 8 in Yoga. > > > > > > > > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?). > > > > > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is > > > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing > > > > > > - https://secure-web.cisco.com/1l5YAwIy_Kf9i8nZRj01Av73trnFQMqoxRgz_2n5WHVL6dc2mfcz-we8VRFvRToxc9yvnpH8QhTDlo2oJoiPHPBheqzFvIaRh40w5Ib3WUxBlvdAfSSNFxyJmXgPOxrq_AwWW27UvaTeFD_ycxhRyngSr_hY7Hji2WkdMMsFl19QfRhk20MI9giWNQk6uMAKlsLKRl4Zuod2cfgERb8Fwm5qwZkfA8NkOU9gZr4IF-nbSgg5aLbgowl4imparhsKS/https%3A%2F%2Freview.opendev.org%2Fc%2Fopenstack%2Fgovernance%2F%2B%2F815851%2F3..6%2Freference%2Fruntimes%2Fyoga.rst > > > > The guidelines the TC have set are not that something exists, but that > > it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide, > > and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable > > LTS releases. It's not clear to me why CentOS Stream is the only distro > > being treated differently. > > > > The only difference is there is no plan for a CentOS-branded release to > > define a point in time where Stream 9 becomes an LTS release. However, > > other parties do have such plans, but pointedly have not done so: RHEL9 > > is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to > > release a version based on Stream 9. > > > > Presumably RDO folks were consulted about this decision and were OK with > > the time frame. However, there are other users out there, and from a > > Metal? perspective this is a giant PITA, requiring us to move from a LTS > > distro to a beta one, that was dropped on us in the middle of a release > > cycle in flagrant violation of the TC's own guidelines that the stable > > distibutions must be chosen from among those available at the > > *beginning* of the release cycle (which CentOS Stream 9 was not). > > > > cheers, > > Zane. > > > > > > From amoralej at redhat.com Wed Dec 1 17:30:01 2021 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Wed, 1 Dec 2021 18:30:01 +0100 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

Message-ID: On Wed, Dec 1, 2021 at 10:05 AM Sean Mooney wrote: > > On Wed, 2021-12-01 at 09:13 -0700, Alex Schultz wrote: > > On Wed, Dec 1, 2021 at 9:04 AM Braden, Albert wrote: > > > > > > It appears that Centos is no longer a viable platform for production Openstack clusters. Of course we have to continue supporting those who are not yet able to move to another distro, but I think we should be clear-eyed about the fact that these are stopgap measures that only need to be implemented while people work on moving. > > > > > > > I'm not certain why this is how it's being interpreted. CentOS stream > > is perfectly viable but it is (as has always been) reliant on > > packaging. I believe Cloud SIG will still exist and RDO will be > > publishing packages. In fact CentOS stream is generally better than > > the previous release cadence that caused all sort of issues when point > > releases dropped with breaking changes. The difference in stream vs > > legacy method was the volume of changes over time. Stream you get > > smaller changes sooner (along with fixes) where as the legacy method > > you'd only really get updates at point release time and it was always > > terrible troubleshooting these failures. CentOS Stream 9 will have > > 3.9 as the default but we need to make sure that we can get it > > available to the various projects for testing. Right now Puppet > > OpenStack primarily relies on CentOS for testing (because Ubuntu jobs > > have been broken for a few years now with no one jumping in to fix). > > So bumping the minimum version without having a way to deploy for us > > would directly impact this project. > > at least internally earlier this year i reached out about rhel9/centos9 supprot > specifcly related to py 3.9 support and eventlets. > my understandwing was there was already some basic rhel9/centos9 ci happening the puppet moduels > since eventlet supprot was tested using a puppet module job. > > > > > IMHO the issue with this thread is timing on being able to bump a > > minimum python version requirement. I personally wouldn't want to > > bump to something that excludes 3.6 at this time without a really good > > reason. > > > > there is/was an expecation that rdo woudl backport support for cento 9 and py39 to stable wababy at > some point since our downstream osp 17 product will be based on rhel 9 on stable/walaby. > > im not directly involved in that packaging effort but i had assumed perhaps incorreectly that redhat would > do that work upstream in rdo? is this not the case? > It is, however, because it's not done it is not OK to just do the switch. Really the issue is that you can't make a blanket switch until much of the bootstrapping work has been completed which is why doing the switch in Z makes more sense to allow for this. > at least form a downstram perspective unless we cahnge direction and decided to build OSP 17 using ubi8 images > instead fo ubi9 we will need to do all this packaging work anyway so im surprised there is this much push back > to moving to centos 9 and py39. > This is the same problem we had with the 7/8 switch where train was ultimately the thing where we had to backport support for py2.7/py3 problems. I would have really preferred to not do this again with 8/9 but here we are. IIRC, we managed to get Ussuri switched to centos8. Due to the delay in 9 availability we weren't able to get it ready in the Xena cycle. We do want to get it done in Yoga but because this thread is about making mandatory, we need to wait until the switch has been completed. > > Are there features we require that will suddenly make > > developer/operator lives easier (e.g. switching to asyncio or > > something)? > > > actuly they are a few nice libary enhanchments but that is not the main driving factor. > > many do not want to support deploying the openstack project on python version we do not test. > so either we keep 3.6 support and test it in every porject or we drop it and test with 3.8 and 3.9. > > > If not, what is the driving factor? > > > > i have been pushing for 3.9 testing to become required for all project because centos/rhel 9 will only ship 3.9+ > and it will be what our downstream product will be based on and i belive 3.9 is already used on debian 11 and 3.10 i belive > is slated for ubuntu 22.04 which will be the next ubuntu lts and will supprot/ship openstack yoga. > That's fine to push it as a goal, but I just think the goal needs to be delayed until Z. Is there anything that is broken in 3.9 > so haveing at least 3.9 support in yoga will be imporatn for multiple distros and to help use test that i and proably others > suggested raising the minium python version to 3.8 so that we only have to test with 2 version in the gate instead of 3.(3.6 3.8 and 3.9) > > continuting to support py36 aslo puts a burden on developers not just on our ci infrastucre as it will becomre harder to test wtih going froward > as it stops being shipped in distros and as it exits security support > the end of life for python 3.6 is planned for this month https://www.python.org/dev/peps/pep-0494/#lifespan > speficically (23 Dec 2021) based on https://endoflife.date/python > > i dont think we shoudl be releasing yoga on an end of life python version. > if we raise the minium to 3.8 that will be supported until at least 14 Oct 2024 > which is after the stabel branch will be retired. > So I guess the question is who do we use for language support EOLs? My understanding is that Ubuntu 18.04's default was 3.6 which has standard support until 2023[0] and CentOS Stream 8 will be supported until 2024[1]. Both of which should exceed Yoga's support[2]? With all these arguments about LTS distros, it seems that we should be using their support life cyles for the language versions and not python's[3]. [0] https://wiki.ubuntu.com/Releases [1] https://www.centos.org/cl-vs-cs/ [2] https://releases.openstack.org/ [3] https://devguide.python.org/#status-of-python-branches > not support python 3.9 and 3.10 for yoga will make packaging openstack very hard for many ditros but since we cant realticaly test 4 verions properly we > have to increase the minium verions at some point. > > I think pushing it > > off to Z would be best to allow for the initial standup required to > > have *all* the projects able to support the switch. > all project where ment to start adding 3.9 support already it has been a non vovting test requiremtn for 2? cycles i belvie > since we knew it was gong to be used in debian 11 and centos 9 for well over a year. > > i do agree that its unfortunet that centos 9 missed it release target and did not release before the start of the yoga cycle > but a better way to adress the upgrade issue i think woudl be to support xena/wallaby on centos 8 and 9 and make yoga 9 only. > if we need to supprot yoga on centos 8 because that is not possibel then we coudl keep 3.6 support for one addtional release i guss > but that wont be something that we just get for free and it will require use to reinstaet all 3.6 based ci and acnockolage that by the > time yoga is released 3.6 will be EOL. > > > > > > Is anyone contemplating continuing to use Centos long-term? If so, I would be interested to hear your reasoning. > > > > > > -----Original Message----- > > > From: Zane Bitter > > > Sent: Wednesday, December 1, 2021 10:13 AM > > > To: openstack-discuss at lists.openstack.org > > > Subject: [EXTERNAL] Re: python_requires >= 3.8 during Yoga > > > > > > 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. > > > > > > On 26/11/21 10:29, Ghanshyam Mann wrote: > > > > ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur wrote ---- > > > > > > > > > > > > > > > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley wrote: > > > > > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote: > > > > > [...] > > > > > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9. > > > > > [...] > > > > > > > > > > Is this still true for CentOS Stream 9? The TC decision was to > > > > > support that instead of CentOS Stream 8 in Yoga. > > > > > > > > > > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?). > > > > > > > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is > > > > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing > > > > > > > > - https://secure-web.cisco.com/1l5YAwIy_Kf9i8nZRj01Av73trnFQMqoxRgz_2n5WHVL6dc2mfcz-we8VRFvRToxc9yvnpH8QhTDlo2oJoiPHPBheqzFvIaRh40w5Ib3WUxBlvdAfSSNFxyJmXgPOxrq_AwWW27UvaTeFD_ycxhRyngSr_hY7Hji2WkdMMsFl19QfRhk20MI9giWNQk6uMAKlsLKRl4Zuod2cfgERb8Fwm5qwZkfA8NkOU9gZr4IF-nbSgg5aLbgowl4imparhsKS/https%3A%2F%2Freview.opendev.org%2Fc%2Fopenstack%2Fgovernance%2F%2B%2F815851%2F3..6%2Freference%2Fruntimes%2Fyoga.rst > > > > > > The guidelines the TC have set are not that something exists, but that > > > it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide, > > > and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable > > > LTS releases. It's not clear to me why CentOS Stream is the only distro > > > being treated differently. > > > > > > The only difference is there is no plan for a CentOS-branded release to > > > define a point in time where Stream 9 becomes an LTS release. However, > > > other parties do have such plans, but pointedly have not done so: RHEL9 > > > is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to > > > release a version based on Stream 9. > > > > > > Presumably RDO folks were consulted about this decision and were OK with > > > the time frame. However, there are other users out there, and from a > > > Metal? perspective this is a giant PITA, requiring us to move from a LTS > > > distro to a beta one, that was dropped on us in the middle of a release > > > cycle in flagrant violation of the TC's own guidelines that the stable > > > distibutions must be chosen from among those available at the > > > *beginning* of the release cycle (which CentOS Stream 9 was not). > > > > > > cheers, > > > Zane. > > > > > > > > > > > From cboylan at sapwetik.org Wed Dec 1 18:06:16 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 01 Dec 2021 10:06:16 -0800 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

Message-ID: <50abb4f5-af13-435c-87c9-1c14d74dcfb2@www.fastmail.com> On Wed, Dec 1, 2021, at 9:31 AM, Alex Schultz wrote: > On Wed, Dec 1, 2021 at 10:05 AM Sean Mooney wrote: > Apologies if my reduction of thread content was too aggressive. > >> so haveing at least 3.9 support in yoga will be imporatn for multiple distros and to help use test that i and proably others >> suggested raising the minium python version to 3.8 so that we only have to test with 2 version in the gate instead of 3.(3.6 3.8 and 3.9) >> >> continuting to support py36 aslo puts a burden on developers not just on our ci infrastucre as it will becomre harder to test wtih going froward >> as it stops being shipped in distros and as it exits security support >> the end of life for python 3.6 is planned for this month https://www.python.org/dev/peps/pep-0494/#lifespan >> speficically (23 Dec 2021) based on https://endoflife.date/python >> >> i dont think we shoudl be releasing yoga on an end of life python version. >> if we raise the minium to 3.8 that will be supported until at least 14 Oct 2024 >> which is after the stabel branch will be retired. >> > > So I guess the question is who do we use for language support EOLs? > My understanding is that Ubuntu 18.04's default was 3.6 which has > standard support until 2023[0] and CentOS Stream 8 will be supported > until 2024[1]. Both of which should exceed Yoga's support[2]? With > all these arguments about LTS distros, it seems that we should be > using their support life cyles for the language versions and not > python's[3]. > > [0] https://wiki.ubuntu.com/Releases > [1] https://www.centos.org/cl-vs-cs/ > [2] https://releases.openstack.org/ > [3] https://devguide.python.org/#status-of-python-branches > I'd like to make a proposal for moving forward. But first let's summarize some facts so that we can evaluate the proposal against the state of the world. * Python 3.6 reaches EOL soon. * CentOS 9 Stream is released and makes no mention of being in a beta status (https://www.centos.org/centos-stream/) * We have the ability to run tests on CentOS 9 Stream today * It is useful to users to ensure we have an OpenStack release tested against old distro release with old python and new distro release with new python. This enables them to update underlying distro releases independently from upgrading OpenStack. * The various distros are not in sync over which python versions they support. Given this state it seems reasonable that we continue to test Yoga against python3.6 and newer python. It would also probably be a good idea to explicitly update the PTI and distro support policies to indicate that when adding new distro releases we continue to support the old distro release's python for one cycle. The level of actual testing done on these platforms will depend on who steps up to maintain that testing, but at the very least we'll accept bug fixes for old python and not prevent installation via setup.cfg python_requires settings. Yes, this means another cycle of python3.6 support which isn't ideal given it's soon EOL, but the intent is to support distros who will continue to support the older python on their platform. If we want to be bold and try an experiment, we could also reduce testing of the python versions to oldest and newest supported python versions. For example python3.6 and python3.9 during Yoga. Don't worry about python3.7 and python3.8 as it is likely they will continue to function as long as 3.6 and 3.9 are happy. This would reduce the size of the testing matrix. We can always reevaluate if problems for 3.7 and 3.8 occur. Finally, I think it is important to note that OpenStack is using CentOS as a stand in for RHEL. This worked a lot better when CentOS was an actual copy of RHEL. What we've got today is CentOS stream and it makes no claims about being in beta until RHEL releases (that I can find anyway), and I don't think we should make those assertions ourselves. If there is interest in using a different stand in (Alma or Rocky?) then we should replace CentOS stream with one of those alternatives. Another option may be to assert that Stream only functions as a standin once RHEL has released their corresponding update, but it is my understanding that Stream and RHEL will always have some delta. Clark From abraden at verisign.com Wed Dec 1 18:06:47 2021 From: abraden at verisign.com (Braden, Albert) Date: Wed, 1 Dec 2021 18:06:47 +0000 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

Message-ID: Obviously Redhat will continue to support and use Openstack on Centos, and Redhat employees are a substantial part of the Openstack community. Without the contributions from Redhat employees, Openstack would struggle to survive. However, I don?t think that use by a single company is enough to justify the effort required to support a distro, even when that single company is a major contributor. I hope and believe that Redhat would continue their contributions to the Openstack community if we continued to support Openstack on RHEL and dropped support for Centos. I'm curious whether anyone who does not work for Redhat is planning to continue using Openstack on Centos long-term, and if so, I'd like to hear your reasoning. -----Original Message----- From: Alex Schultz Sent: Wednesday, December 1, 2021 11:13 AM To: Braden, Albert Cc: openstack-discuss at lists.openstack.org Subject: [EXTERNAL] Re: Re: python_requires >= 3.8 during Yoga 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. On Wed, Dec 1, 2021 at 9:04 AM Braden, Albert wrote: > > It appears that Centos is no longer a viable platform for production Openstack clusters. Of course we have to continue supporting those who are not yet able to move to another distro, but I think we should be clear-eyed about the fact that these are stopgap measures that only need to be implemented while people work on moving. > I'm not certain why this is how it's being interpreted. CentOS stream is perfectly viable but it is (as has always been) reliant on packaging. I believe Cloud SIG will still exist and RDO will be publishing packages. In fact CentOS stream is generally better than the previous release cadence that caused all sort of issues when point releases dropped with breaking changes. The difference in stream vs legacy method was the volume of changes over time. Stream you get smaller changes sooner (along with fixes) where as the legacy method you'd only really get updates at point release time and it was always terrible troubleshooting these failures. CentOS Stream 9 will have 3.9 as the default but we need to make sure that we can get it available to the various projects for testing. Right now Puppet OpenStack primarily relies on CentOS for testing (because Ubuntu jobs have been broken for a few years now with no one jumping in to fix). So bumping the minimum version without having a way to deploy for us would directly impact this project. IMHO the issue with this thread is timing on being able to bump a minimum python version requirement. I personally wouldn't want to bump to something that excludes 3.6 at this time without a really good reason. Are there features we require that will suddenly make developer/operator lives easier (e.g. switching to asyncio or something)? If not, what is the driving factor? I think pushing it off to Z would be best to allow for the initial standup required to have *all* the projects able to support the switch. > Is anyone contemplating continuing to use Centos long-term? If so, I would be interested to hear your reasoning. > > -----Original Message----- > From: Zane Bitter > Sent: Wednesday, December 1, 2021 10:13 AM > To: openstack-discuss at lists.openstack.org > Subject: [EXTERNAL] Re: python_requires >= 3.8 during Yoga > > 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. > > On 26/11/21 10:29, Ghanshyam Mann wrote: > > ---- On Fri, 26 Nov 2021 09:20:39 -0600 Dmitry Tantsur wrote ---- > > > > > > > > > On Fri, Nov 26, 2021 at 3:35 PM Jeremy Stanley wrote: > > > On 2021-11-26 14:29:53 +0100 (+0100), Dmitry Tantsur wrote: > > > [...] > > > > CentOS/RHEL ships 3.6 and a limited version of 3.8 and 3.9. > > > [...] > > > > > > Is this still true for CentOS Stream 9? The TC decision was to > > > support that instead of CentOS Stream 8 in Yoga. > > > > > > No. But Stream 9 is pretty much beta, so it's not a replacement for us (and we don't have nodes in nodepool with it even yet?). > > > > I think here is the confusion. In TC, after checking with centos team impression was CentOS stream 9 is released and that is > > what we should update In OpenStack testing. And then only we updated the centos stream 8 -> 9 and dropped py3.6 testing > > > > - https://secure-web.cisco.com/1l5YAwIy_Kf9i8nZRj01Av73trnFQMqoxRgz_2n5WHVL6dc2mfcz-we8VRFvRToxc9yvnpH8QhTDlo2oJoiPHPBheqzFvIaRh40w5Ib3WUxBlvdAfSSNFxyJmXgPOxrq_AwWW27UvaTeFD_ycxhRyngSr_hY7Hji2WkdMMsFl19QfRhk20MI9giWNQk6uMAKlsLKRl4Zuod2cfgERb8Fwm5qwZkfA8NkOU9gZr4IF-nbSgg5aLbgowl4imparhsKS/https%3A%2F%2Freview.opendev.org%2Fc%2Fopenstack%2Fgovernance%2F%2B%2F815851%2F3..6%2Freference%2Fruntimes%2Fyoga.rst > > The guidelines the TC have set are not that something exists, but that > it is a stable LTS release. Debian sid, Ubuntu 20.10, Fedora rawhide, > and OpenSUSE Tumbleweed all exist, but nobody mistakes them for stable > LTS releases. It's not clear to me why CentOS Stream is the only distro > being treated differently. > > The only difference is there is no plan for a CentOS-branded release to > define a point in time where Stream 9 becomes an LTS release. However, > other parties do have such plans, but pointedly have not done so: RHEL9 > is in beta; Rocky Linux, Alma Linux, and Oracle Linux are all yet to > release a version based on Stream 9. > > Presumably RDO folks were consulted about this decision and were OK with > the time frame. However, there are other users out there, and from a > Metal? perspective this is a giant PITA, requiring us to move from a LTS > distro to a beta one, that was dropped on us in the middle of a release > cycle in flagrant violation of the TC's own guidelines that the stable > distibutions must be chosen from among those available at the > *beginning* of the release cycle (which CentOS Stream 9 was not). > > cheers, > Zane. > > From abraden at verisign.com Wed Dec 1 18:15:41 2021 From: abraden at verisign.com (Braden, Albert) Date: Wed, 1 Dec 2021 18:15:41 +0000 Subject: [ops] [kolla] RabbitMQ High Availability Message-ID: <7d613f7f8f71497db28b5e27ddcb8224@verisign.com> I read this with great interest because we are seeing this issue. Questions: 1. We are running kola-ansible Train, and our RMQ version is 3.7.23. Should we be upgrading our Train clusters to use 3.8.x? 2. Document [2] recommends policy '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'. I don't see this in our ansible playbooks, nor in any of the config files in the RMQ container. What would this look like in Ansible, and what should the resulting container config look like? 3. It appears that we are not setting "amqp_durable_queues = True". What does this setting look like in Ansible, and what file does it go into? Does anyone have a sample set of RMQ config files that they can share? It looks like my Outlook has ruined the link; reposting: [2] https://wiki.openstack.org/wiki/Large_Scale_Configuration_Rabbit -----Original Message----- From: Arnaud Morin Sent: Monday, November 29, 2021 2:04 PM To: Bogdan Dobrelya Cc: DHilsbos at performair.com; openstack-discuss at lists.openstack.org Subject: [EXTERNAL] Re: [ops]RabbitMQ High Availability 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. Hi, After a talk on this ml (which starts at [1]), we endup building a documentation with Large Scale group. The doc is accessible at [2]. Hope this will help. [1] http://secure-web.cisco.com/1gFccuTyEVGnFd9aBOZ-RTPG0hbVIPGAbuLBNnoXP4onSZGFG1umIn0EtkEpBJWko4mi6yOUZ8Vsm-5sDGmIVl8rC2sOHv3Z2I1s9lFIkVFyn16CXJgcJbQQ7SBU8wEz5I_TysLtIY6YrmiC3PkKdG4oVCZk6n_KqYPYjmYUmDn9BD6JcXKUbFujVfugbjewZDY4HDCBnTe43tPSqkIZRVarApPiwsFtHu5PQ5riSoSgTpupqZHZdPnnGz7sbVGzx/http%3A%2F%2Flists.openstack.org%2Fpipermail%2Fopenstack-discuss%2F2020-August%2F016362.html [2] https://secure-web.cisco.com/1OtQ3pcnPPBNwevAFxS8yOS2xFlkHo0tY4SmkFE-wpAU_YPYS-BxRX5omcjCPZ3cMOxefnaO0vc3qlVm_SvI3DpkhejUkQUrrRbBJ72ki_ly13bYzC_QKd0-VERmSnlx8SFUB_DWewMYIZ7JfaURBYN9QvJgwD0b0aG-hYgvxcN1ZCt7qHTDqneGTtpx-5gRUMvld2dFz5uXsPj7QzohumP5bAoTblw7xLJy3zXhlfvrg6aHhQIR4xw9_y8E5Lt7d/https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit On 24.11.21 - 11:31, Bogdan Dobrelya wrote: > On 11/24/21 12:34 AM, DHilsbos at performair.com wrote: > > All; > > > > In the time I've been part of this mailing list, the subject of RabbitMQ high availability has come up several times, and each time specific recommendations for both Rabbit and Open Stack are provided. I remember it being an A or B kind of recommendation (i.e. configure Rabbit like A1, and Open Stack like A2, OR configure Rabbit like B1, and Open Stack like B2). > > There is no special recommendations for rabbitmq setup for openstack, > but probably a few, like instead of putting it behind a haproxy, or the > like, list the rabbit cluster nodes in the oslo messaging config > settings directly. Also, it seems that durable queues makes a very > little sense for highly ephemeral RPC calls, just by design. I would > also add that the raft quorum queues feature of rabbitmq >=3.18 does > neither fit well into the oslo messaging design for RPC calls. > > A discussable and highly opinionated thing is also configuring > ha/mirror queue policy params for queues used for RPC calls vs > broad-casted notifications. > > And my biased personal humble recommendation is: use the upstream OCF RA > [0][1], if configuring rabbitmq cluster by pacemaker. > > [0] https://secure-web.cisco.com/1N1wD9gW7NZho0LdTVNuiU2ZIB7NW-eJMfDgVzBH3D3E6URzGYPKa-uhcLHxy3tRvRXopjnLAd2CECD1urJyRpg8NBSxTOEUSPxOlS0cQyULtSQuDbVWr-W7Bl3ZRcdWPrF9EuX_b40IM7zTjqS40gImsEouTqtD1vlCuEoaFgpptDEuMuaNTqBJ0IAtiZHuWiW6E7ufTtgxmVbkGLjXCZw5ZNhibbu-kGVyA-7MQsxQ-RBgSq5peTcLBR2Vx-f9k/https%3A%2F%2Fwww.rabbitmq.com%2Fpacemaker.html%23auto-pacemaker > > [1] > https://secure-web.cisco.com/1iDK1NnL9JTkQqkpBda06xTQNrWY2W0pVOTDwUoadfQbSXn5r0g_GH8PB8wZC5-JmHW2-m1YWoj1Z86jFcmWT0m9W9Sax5fJE5G7MbvQN2JM0EbAVHJDCmiBkMZlrSLoTgmh30RGhvmF9ww7jAjVnas3_AYFmwc65P-YtpdcswFC8rYcg5HlE2d979gf2OQUeftP3lfClkVou7hnELIFanDq07MfOJc2exHIfBo2ZQyUXRqXWUqnTsj7df-jCySkz/https%3A%2F%2Fgithub.com%2FClusterLabs%2Fresource-agents%2Fblob%2Fmaster%2Fheartbeat%2Frabbitmq-server-ha > > > > > Unfortunately, I can't find the previous threads on this topic. > > > > Does anyone have this information, that they would care to share with me? > > > > Thank you, > > > > Dominic L. Hilsbos, MBA > > Vice President - Information Technology > > Perform Air International Inc. > > DHilsbos at PerformAir.com > > www.PerformAir.com > > > > > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > From fungi at yuggoth.org Wed Dec 1 18:24:31 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 1 Dec 2021 18:24:31 +0000 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References: <20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

Message-ID: <20211201182430.5eh3wc6ezk5ittnm@yuggoth.org> On 2021-12-01 10:31:58 -0700 (-0700), Alex Schultz wrote: [...] > So I guess the question is who do we use for language support EOLs? > My understanding is that Ubuntu 18.04's default was 3.6 which has > standard support until 2023[0] and CentOS Stream 8 will be supported > until 2024[1]. Both of which should exceed Yoga's support[2]? With > all these arguments about LTS distros, it seems that we should be > using their support life cyles for the language versions and not > python's[3]. [...] The answer is that it's not clear. We use the packaged Python 3 interpreter and standard library from specific LTS distros, but we consume additional Python 3 library dependencies from PyPI rather than from packages in those distros contemporary with the interpreters they've packaged. The result is that we're stuck relying on when those dependencies decide to drop support for what they consider to be "old" interpreter versions. At one time we tried to rely on distro packaged dependencies, but discovered that breaks down as soon as projects want to use libraries which aren't yet packaged in those distributions. It's sort of Catch-22 in that the distros look to us to determine when they should be adding or updating dependencies, so if we look to them for which dependencies/versions are available then we can quickly get deadlocked. -- 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 Dec 1 18:34:17 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 1 Dec 2021 18:34:17 +0000 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References: <20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

Message-ID: <20211201183416.bukigb2w4edsnftv@yuggoth.org> On 2021-12-01 18:06:47 +0000 (+0000), Braden, Albert wrote: [...] > I hope and believe that Redhat would continue their contributions > to the Openstack community if we continued to support Openstack on > RHEL and dropped support for Centos. [...] Just to clear up some misconceptions, what we mean when we say "support" (from the OpenStack community perspective) is that we test it upstream: https://governance.openstack.org/tc/resolutions/20170620-volunteer-support.html In that sense, OpenStack does not officially "support" RHEL because we lack the ability to test it due to licensing challenges. We've asked on multiple occasions, and been told that running RHEL in arbitrary public cloud environments driven by automation is not feasible to license (due to a combination of legalities and logistics), and is still outside the scope of the "free for developer use" RHEL license program available today. This is why we traditionally tested on CentOS as a stand-in for RHEL, rather than using actual RHEL. Informally we "support" RHEL in the sense that we'd like users to be able to run our software on the platform, but we rely on others to test that's possible since we can't guarantee it ourselves. -- 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 zbitter at redhat.com Wed Dec 1 19:21:01 2021 From: zbitter at redhat.com (Zane Bitter) Date: Wed, 1 Dec 2021 14:21:01 -0500 Subject: python_requires >= 3.8 during Yoga In-Reply-To: <17d76d33dc7.113f517f7180736.3792235396720560154@ghanshyammann.com> References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

<50abb4f5-af13-435c-87c9-1c14d74dcfb2@www.fastmail.com> Message-ID: ))) On Wed, Dec 1, 2021 at 11:09 AM Clark Boylan wrote: > > On Wed, Dec 1, 2021, at 9:31 AM, Alex Schultz wrote: > > On Wed, Dec 1, 2021 at 10:05 AM Sean Mooney wrote: > > > > Apologies if my reduction of thread content was too aggressive. > > > > >> so haveing at least 3.9 support in yoga will be imporatn for multiple distros and to help use test that i and proably others > >> suggested raising the minium python version to 3.8 so that we only have to test with 2 version in the gate instead of 3.(3.6 3.8 and 3.9) > >> > >> continuting to support py36 aslo puts a burden on developers not just on our ci infrastucre as it will becomre harder to test wtih going froward > >> as it stops being shipped in distros and as it exits security support > >> the end of life for python 3.6 is planned for this month https://www.python.org/dev/peps/pep-0494/#lifespan > >> speficically (23 Dec 2021) based on https://endoflife.date/python > >> > >> i dont think we shoudl be releasing yoga on an end of life python version. > >> if we raise the minium to 3.8 that will be supported until at least 14 Oct 2024 > >> which is after the stabel branch will be retired. > >> > > > > So I guess the question is who do we use for language support EOLs? > > My understanding is that Ubuntu 18.04's default was 3.6 which has > > standard support until 2023[0] and CentOS Stream 8 will be supported > > until 2024[1]. Both of which should exceed Yoga's support[2]? With > > all these arguments about LTS distros, it seems that we should be > > using their support life cyles for the language versions and not > > python's[3]. > > > > [0] https://wiki.ubuntu.com/Releases > > [1] https://www.centos.org/cl-vs-cs/ > > [2] https://releases.openstack.org/ > > [3] https://devguide.python.org/#status-of-python-branches > > For this reply, "LTS Distro" means support/updates > 13 months This means regular Ubuntu and Fedora releases don't qualify. Ubuntu LTS, CentOS Stream * and Debian LTS would qualify. Can we all agree on this definition? https://ubuntu.com/about/release-cycle https://www.centos.org/cl-vs-cs/#end-of-life https://wiki.debian.org/LTS > > I'd like to make a proposal for moving forward. But first let's summarize some facts so that we can evaluate the proposal against the state of the world. > > * Python 3.6 reaches EOL soon. > * CentOS 9 Stream is released and makes no mention of being in a beta status (https://www.centos.org/centos-stream/) > * We have the ability to run tests on CentOS 9 Stream today Yes some OpenStack projects can run on CentOS 9 Stream today but not all can (Puppet OpenStack being one). The assumption that pip install is sufficient for *all* projects is not correct. At least some testing needs to be able to be run on all projects before projects can officially declare <= 3.6 dead. This hopefully will be completed during Yoga but it takes time. > * It is useful to users to ensure we have an OpenStack release tested against old distro release with old python and new distro release with new python. This enables them to update underlying distro releases independently from upgrading OpenStack. > * The various distros are not in sync over which python versions they support. > > Given this state it seems reasonable that we continue to test Yoga against python3.6 and newer python. It would also probably be a good idea to explicitly update the PTI and distro support policies to indicate that when adding new distro releases we continue to support the old distro release's python for one cycle. The level of actual testing done on these platforms will depend on who steps up to maintain that testing, but at the very least we'll accept bug fixes for old python and not prevent installation via setup.cfg python_requires settings. > > Yes, this means another cycle of python3.6 support which isn't ideal given it's soon EOL, but the intent is to support distros who will continue to support the older python on their platform. IMHO "another cycle" means continued support in Z not Yoga. I think the ask here was just delay the minimum version until Z so this would be the last cycle with 3.6 support. Jeremy said in a subsequent message that the interpreter comes from an LTS distro which IMHO means the EOL is the distro's EOL not Python's. Now this brings up issues if we can't get 3.6 fixes for specific versions of our dependencies that come in via pypi, but do we have data how often this is actually a problem? Isn't that already a problem for stable branches? Or are we worrying about something that doesn't happen? We need to all agree on where EOL dates come from for dependencies and expectations around them. LTS Distros are being referenced in this thread but people keep going back to EOL dates that are not aligned with these distros. For the full OpenStack project ecosystem, testing is occurring on Ubuntu, CentOS, and a bit of Debian. IMHO when a release (e.g. Yoga) is released, we should use what is available at the start of cycle and using the EOL dates of the tested distros in determining decisions around version support. If we use this for Yoga, realistically CentOS Stream 8 and Ubuntu 20.04 could be used which would leave us with 3.6/3.8. It seems Debian was the only one with 3.7 (https://wiki.debian.org/Python). Since CentOS Stream 9 was released during the Yoga cycle, we couldn't pick it up as a version until Z but we could then make the 3.8 cutoff then. If Ubuntu releases a new version (the website says they might) during Yoga with 3.9 then we could talk about raising it further in Z. This would allow for lower bounds to be pushed, but requires that one of our qualifying LTS distros in check/gate were already available at the start of a cycle. What I would like is that people stop pointing to Python's EOL date which is newer but does not actually align with the assumption of an LTS distro. It would only make sense to use that date if we were basing our testing on non-LTS distros which may be able to follow their EOL dates more closely. I keep hammering on the LTS distro because OpenStack is heavily reliant on packages and hardware supported by distros that it is very closely tied to what is available. If OpenStack had no tie to distro hardware support, venvs and pip installing all the things might be sufficient but there are many dependencies which end up not being satisfied this way. You can get away with it up to a point, but it's an important integration point. > > If we want to be bold and try an experiment, we could also reduce testing of the python versions to oldest and newest supported python versions. For example python3.6 and python3.9 during Yoga. Don't worry about python3.7 and python3.8 as it is likely they will continue to function as long as 3.6 and 3.9 are happy. This would reduce the size of the testing matrix. We can always reevaluate if problems for 3.7 and 3.8 occur. > The issue here I think is trying to align on a default LTS distro python. CS8,18.04 is 3.6, Debian Buster is 3.7, 20.04 is 3.8 and CS9 will be 3.9. Personally I think 3.6/3.9 is sufficient because for the projects I contribute to this covers my cases. But this would exclude the 3.8 on 20.04. Would this be a problem for Ubuntu's UCA? > Finally, I think it is important to note that OpenStack is using CentOS as a stand in for RHEL. This worked a lot better when CentOS was an actual copy of RHEL. What we've got today is CentOS stream and it makes no claims about being in beta until RHEL releases (that I can find anyway), and I don't think we should make those assertions ourselves. If there is interest in using a different stand in (Alma or Rocky?) then we should replace CentOS stream with one of those alternatives. Another option may be to assert that Stream only functions as a standin once RHEL has released their corresponding update, but it is my understanding that Stream and RHEL will always have some delta. There has always been a delta. The change now is the delta has been reversed such that we'll get fixes for things before RHEL but this is likely better for OpenStack's use cases where the previous meant long delays to get necessary fixes. I'm uncertain why the RHEL release schedule is being factored in to determine some indication of stability when testing is occurring (https://www.centos.org/cl-vs-cs/#testing). Thanks, -Alex > > Clark > From arnaud.morin at gmail.com Wed Dec 1 20:02:02 2021 From: arnaud.morin at gmail.com (Arnaud) Date: Wed, 01 Dec 2021 21:02:02 +0100 Subject: [ops] [kolla] RabbitMQ High Availability In-Reply-To: <7d613f7f8f71497db28b5e27ddcb8224@verisign.com> References: <7d613f7f8f71497db28b5e27ddcb8224@verisign.com> Message-ID: <8C25B4D7-5D74-4E15-84C8-DBDA9E304855@gmail.com> Hi, I definitely recommend upgrading to 3.8. Also enable the durable queues. This helped us a lot in managing our clusters. We also applied the policy, which was originally taken from openstack ansible [1]. We also collect unroutable messages and send alerts based in that (but we had no issue recently thanks to all above). Finally we ping all our clients using oslo_ping_endpoint [2] every five minutes so we know when an agent is disconnected. Dunno about kolla, sorry. [1] https://github.com/openstack/openstack-ansible-rabbitmq_server/blob/fc27e735a68b64cb3c67dd8abeaf324803a9845b/defaults/main.yml#L172 [2] https://opendev.org/openstack/oslo.messaging/commit/82492442f3387a0e4f19623ccfda64f8b84d59c3 Le 1 d?cembre 2021 19:15:41 GMT+01:00, "Braden, Albert" a ?crit?: >I read this with great interest because we are seeing this issue. Questions: > >1. We are running kola-ansible Train, and our RMQ version is 3.7.23. Should we be upgrading our Train clusters to use 3.8.x? >2. Document [2] recommends policy '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'. I don't see this in our ansible playbooks, nor in any of the config files in the RMQ container. What would this look like in Ansible, and what should the resulting container config look like? >3. It appears that we are not setting "amqp_durable_queues = True". What does this setting look like in Ansible, and what file does it go into? > >Does anyone have a sample set of RMQ config files that they can share? > >It looks like my Outlook has ruined the link; reposting: >[2] https://wiki.openstack.org/wiki/Large_Scale_Configuration_Rabbit > >-----Original Message----- >From: Arnaud Morin >Sent: Monday, November 29, 2021 2:04 PM >To: Bogdan Dobrelya >Cc: DHilsbos at performair.com; openstack-discuss at lists.openstack.org >Subject: [EXTERNAL] Re: [ops]RabbitMQ High Availability > >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. > >Hi, > >After a talk on this ml (which starts at [1]), we endup building a >documentation with Large Scale group. >The doc is accessible at [2]. > >Hope this will help. > >[1] http://secure-web.cisco.com/1gFccuTyEVGnFd9aBOZ-RTPG0hbVIPGAbuLBNnoXP4onSZGFG1umIn0EtkEpBJWko4mi6yOUZ8Vsm-5sDGmIVl8rC2sOHv3Z2I1s9lFIkVFyn16CXJgcJbQQ7SBU8wEz5I_TysLtIY6YrmiC3PkKdG4oVCZk6n_KqYPYjmYUmDn9BD6JcXKUbFujVfugbjewZDY4HDCBnTe43tPSqkIZRVarApPiwsFtHu5PQ5riSoSgTpupqZHZdPnnGz7sbVGzx/http%3A%2F%2Flists.openstack.org%2Fpipermail%2Fopenstack-discuss%2F2020-August%2F016362.html >[2] https://secure-web.cisco.com/1OtQ3pcnPPBNwevAFxS8yOS2xFlkHo0tY4SmkFE-wpAU_YPYS-BxRX5omcjCPZ3cMOxefnaO0vc3qlVm_SvI3DpkhejUkQUrrRbBJ72ki_ly13bYzC_QKd0-VERmSnlx8SFUB_DWewMYIZ7JfaURBYN9QvJgwD0b0aG-hYgvxcN1ZCt7qHTDqneGTtpx-5gRUMvld2dFz5uXsPj7QzohumP5bAoTblw7xLJy3zXhlfvrg6aHhQIR4xw9_y8E5Lt7d/https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit > >On 24.11.21 - 11:31, Bogdan Dobrelya wrote: >> On 11/24/21 12:34 AM, DHilsbos at performair.com wrote: >> > All; >> > >> > In the time I've been part of this mailing list, the subject of RabbitMQ high availability has come up several times, and each time specific recommendations for both Rabbit and Open Stack are provided. I remember it being an A or B kind of recommendation (i.e. configure Rabbit like A1, and Open Stack like A2, OR configure Rabbit like B1, and Open Stack like B2). >> >> There is no special recommendations for rabbitmq setup for openstack, >> but probably a few, like instead of putting it behind a haproxy, or the >> like, list the rabbit cluster nodes in the oslo messaging config >> settings directly. Also, it seems that durable queues makes a very >> little sense for highly ephemeral RPC calls, just by design. I would >> also add that the raft quorum queues feature of rabbitmq >=3.18 does >> neither fit well into the oslo messaging design for RPC calls. >> >> A discussable and highly opinionated thing is also configuring >> ha/mirror queue policy params for queues used for RPC calls vs >> broad-casted notifications. >> >> And my biased personal humble recommendation is: use the upstream OCF RA >> [0][1], if configuring rabbitmq cluster by pacemaker. >> >> [0] https://secure-web.cisco.com/1N1wD9gW7NZho0LdTVNuiU2ZIB7NW-eJMfDgVzBH3D3E6URzGYPKa-uhcLHxy3tRvRXopjnLAd2CECD1urJyRpg8NBSxTOEUSPxOlS0cQyULtSQuDbVWr-W7Bl3ZRcdWPrF9EuX_b40IM7zTjqS40gImsEouTqtD1vlCuEoaFgpptDEuMuaNTqBJ0IAtiZHuWiW6E7ufTtgxmVbkGLjXCZw5ZNhibbu-kGVyA-7MQsxQ-RBgSq5peTcLBR2Vx-f9k/https%3A%2F%2Fwww.rabbitmq.com%2Fpacemaker.html%23auto-pacemaker >> >> [1] >> https://secure-web.cisco.com/1iDK1NnL9JTkQqkpBda06xTQNrWY2W0pVOTDwUoadfQbSXn5r0g_GH8PB8wZC5-JmHW2-m1YWoj1Z86jFcmWT0m9W9Sax5fJE5G7MbvQN2JM0EbAVHJDCmiBkMZlrSLoTgmh30RGhvmF9ww7jAjVnas3_AYFmwc65P-YtpdcswFC8rYcg5HlE2d979gf2OQUeftP3lfClkVou7hnELIFanDq07MfOJc2exHIfBo2ZQyUXRqXWUqnTsj7df-jCySkz/https%3A%2F%2Fgithub.com%2FClusterLabs%2Fresource-agents%2Fblob%2Fmaster%2Fheartbeat%2Frabbitmq-server-ha >> >> > >> > Unfortunately, I can't find the previous threads on this topic. >> > >> > Does anyone have this information, that they would care to share with me? >> > >> > Thank you, >> > >> > Dominic L. Hilsbos, MBA >> > Vice President - Information Technology >> > Perform Air International Inc. >> > DHilsbos at PerformAir.com >> > www.PerformAir.com >> > >> > >> > >> >> >> -- >> Best regards, >> Bogdan Dobrelya, >> Irc #bogdando >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Dec 1 20:16:27 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 1 Dec 2021 20:16:27 +0000 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References: <20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

<50abb4f5-af13-435c-87c9-1c14d74dcfb2@www.fastmail.com> Message-ID: <20211201201627.gkp4ik6g2qm5rdtf@yuggoth.org> On 2021-12-01 12:46:08 -0700 (-0700), Alex Schultz wrote: [...] > For this reply, "LTS Distro" means support/updates > 13 months This > means regular Ubuntu and Fedora releases don't qualify. Ubuntu LTS, > CentOS Stream * and Debian LTS would qualify. Can we all agree on > this definition? > > https://ubuntu.com/about/release-cycle > https://www.centos.org/cl-vs-cs/#end-of-life > https://wiki.debian.org/LTS [...] Technically, Debian on its own would meet this definition, as releases come every ~2.5 years and are generally supported for ~6 months after the next release, making it roughly 3 years of normal support. "LTS" in Debian is something which extends beyond the normal security support for the distribution, but is irrelevant here given the already long support timeframe for Debian releases. > Jeremy said in a subsequent message that the interpreter comes > from an LTS distro which IMHO means the EOL is the distro's EOL > not Python's. Now this brings up issues if we can't get 3.6 fixes > for specific versions of our dependencies that come in via pypi, > but do we have data how often this is actually a problem? You can get some idea by counting the number of times "python_version" appears in global-requirements.txt or upper-constraints.txt in openstack/requirements by the end of a release cycle. > Isn't that already a problem for stable branches? Not really, since we freeze openstack/requirements when branching, in a crude attempt to mimic testing with versions contemporary with what distros are probably packaging alongside that OpenStack release. > Or are we worrying about something that doesn't happen? We need > to all agree on where EOL dates come from for dependencies and > expectations around them. It's definitely a thing which happens. We're running Python 3.6 jobs on OpenStack project master branches now while pinning to older versions of more than a dozen dependencies, and when mainline 3.6 EOL comes that will almost certainly rise sharply as our dependencies start to aggressively drop support for it. Having this happen during a cycle definitely leads to a wider disparity in versions of dependencies used for various jobs, compared to having it happen after we freeze requirements for the release. > LTS Distros are being referenced in this thread but people keep going > back to EOL dates that are not aligned with these distros. For the > full OpenStack project ecosystem, testing is occurring on Ubuntu, > CentOS, and a bit of Debian. IMHO when a release (e.g. Yoga) is > released, we should use what is available at the start of cycle and > using the EOL dates of the tested distros in determining decisions > around version support. If we use this for Yoga, realistically CentOS > Stream 8 and Ubuntu 20.04 could be used which would leave us with > 3.6/3.8. It seems Debian was the only one with 3.7 > (https://wiki.debian.org/Python). Since CentOS Stream 9 was released > during the Yoga cycle, we couldn't pick it up as a version until Z but > we could then make the 3.8 cutoff then. If Ubuntu releases a new > version (the website says they might) during Yoga with 3.9 then we > could talk about raising it further in Z. This would allow for lower > bounds to be pushed, but requires that one of our qualifying LTS > distros in check/gate were already available at the start of a cycle. Actually, Debian's last stable release (11 a.k.a. bullseye) was available approximately 2 months before we started on OpenStack Yoga and uses Python 3.9 as its default python3, so testing 3.6 and 3.9 would be the preferred lower and upper bounds there. > What I would like is that people stop pointing to Python's EOL date > which is newer but does not actually align with the assumption of an > LTS distro. It would only make sense to use that date if we were > basing our testing on non-LTS distros which may be able to follow > their EOL dates more closely. [...] The underlying reason it keeps coming up is that, during development, we don't attempt to match the versions of dependencies we test with to the versions those distributions are packaging alongside the Python 3 interpreter. As a result, when our dependencies begin dropping upstream support for Python releases is what impacts us, at least under our current testing model. -- 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 tonyliu0592 at hotmail.com Wed Dec 1 20:26:12 2021 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Wed, 1 Dec 2021 20:26:12 +0000 Subject: [kolla] Plan to deprecate binary and unify on single distrubition In-Reply-To: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com> References: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com> Message-ID: For OpenStack, I've been using centos-binary containers on CentOS. It's been working very well. I don't have much concern on supporting single-distro based container on different distro hosts. That's actually one of the beauties of container, which self-contains all packages and dependencies. We used to have a product based on single-distro container and support different distro hosts. Just need to be careful when container needs any resource from the host, like kernel, mounted host filesystem, networking, privilege, etc. Regarding to source container, what's the purpose of it? Is it allow user to get the package based on some specific source that is not provided by any existing package repo? In that case, I'd assume user should always build their own source container. Then what's the purpose of providing pre-build source container? Also, are those non-core containers, like MariaDB, HAProxy, RabbitMQ, etc. all built from source code? Thanks! Tony ________________________________________ From: Micha? Nasiadka Sent: November 18, 2021 04:33 AM To: openstack-discuss Subject: [kolla] Plan to deprecate binary and unify on single distrubition Hello Koalas, On the PTG we have discussed two topics: 1) Deprecate and drop binary type of Kolla images 2) Use a common base (single Linux distribution) for Kolla images This is a call for feedback - for people that have not been attending the PTG. What this essentially mean for consumers: 1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z cycle those will be dropped. 2) We are not going to support CentOS Stream 9 (cs9) as a base operating system, and the source type build will rely on CentOS Stream 8 in Z release. 3) Beginning from A release Kolla will build only Debian source images - but Kolla-Ansible will still support deployment of those images on CentOS/Ubuntu/Debian Host operating systems (and Rocky Linux to be added in Yoga to that mix). Justification: The Kolla project team is limited in numbers, therefore supporting current broad mix of operating systems (especially with CentOS Stream 9 ,,on the way??) is a significant maintenance burden. By dropping binary type of images - users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images jobs as voting). In Xena we?ve already changed the default image type Kolla-Ansible uses to source. We also feel that using a unified base OS for Kolla container images is a way to remove some of the maintenance burden (including CI cycles and Request for feedback: If any of those changes is a no go from your perspective - we?d like to hear your opinions. Best regards, Michal Nasiadka From pierre at stackhpc.com Wed Dec 1 21:22:52 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Wed, 1 Dec 2021 22:22:52 +0100 Subject: [ops] [kolla] RabbitMQ High Availability In-Reply-To: <7d613f7f8f71497db28b5e27ddcb8224@verisign.com> References: <7d613f7f8f71497db28b5e27ddcb8224@verisign.com> Message-ID: Hello Albert, The amqp_durable_queues configuration option comes from oslo.messaging, which is a library used by many OpenStack projects. You can set this option in the [oslo_messaging_rabbit] section of each of these OpenStack projects (check their configuration reference for more details). As for how to configure it with Kolla Ansible: you can either set it directly for each service (e.g. in /etc/kolla/config/nova.conf to configure it for Nova) or for all projects at once using /etc/kolla/config/global.conf. Projects that don't support this option should just ignore it. Read this section of the documentation for more details: https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration.html#openstack-service-configuration-in-kolla Best wishes, Pierre Riteau On Wed, 1 Dec 2021 at 19:20, Braden, Albert wrote: > > I read this with great interest because we are seeing this issue. Questions: > > 1. We are running kola-ansible Train, and our RMQ version is 3.7.23. Should we be upgrading our Train clusters to use 3.8.x? > 2. Document [2] recommends policy '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'. I don't see this in our ansible playbooks, nor in any of the config files in the RMQ container. What would this look like in Ansible, and what should the resulting container config look like? > 3. It appears that we are not setting "amqp_durable_queues = True". What does this setting look like in Ansible, and what file does it go into? > > Does anyone have a sample set of RMQ config files that they can share? > > It looks like my Outlook has ruined the link; reposting: > [2] https://wiki.openstack.org/wiki/Large_Scale_Configuration_Rabbit > > -----Original Message----- > From: Arnaud Morin > Sent: Monday, November 29, 2021 2:04 PM > To: Bogdan Dobrelya > Cc: DHilsbos at performair.com; openstack-discuss at lists.openstack.org > Subject: [EXTERNAL] Re: [ops]RabbitMQ High Availability > > 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. > > Hi, > > After a talk on this ml (which starts at [1]), we endup building a > documentation with Large Scale group. > The doc is accessible at [2]. > > Hope this will help. > > [1] http://secure-web.cisco.com/1gFccuTyEVGnFd9aBOZ-RTPG0hbVIPGAbuLBNnoXP4onSZGFG1umIn0EtkEpBJWko4mi6yOUZ8Vsm-5sDGmIVl8rC2sOHv3Z2I1s9lFIkVFyn16CXJgcJbQQ7SBU8wEz5I_TysLtIY6YrmiC3PkKdG4oVCZk6n_KqYPYjmYUmDn9BD6JcXKUbFujVfugbjewZDY4HDCBnTe43tPSqkIZRVarApPiwsFtHu5PQ5riSoSgTpupqZHZdPnnGz7sbVGzx/http%3A%2F%2Flists.openstack.org%2Fpipermail%2Fopenstack-discuss%2F2020-August%2F016362.html > [2] https://secure-web.cisco.com/1OtQ3pcnPPBNwevAFxS8yOS2xFlkHo0tY4SmkFE-wpAU_YPYS-BxRX5omcjCPZ3cMOxefnaO0vc3qlVm_SvI3DpkhejUkQUrrRbBJ72ki_ly13bYzC_QKd0-VERmSnlx8SFUB_DWewMYIZ7JfaURBYN9QvJgwD0b0aG-hYgvxcN1ZCt7qHTDqneGTtpx-5gRUMvld2dFz5uXsPj7QzohumP5bAoTblw7xLJy3zXhlfvrg6aHhQIR4xw9_y8E5Lt7d/https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit > > On 24.11.21 - 11:31, Bogdan Dobrelya wrote: > > On 11/24/21 12:34 AM, DHilsbos at performair.com wrote: > > > All; > > > > > > In the time I've been part of this mailing list, the subject of RabbitMQ high availability has come up several times, and each time specific recommendations for both Rabbit and Open Stack are provided. I remember it being an A or B kind of recommendation (i.e. configure Rabbit like A1, and Open Stack like A2, OR configure Rabbit like B1, and Open Stack like B2). > > > > There is no special recommendations for rabbitmq setup for openstack, > > but probably a few, like instead of putting it behind a haproxy, or the > > like, list the rabbit cluster nodes in the oslo messaging config > > settings directly. Also, it seems that durable queues makes a very > > little sense for highly ephemeral RPC calls, just by design. I would > > also add that the raft quorum queues feature of rabbitmq >=3.18 does > > neither fit well into the oslo messaging design for RPC calls. > > > > A discussable and highly opinionated thing is also configuring > > ha/mirror queue policy params for queues used for RPC calls vs > > broad-casted notifications. > > > > And my biased personal humble recommendation is: use the upstream OCF RA > > [0][1], if configuring rabbitmq cluster by pacemaker. > > > > [0] https://secure-web.cisco.com/1N1wD9gW7NZho0LdTVNuiU2ZIB7NW-eJMfDgVzBH3D3E6URzGYPKa-uhcLHxy3tRvRXopjnLAd2CECD1urJyRpg8NBSxTOEUSPxOlS0cQyULtSQuDbVWr-W7Bl3ZRcdWPrF9EuX_b40IM7zTjqS40gImsEouTqtD1vlCuEoaFgpptDEuMuaNTqBJ0IAtiZHuWiW6E7ufTtgxmVbkGLjXCZw5ZNhibbu-kGVyA-7MQsxQ-RBgSq5peTcLBR2Vx-f9k/https%3A%2F%2Fwww.rabbitmq.com%2Fpacemaker.html%23auto-pacemaker > > > > [1] > > https://secure-web.cisco.com/1iDK1NnL9JTkQqkpBda06xTQNrWY2W0pVOTDwUoadfQbSXn5r0g_GH8PB8wZC5-JmHW2-m1YWoj1Z86jFcmWT0m9W9Sax5fJE5G7MbvQN2JM0EbAVHJDCmiBkMZlrSLoTgmh30RGhvmF9ww7jAjVnas3_AYFmwc65P-YtpdcswFC8rYcg5HlE2d979gf2OQUeftP3lfClkVou7hnELIFanDq07MfOJc2exHIfBo2ZQyUXRqXWUqnTsj7df-jCySkz/https%3A%2F%2Fgithub.com%2FClusterLabs%2Fresource-agents%2Fblob%2Fmaster%2Fheartbeat%2Frabbitmq-server-ha > > > > > > > > Unfortunately, I can't find the previous threads on this topic. > > > > > > Does anyone have this information, that they would care to share with me? > > > > > > Thank you, > > > > > > Dominic L. Hilsbos, MBA > > > Vice President - Information Technology > > > Perform Air International Inc. > > > DHilsbos at PerformAir.com > > > www.PerformAir.com > > > > > > > > > > > > > > > -- > > Best regards, > > Bogdan Dobrelya, > > Irc #bogdando > > > > > > > From adrian at fleio.com Wed Dec 1 21:30:48 2021 From: adrian at fleio.com (Adrian Andreias) Date: Wed, 1 Dec 2021 23:30:48 +0200 Subject: [kolla] Plan to deprecate binary and unify on single distrubition In-Reply-To: References: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com> Message-ID: The user doesn't have to build the images that are source based. Ready built source-based images are available: https://quay.io/search?q=kolla Binary-based Kolla docker images are installing (at image build time) OpenStack projects via system packages, while source based images are symply adding projects' Python source code. Just as you said, the user shouldn't care much about distro inside images. But makes things a lot easier for developers to maintain less images and without working around different versions and dependencies provided by the system packages of various distros. Regards, Adrian Andreias On Wed, Dec 1, 2021 at 10:31 PM Tony Liu wrote: > For OpenStack, I've been using centos-binary containers on CentOS. It's > been working very well. > > I don't have much concern on supporting single-distro based container on > different distro hosts. > That's actually one of the beauties of container, which self-contains all > packages and dependencies. > We used to have a product based on single-distro container and support > different distro hosts. > Just need to be careful when container needs any resource from the host, > like kernel, mounted > host filesystem, networking, privilege, etc. > > Regarding to source container, what's the purpose of it? Is it allow user > to get the package based > on some specific source that is not provided by any existing package repo? > In that case, I'd assume > user should always build their own source container. Then what's the > purpose of providing pre-build > source container? Also, are those non-core containers, like MariaDB, > HAProxy, RabbitMQ, etc. all > built from source code? > > > Thanks! > Tony > ________________________________________ > From: Micha? Nasiadka > Sent: November 18, 2021 04:33 AM > To: openstack-discuss > Subject: [kolla] Plan to deprecate binary and unify on single distrubition > > Hello Koalas, > > On the PTG we have discussed two topics: > > 1) Deprecate and drop binary type of Kolla images > 2) Use a common base (single Linux distribution) for Kolla images > > This is a call for feedback - for people that have not been attending the > PTG. > > What this essentially mean for consumers: > > 1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z > cycle those will be dropped. > 2) We are not going to support CentOS Stream 9 (cs9) as a base operating > system, and the source type build will rely on CentOS Stream 8 in Z release. > 3) Beginning from A release Kolla will build only Debian source images - > but Kolla-Ansible will still support deployment of those images on > CentOS/Ubuntu/Debian Host operating systems (and Rocky Linux to be added in > Yoga to that mix). > > Justification: > The Kolla project team is limited in numbers, therefore supporting current > broad mix of operating systems (especially with CentOS Stream 9 ,,on the > way??) is a significant maintenance burden. > By dropping binary type of images - users would be running more tested > images (since Kolla/Kolla-Ansible CI runs source images jobs as voting). > In Xena we?ve already changed the default image type Kolla-Ansible uses to > source. > We also feel that using a unified base OS for Kolla container images is a > way to remove some of the maintenance burden (including CI cycles and > > Request for feedback: > If any of those changes is a no go from your perspective - we?d like to > hear your opinions. > > Best regards, > Michal Nasiadka > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Wed Dec 1 21:30:44 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 01 Dec 2021 13:30:44 -0800 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

<50abb4f5-af13-435c-87c9-1c14d74dcfb2@www.fastmail.com> Message-ID: On Wed, Dec 1, 2021, at 11:46 AM, Alex Schultz wrote: > ))) > > On Wed, Dec 1, 2021 at 11:09 AM Clark Boylan wrote: >> >> On Wed, Dec 1, 2021, at 9:31 AM, Alex Schultz wrote: >> > On Wed, Dec 1, 2021 at 10:05 AM Sean Mooney wrote: >> > >> >> Apologies if my reduction of thread content was too aggressive. >> >> > >> >> so haveing at least 3.9 support in yoga will be imporatn for multiple distros and to help use test that i and proably others >> >> suggested raising the minium python version to 3.8 so that we only have to test with 2 version in the gate instead of 3.(3.6 3.8 and 3.9) >> >> >> >> continuting to support py36 aslo puts a burden on developers not just on our ci infrastucre as it will becomre harder to test wtih going froward >> >> as it stops being shipped in distros and as it exits security support >> >> the end of life for python 3.6 is planned for this month https://www.python.org/dev/peps/pep-0494/#lifespan >> >> speficically (23 Dec 2021) based on https://endoflife.date/python >> >> >> >> i dont think we shoudl be releasing yoga on an end of life python version. >> >> if we raise the minium to 3.8 that will be supported until at least 14 Oct 2024 >> >> which is after the stabel branch will be retired. >> >> >> > >> > So I guess the question is who do we use for language support EOLs? >> > My understanding is that Ubuntu 18.04's default was 3.6 which has >> > standard support until 2023[0] and CentOS Stream 8 will be supported >> > until 2024[1]. Both of which should exceed Yoga's support[2]? With >> > all these arguments about LTS distros, it seems that we should be >> > using their support life cyles for the language versions and not >> > python's[3]. >> > >> > [0] https://wiki.ubuntu.com/Releases >> > [1] https://www.centos.org/cl-vs-cs/ >> > [2] https://releases.openstack.org/ >> > [3] https://devguide.python.org/#status-of-python-branches >> > > > For this reply, "LTS Distro" means support/updates > 13 months This > means regular Ubuntu and Fedora releases don't qualify. Ubuntu LTS, > CentOS Stream * and Debian LTS would qualify. Can we all agree on > this definition? > > https://ubuntu.com/about/release-cycle > https://www.centos.org/cl-vs-cs/#end-of-life > https://wiki.debian.org/LTS > >> >> I'd like to make a proposal for moving forward. But first let's summarize some facts so that we can evaluate the proposal against the state of the world. >> >> * Python 3.6 reaches EOL soon. >> * CentOS 9 Stream is released and makes no mention of being in a beta status (https://www.centos.org/centos-stream/) >> * We have the ability to run tests on CentOS 9 Stream today > > Yes some OpenStack projects can run on CentOS 9 Stream today but not > all can (Puppet OpenStack being one). The assumption that pip install > is sufficient for *all* projects is not correct. At least some testing > needs to be able to be run on all projects before projects can > officially declare <= 3.6 dead. This hopefully will be completed > during Yoga but it takes time. > >> * It is useful to users to ensure we have an OpenStack release tested against old distro release with old python and new distro release with new python. This enables them to update underlying distro releases independently from upgrading OpenStack. >> * The various distros are not in sync over which python versions they support. >> >> Given this state it seems reasonable that we continue to test Yoga against python3.6 and newer python. It would also probably be a good idea to explicitly update the PTI and distro support policies to indicate that when adding new distro releases we continue to support the old distro release's python for one cycle. The level of actual testing done on these platforms will depend on who steps up to maintain that testing, but at the very least we'll accept bug fixes for old python and not prevent installation via setup.cfg python_requires settings. >> >> Yes, this means another cycle of python3.6 support which isn't ideal given it's soon EOL, but the intent is to support distros who will continue to support the older python on their platform. > > IMHO "another cycle" means continued support in Z not Yoga. I think > the ask here was just delay the minimum version until Z so this would > be the last cycle with 3.6 support. Jeremy said in a subsequent > message that the interpreter comes from an LTS distro which IMHO means > the EOL is the distro's EOL not Python's. Now this brings up issues if > we can't get 3.6 fixes for specific versions of our dependencies that > come in via pypi, but do we have data how often this is actually a > problem? Isn't that already a problem for stable branches? Or are we > worrying about something that doesn't happen? We need to all agree on > where EOL dates come from for dependencies and expectations around > them. The point I was trying to make was more that we should be explicit about when the overlap happens; write that down in our policy so that the next time this comes up the process goes more smoothly. I suppose if we have to delay for an additional cycle that may be the cost of not having considered this ahead of time. I think Jeremy covered why the Python EOL is important. Our dependencies tend to start dropping like flies when python versions go EOL. I think we can survive for a time, but we shouldn't try to keep them alive for the long term. > > LTS Distros are being referenced in this thread but people keep going > back to EOL dates that are not aligned with these distros. For the > full OpenStack project ecosystem, testing is occurring on Ubuntu, > CentOS, and a bit of Debian. IMHO when a release (e.g. Yoga) is > released, we should use what is available at the start of cycle and > using the EOL dates of the tested distros in determining decisions > around version support. If we use this for Yoga, realistically CentOS > Stream 8 and Ubuntu 20.04 could be used which would leave us with > 3.6/3.8. It seems Debian was the only one with 3.7 > (https://wiki.debian.org/Python). Since CentOS Stream 9 was released > during the Yoga cycle, we couldn't pick it up as a version until Z but > we could then make the 3.8 cutoff then. If Ubuntu releases a new > version (the website says they might) during Yoga with 3.9 then we > could talk about raising it further in Z. This would allow for lower > bounds to be pushed, but requires that one of our qualifying LTS > distros in check/gate were already available at the start of a cycle. > > What I would like is that people stop pointing to Python's EOL date > which is newer but does not actually align with the assumption of an > LTS distro. It would only make sense to use that date if we were > basing our testing on non-LTS distros which may be able to follow > their EOL dates more closely. I keep hammering on the LTS distro > because OpenStack is heavily reliant on packages and hardware > supported by distros that it is very closely tied to what is > available. If OpenStack had no tie to distro hardware support, venvs > and pip installing all the things might be sufficient but there are > many dependencies which end up not being satisfied this way. You can > get away with it up to a point, but it's an important integration > point. > >> >> If we want to be bold and try an experiment, we could also reduce testing of the python versions to oldest and newest supported python versions. For example python3.6 and python3.9 during Yoga. Don't worry about python3.7 and python3.8 as it is likely they will continue to function as long as 3.6 and 3.9 are happy. This would reduce the size of the testing matrix. We can always reevaluate if problems for 3.7 and 3.8 occur. >> > > The issue here I think is trying to align on a default LTS distro > python. CS8,18.04 is 3.6, Debian Buster is 3.7, 20.04 is 3.8 and CS9 > will be 3.9. Personally I think 3.6/3.9 is sufficient because for the > projects I contribute to this covers my cases. But this would exclude > the 3.8 on 20.04. Would this be a problem for Ubuntu's UCA? Ubuntu 20.04 includes a python 3.9. I don't know how that would impact the UCA or Ubuntu's packaging though. That said I have a strong suspicion that if OpenStack runs on 3.6 and 3.9 that it should just work on 3.8 as well. And as I mentioned if we prove that wrong through experience we can always fix 3.8 and go back to explicitly testing it. I don't think this particular change is super critical, but I know some people were concerned about the number of pythons that would need testing. > >> Finally, I think it is important to note that OpenStack is using CentOS as a stand in for RHEL. This worked a lot better when CentOS was an actual copy of RHEL. What we've got today is CentOS stream and it makes no claims about being in beta until RHEL releases (that I can find anyway), and I don't think we should make those assertions ourselves. If there is interest in using a different stand in (Alma or Rocky?) then we should replace CentOS stream with one of those alternatives. Another option may be to assert that Stream only functions as a standin once RHEL has released their corresponding update, but it is my understanding that Stream and RHEL will always have some delta. > > There has always been a delta. The change now is the delta has been > reversed such that we'll get fixes for things before RHEL but this is > likely better for OpenStack's use cases where the previous meant long > delays to get necessary fixes. I'm uncertain why the RHEL release > schedule is being factored in to determine some indication of > stability when testing is occurring > (https://www.centos.org/cl-vs-cs/#testing). I'm explicitly saying don't compare to RHEL for stability. CentOS 9 Stream is released as far as I can tell. It isn't labeled a beta release. You can download and run it today. We run CentOS testing because OpenStack asserts that it supports RHEL and historically CentOS was the closest we could get to RHEL. I'm saying we might consider if continuing to use CentOS for that goal is still appropriate. If it is then lets just use 9 Stream today as it is released and ready to go. If it isn't appropriate because it isn't close enough to RHEL, then we should consider an alternative like Alma or Rocky or perhaps they will converge more once RHEL has released. Basically I'm saying lets get away from thinking about this in terms of "is stream ready/beta/etc" and think in terms of "does using stream accomplish the goals of testing to ensure RHEL compatibility". > > Thanks, > -Alex > >> >> Clark >> From tonyliu0592 at hotmail.com Wed Dec 1 22:04:19 2021 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Wed, 1 Dec 2021 22:04:19 +0000 Subject: [kolla] Plan to deprecate binary and unify on single distrubition In-Reply-To: References: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com>

Message-ID: Since I've never used source container and not able to find answers from doc, bear my dummy questions. BTW, I am not able to figure it out from Dockerfile.j2. Take centos-source-mariadb as an example, is it built by 1) installing packages from package repo or 2) download source code, compile and build packages and install self-build packages? In case of 2), how can I tell where and which release source code is downloaded and how it's compiled and built? In case of 1), what's the difference here from centos-binary-mariadb? Similarly, take centos-source-keystone as another example, is it built by 1) installing package from eg. centos/8-stream/cloud/x86_64/openstack-ussuri/ or 2) download source code from Github, build packages locally and install them? The same questions here, for 1) what's the difference from binary container, for 2) how can I tell which revision the source code is downloaded? Or, the source container is binary container with source code? Thanks! Tony ________________________________________ Fro: Adrian Andreias Sent: December 1, 2021 01:30 PM To: Tony Liu Cc: Micha? Nasiadka; openstack-discuss Subject: Re: [kolla] Plan to deprecate binary and unify on single distrubition The user doesn't have to build the images that are source based. Ready built source-based images are available: https://quay.io/search?q=kolla Binary-based Kolla docker images are installing (at image build time) OpenStack projects via system packages, while source based images are symply adding projects' Python source code. Just as you said, the user shouldn't care much about distro inside images. But makes things a lot easier for developers to maintain less images and without working around different versions and dependencies provided by the system packages of various distros. Regards, Adrian Andreias On Wed, Dec 1, 2021 at 10:31 PM Tony Liu > wrote: For OpenStack, I've been using centos-binary containers on CentOS. It's been working very well. I don't have much concern on supporting single-distro based container on different distro hosts. That's actually one of the beauties of container, which self-contains all packages and dependencies. We used to have a product based on single-distro container and support different distro hosts. Just need to be careful when container needs any resource from the host, like kernel, mounted host filesystem, networking, privilege, etc. Regarding to source container, what's the purpose of it? Is it allow user to get the package based on some specific source that is not provided by any existing package repo? In that case, I'd assume user should always build their own source container. Then what's the purpose of providing pre-build source container? Also, are those non-core containers, like MariaDB, HAProxy, RabbitMQ, etc. all built from source code? Thanks! Tony ________________________________________ From: Micha? Nasiadka > Sent: November 18, 2021 04:33 AM To: openstack-discuss Subject: [kolla] Plan to deprecate binary and unify on single distrubition Hello Koalas, On the PTG we have discussed two topics: 1) Deprecate and drop binary type of Kolla images 2) Use a common base (single Linux distribution) for Kolla images This is a call for feedback - for people that have not been attending the PTG. What this essentially mean for consumers: 1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z cycle those will be dropped. 2) We are not going to support CentOS Stream 9 (cs9) as a base operating system, and the source type build will rely on CentOS Stream 8 in Z release. 3) Beginning from A release Kolla will build only Debian source images - but Kolla-Ansible will still support deployment of those images on CentOS/Ubuntu/Debian Host operating systems (and Rocky Linux to be added in Yoga to that mix). Justification: The Kolla project team is limited in numbers, therefore supporting current broad mix of operating systems (especially with CentOS Stream 9 ,,on the way??) is a significant maintenance burden. By dropping binary type of images - users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images jobs as voting). In Xena we?ve already changed the default image type Kolla-Ansible uses to source. We also feel that using a unified base OS for Kolla container images is a way to remove some of the maintenance burden (including CI cycles and Request for feedback: If any of those changes is a no go from your perspective - we?d like to hear your opinions. Best regards, Michal Nasiadka From gmann at ghanshyammann.com Wed Dec 1 22:29:35 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 01 Dec 2021 16:29:35 -0600 Subject: [all][tc] Technical Committee next weekly meeting on Dec 2nd at 1500 UTC In-Reply-To: <17d6cf1413a.11da1006039481.6604682679623549161@ghanshyammann.com> References: <17d6cf1413a.11da1006039481.6604682679623549161@ghanshyammann.com> Message-ID: <17d781e0eab.b5fe932f194678.5688946776937692361@ghanshyammann.com> Hello Everyone, Below is the agenda for Tomorrow's TC video 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 * Updates on community-wide goal ** Selecting RBAC goal *** https://review.opendev.org/c/openstack/governance/+/818817 ** Proposed community goal for FIPS compatibility and compliance *** https://review.opendev.org/c/openstack/governance/+/816587 * Yoga testing runtime: revert the drop of py3.6? ** http://lists.openstack.org/pipermail/openstack-discuss/2021-November/026024.html * Adjutant need PTLs and maintainers ** http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025555.html * TC position on release cadence? ** http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025684.html * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Mon, 29 Nov 2021 12:24:49 -0600 Ghanshyam Mann wrote ---- > Hello Everyone, > > Technical Committee's next weekly meeting is scheduled for Dec 2nd at 1500 UTC. > > If you would like to add topics for discussion, please add them to the below wiki page by > Wednesday, Dec 1st, at 2100 UTC. > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > -gmann > > From zigo at debian.org Wed Dec 1 22:33:54 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 1 Dec 2021 23:33:54 +0100 Subject: [nova] Spawning instance that will do PXE booting Message-ID: Hi, In order to test OCI [1] within OpenStack itself, I would need my instances to do PXE booting. This would be with something like this on the qemu command line: qemu-system-x86_64 -boot n I believe this would also mean setting-up network cards that can do PXE booting, like the e1000, which Qemu supports. If that is possible, then I would setup DHCP + tftp-hpa on another instance, wired on the same private network. Your thoughts? Is this possible? Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer From openstack at a.spamming.party Wed Dec 1 22:43:32 2021 From: openstack at a.spamming.party (Jean-Philippe Evrard) Date: Wed, 01 Dec 2021 23:43:32 +0100 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> Message-ID: <6536dfae-cb75-4263-856d-f4dbdfa2db01@www.fastmail.com> 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)? Thank you in advance. Regards, Jean-Philippe Evrard (evrardjp) From adrian at fleio.com Wed Dec 1 23:04:26 2021 From: adrian at fleio.com (Adrian Andreias) Date: Thu, 2 Dec 2021 01:04:26 +0200 Subject: [kolla] Plan to deprecate binary and unify on single distrubition In-Reply-To: References: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com>

Message-ID: "source" refers here to OpenStack projects source code: https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/nova/nova-base/Dockerfile.j2#L52 There is no reason to build MariaDB from source. System package are always used (regardless of binary/source config): https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/mariadb/mariadb-base/Dockerfile.j2#L14 https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/mariadb/mariadb-server/Dockerfile.j2#L15 Image names like "centos-source-mariadb" are probably just kept for consistency. If you want to experiment and see what's happening, you can build images yourself: https://docs.openstack.org/kolla/latest/admin/image-building.html Anyhow, the thread is about any blockers on Micha?'s proposal. I think it makes sense: less ground to cover and effort will be focused on a few reliable images. The only possible issue I can imagine would be a project that already has massive image customizations that are based on binary images. Otherwise, minor customizations or standard images should not impact change from binary to source nor to single distro. Regards, Adrian Andreias On Thu, Dec 2, 2021 at 12:04 AM Tony Liu wrote: > Since I've never used source container and not able to find answers from > doc, > bear my dummy questions. BTW, I am not able to figure it out from > Dockerfile.j2. > > Take centos-source-mariadb as an example, is it built by 1) installing > packages > from package repo or 2) download source code, compile and build packages > and > install self-build packages? In case of 2), how can I tell where and which > release > source code is downloaded and how it's compiled and built? In case of 1), > what's > the difference here from centos-binary-mariadb? > > Similarly, take centos-source-keystone as another example, is it built by > 1) installing package from eg. > centos/8-stream/cloud/x86_64/openstack-ussuri/ > or 2) download source code from Github, build packages locally and install > them? > The same questions here, for 1) what's the difference from binary > container, > for 2) how can I tell which revision the source code is downloaded? > > Or, the source container is binary container with source code? > > Thanks! > Tony > ________________________________________ > Fro: Adrian Andreias > Sent: December 1, 2021 01:30 PM > To: Tony Liu > Cc: Micha? Nasiadka; openstack-discuss > Subject: Re: [kolla] Plan to deprecate binary and unify on single > distrubition > > The user doesn't have to build the images that are source based. Ready > built source-based images are available: https://quay.io/search?q=kolla > > Binary-based Kolla docker images are installing (at image build time) > OpenStack projects via system packages, while source based images are > symply adding projects' Python source code. > > Just as you said, the user shouldn't care much about distro inside images. > But makes things a lot easier for developers to maintain less images and > without working around different versions and dependencies provided by the > system packages of various distros. > > > Regards, > Adrian Andreias > > > > > On Wed, Dec 1, 2021 at 10:31 PM Tony Liu tonyliu0592 at hotmail.com>> wrote: > For OpenStack, I've been using centos-binary containers on CentOS. It's > been working very well. > > I don't have much concern on supporting single-distro based container on > different distro hosts. > That's actually one of the beauties of container, which self-contains all > packages and dependencies. > We used to have a product based on single-distro container and support > different distro hosts. > Just need to be careful when container needs any resource from the host, > like kernel, mounted > host filesystem, networking, privilege, etc. > > Regarding to source container, what's the purpose of it? Is it allow user > to get the package based > on some specific source that is not provided by any existing package repo? > In that case, I'd assume > user should always build their own source container. Then what's the > purpose of providing pre-build > source container? Also, are those non-core containers, like MariaDB, > HAProxy, RabbitMQ, etc. all > built from source code? > > > Thanks! > Tony > ________________________________________ > From: Micha? Nasiadka > > Sent: November 18, 2021 04:33 AM > To: openstack-discuss > Subject: [kolla] Plan to deprecate binary and unify on single distrubition > > Hello Koalas, > > On the PTG we have discussed two topics: > > 1) Deprecate and drop binary type of Kolla images > 2) Use a common base (single Linux distribution) for Kolla images > > This is a call for feedback - for people that have not been attending the > PTG. > > What this essentially mean for consumers: > > 1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z > cycle those will be dropped. > 2) We are not going to support CentOS Stream 9 (cs9) as a base operating > system, and the source type build will rely on CentOS Stream 8 in Z release. > 3) Beginning from A release Kolla will build only Debian source images - > but Kolla-Ansible will still support deployment of those images on > CentOS/Ubuntu/Debian Host operating systems (and Rocky Linux to be added in > Yoga to that mix). > > Justification: > The Kolla project team is limited in numbers, therefore supporting current > broad mix of operating systems (especially with CentOS Stream 9 ,,on the > way??) is a significant maintenance burden. > By dropping binary type of images - users would be running more tested > images (since Kolla/Kolla-Ansible CI runs source images jobs as voting). > In Xena we?ve already changed the default image type Kolla-Ansible uses to > source. > We also feel that using a unified base OS for Kolla container images is a > way to remove some of the maintenance burden (including CI cycles and > > Request for feedback: > If any of those changes is a no go from your perspective - we?d like to > hear your opinions. > > Best regards, > Michal Nasiadka > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyliu0592 at hotmail.com Wed Dec 1 23:14:55 2021 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Wed, 1 Dec 2021 23:14:55 +0000 Subject: [kolla] Plan to deprecate binary and unify on single distrubition In-Reply-To: References: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com>

Message-ID: Thank you Adrian for clarifications! I am good with Micha?'s proposal, although it will add a bit overhead to rpm-operator when need to look into container. For example, you need to keep it in mind that the container is Debian based and run dpkg instead of rpm. Tony ________________________________________ From: Adrian Andreias Sent: December 1, 2021 03:04 PM To: Tony Liu Cc: Micha? Nasiadka; openstack-discuss Subject: Re: [kolla] Plan to deprecate binary and unify on single distrubition "source" refers here to OpenStack projects source code: https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/nova/nova-base/Dockerfile.j2#L52 There is no reason to build MariaDB from source. System package are always used (regardless of binary/source config): https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/mariadb/mariadb-base/Dockerfile.j2#L14 https://opendev.org/openstack/kolla/src/commit/1a9d5a1a42c86b447af371ab5e0864f2b452f6ad/docker/mariadb/mariadb-server/Dockerfile.j2#L15 Image names like "centos-source-mariadb" are probably just kept for consistency. If you want to experiment and see what's happening, you can build images yourself: https://docs.openstack.org/kolla/latest/admin/image-building.html Anyhow, the thread is about any blockers on Micha?'s proposal. I think it makes sense: less ground to cover and effort will be focused on a few reliable images. The only possible issue I can imagine would be a project that already has massive image customizations that are based on binary images. Otherwise, minor customizations or standard images should not impact change from binary to source nor to single distro. Regards, Adrian Andreias On Thu, Dec 2, 2021 at 12:04 AM Tony Liu > wrote: Since I've never used source container and not able to find answers from doc, bear my dummy questions. BTW, I am not able to figure it out from Dockerfile.j2. Take centos-source-mariadb as an example, is it built by 1) installing packages from package repo or 2) download source code, compile and build packages and install self-build packages? In case of 2), how can I tell where and which release source code is downloaded and how it's compiled and built? In case of 1), what's the difference here from centos-binary-mariadb? Similarly, take centos-source-keystone as another example, is it built by 1) installing package from eg. centos/8-stream/cloud/x86_64/openstack-ussuri/ or 2) download source code from Github, build packages locally and install them? The same questions here, for 1) what's the difference from binary container, for 2) how can I tell which revision the source code is downloaded? Or, the source container is binary container with source code? Thanks! Tony ________________________________________ Fro: Adrian Andreias > Sent: December 1, 2021 01:30 PM To: Tony Liu Cc: Micha? Nasiadka; openstack-discuss Subject: Re: [kolla] Plan to deprecate binary and unify on single distrubition The user doesn't have to build the images that are source based. Ready built source-based images are available: https://quay.io/search?q=kolla Binary-based Kolla docker images are installing (at image build time) OpenStack projects via system packages, while source based images are symply adding projects' Python source code. Just as you said, the user shouldn't care much about distro inside images. But makes things a lot easier for developers to maintain less images and without working around different versions and dependencies provided by the system packages of various distros. Regards, Adrian Andreias On Wed, Dec 1, 2021 at 10:31 PM Tony Liu >> wrote: For OpenStack, I've been using centos-binary containers on CentOS. It's been working very well. I don't have much concern on supporting single-distro based container on different distro hosts. That's actually one of the beauties of container, which self-contains all packages and dependencies. We used to have a product based on single-distro container and support different distro hosts. Just need to be careful when container needs any resource from the host, like kernel, mounted host filesystem, networking, privilege, etc. Regarding to source container, what's the purpose of it? Is it allow user to get the package based on some specific source that is not provided by any existing package repo? In that case, I'd assume user should always build their own source container. Then what's the purpose of providing pre-build source container? Also, are those non-core containers, like MariaDB, HAProxy, RabbitMQ, etc. all built from source code? Thanks! Tony ________________________________________ From: Micha? Nasiadka >> Sent: November 18, 2021 04:33 AM To: openstack-discuss Subject: [kolla] Plan to deprecate binary and unify on single distrubition Hello Koalas, On the PTG we have discussed two topics: 1) Deprecate and drop binary type of Kolla images 2) Use a common base (single Linux distribution) for Kolla images This is a call for feedback - for people that have not been attending the PTG. What this essentially mean for consumers: 1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z cycle those will be dropped. 2) We are not going to support CentOS Stream 9 (cs9) as a base operating system, and the source type build will rely on CentOS Stream 8 in Z release. 3) Beginning from A release Kolla will build only Debian source images - but Kolla-Ansible will still support deployment of those images on CentOS/Ubuntu/Debian Host operating systems (and Rocky Linux to be added in Yoga to that mix). Justification: The Kolla project team is limited in numbers, therefore supporting current broad mix of operating systems (especially with CentOS Stream 9 ,,on the way??) is a significant maintenance burden. By dropping binary type of images - users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images jobs as voting). In Xena we?ve already changed the default image type Kolla-Ansible uses to source. We also feel that using a unified base OS for Kolla container images is a way to remove some of the maintenance burden (including CI cycles and Request for feedback: If any of those changes is a no go from your perspective - we?d like to hear your opinions. Best regards, Michal Nasiadka From tonyliu0592 at hotmail.com Wed Dec 1 23:47:09 2021 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Wed, 1 Dec 2021 23:47:09 +0000 Subject: [nova] Spawning instance that will do PXE booting In-Reply-To: References: Message-ID: Here is what I would do, not validated. * Create a network with DHCP disabled. * Launch a VM to support PXE boot. * Launch a VM on volume based on any image for PXE boot. * The default virtio nic works fine with PXE boot. * "virsh edit " to enable PXE boot on the compute node. * "soft reboot" VM should bring VM to PXE boot. I prefer to do this with virsh/libvirt directly, which is much easier. Tony ________________________________________ From: Thomas Goirand Sent: December 1, 2021 02:33 PM To: openstack-discuss at lists.openstack.org Subject: [nova] Spawning instance that will do PXE booting Hi, In order to test OCI [1] within OpenStack itself, I would need my instances to do PXE booting. This would be with something like this on the qemu command line: qemu-system-x86_64 -boot n I believe this would also mean setting-up network cards that can do PXE booting, like the e1000, which Qemu supports. If that is possible, then I would setup DHCP + tftp-hpa on another instance, wired on the same private network. Your thoughts? Is this possible? Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer From cboylan at sapwetik.org Wed Dec 1 23:51:43 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 01 Dec 2021 15:51:43 -0800 Subject: [nova] Spawning instance that will do PXE booting In-Reply-To: References: Message-ID: <620fe1cf-cd03-4d76-8614-aeeb83cf103d@www.fastmail.com> On Wed, Dec 1, 2021, at 2:33 PM, Thomas Goirand wrote: > Hi, > > In order to test OCI [1] within OpenStack itself, I would need my > instances to do PXE booting. This would be with something like this on > the qemu command line: > > qemu-system-x86_64 -boot n > > I believe this would also mean setting-up network cards that can do PXE > booting, like the e1000, which Qemu supports. > > If that is possible, then I would setup DHCP + tftp-hpa on another > instance, wired on the same private network. > > Your thoughts? Is this possible? I'm not super familiar with all the details but I believe ironic does something similar in their devstack plugin [2]. They do this so they can create fake baremetal instances that are actually VMs that ironic manages. But a similar setup will probably work for your use cases if PXE is what you are starting with. > > Cheers, > > Thomas Goirand (zigo) > > [1] > https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer [2] https://opendev.org/openstack/ironic/src/branch/master/devstack/lib/ironic#L2109 From zigo at debian.org Thu Dec 2 00:04:03 2021 From: zigo at debian.org (Thomas Goirand) Date: Thu, 2 Dec 2021 01:04:03 +0100 Subject: [kolla] Plan to deprecate binary and unify on single distrubition In-Reply-To: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com> References: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com> Message-ID: On 11/18/21 1:33 PM, Micha? Nasiadka wrote: > Hello Koalas, > > On the PTG we have discussed two topics: > > 1) Deprecate and drop binary type of Kolla images > 2) Use a common base (single Linux distribution) for Kolla images > > This is a call for feedback - for people that have not been attending the PTG. > > What this essentially mean for consumers: > > 1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z cycle those will be dropped. > 2) We are not going to support CentOS Stream 9 (cs9) as a base operating system, and the source type build will rely on CentOS Stream 8 in Z release. > 3) Beginning from A release Kolla will build only Debian source images - but Kolla-Ansible will still support deployment of those images on CentOS/Ubuntu/Debian Host operating systems (and Rocky Linux to be added in Yoga to that mix). > > Justification: > The Kolla project team is limited in numbers, therefore supporting current broad mix of operating systems (especially with CentOS Stream 9 ,,on the way??) is a significant maintenance burden. > By dropping binary type of images - users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images jobs as voting). > In Xena we?ve already changed the default image type Kolla-Ansible uses to source. > We also feel that using a unified base OS for Kolla container images is a way to remove some of the maintenance burden (including CI cycles and > > Request for feedback: > If any of those changes is a no go from your perspective - we?d like to hear your opinions. > > Best regards, > Michal Nasiadka Hi, While I fully support moving to a Debian only world (anyone who knows me isn't surprised to read this...), I really wonder if moving to a "source only" world is the right step. If you don't have enough people, why don't you just move to a Debian package only type of install, rather than re-implementing all by yourself? The very point of packages is to abstract for you many things, like for example, the fact that Nova has a reserved UID/GID of 64060 in Debian, and will always use that one, and automatically set that up for you, plus put the Nova user in the right group... Or if you need another example, making sure that swift-proxy starts with the right "route = .* addheader:Date: ${httptime[]}" uwsgi parameter... etc. Now, if you have a limited amount of contributors, all these tiny tweaks that the package maintainers are doing for you, you'll have to re-implement them yourself. Worse: it's going to be even more complicated if you put stuff in containers. Using source only images, you also don't get all the testing that's done by distro on funny arch which you probably didn't think of. Yes, the openvswitch package in Debian is tested and working on the 10 official Debian arch. The lz4tools contains a 32 bits patch. Or is it that you don't care about anything else than x86_64? So why don't you just take the other direction, and drop the source images? I'm sure this will save you a lot of work. Plus myself and Michal will make sure everything works, and is available in time for every release, like we always did (did you notice Debian is often (if not always) the first distro to have available packages for each release?). Cheers, Thomas Goirand (zigo) P.S: I'm using puppet-openstack myself, so I wont ever contribute to Kolla and/or OSA, but I still would like to support you... From zigo at debian.org Thu Dec 2 00:09:58 2021 From: zigo at debian.org (Thomas Goirand) Date: Thu, 2 Dec 2021 01:09:58 +0100 Subject: [nova] Spawning instance that will do PXE booting In-Reply-To: References: Message-ID: <70a61878-a798-f833-48c8-f177ce4fa38b@debian.org> Hi Tony, Thanks for your reply. On 12/2/21 12:47 AM, Tony Liu wrote: > Here is what I would do, not validated. > * Create a network with DHCP disabled. > * Launch a VM to support PXE boot. > * Launch a VM on volume based on any image for PXE boot. > * The default virtio nic works fine with PXE boot. > * "virsh edit " to enable PXE boot on the compute node. This isn't an option. To do "virsh edit", you need to have root access to a compute node, and that's not what I would like to do: I'd like my CI to run with a normal OpenStack account only, to make it easy for people to reuse. > * "soft reboot" VM should bring VM to PXE boot. > > I prefer to do this with virsh/libvirt directly, which is much easier. > > Tony Cheers, Thomas Goirand (zigo) From openinfradn at gmail.com Thu Dec 2 03:28:15 2021 From: openinfradn at gmail.com (open infra) Date: Thu, 2 Dec 2021 08:58:15 +0530 Subject: cpu pinning Message-ID: Hi, I have created a flavor with following properties and created an instance. Instance failed with the error "No valid host was found. There are not enough hosts available." When I set the cpu policy as 'shared' I can create the instance. The host machine has two numa nodes and a total of 128 vcpu. I can not figure out what's missing here. controller-1:~$ openstack flavor show dn.large -c properties +------------+--------------------------------------------------------------------------------------------------------+ | Field | Value | +------------+--------------------------------------------------------------------------------------------------------+ | properties | hw:cpu_cores='2', hw:cpu_policy='dedicated', hw:cpu_sockets='1', hw:cpu_threads='2', hw:numa_nodes='1' | +------------+--------------------------------------------------------------------------------------------------------+ controller-1:~$ openstack hypervisor stats show +----------------------+--------+ | Field | Value | +----------------------+--------+ | count | 1 | | current_workload | 0 | | disk_available_least | 187 | | free_disk_gb | 199 | | free_ram_mb | 308787 | | local_gb | 219 | | local_gb_used | 20 | | memory_mb | 515443 | | memory_mb_used | 206656 | | running_vms | 7 | | vcpus | 126 | | vcpus_used | 49 | +----------------------+--------+ Regards, Danishka -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnasiadka at gmail.com Thu Dec 2 07:37:34 2021 From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=) Date: Thu, 2 Dec 2021 08:37:34 +0100 Subject: [kolla] Plan to deprecate binary and unify on single distrubition In-Reply-To: References: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com> Message-ID: Hi Thomas, Thanks for your opinion - but we can?t really wait until each Debian OpenStack release to test all the features (and what will be broken) - we already trail long time after the official OpenStack release due to other issues. That would significantly lengthen the delay and the process involved. Kolla has been doing voting CI on source images for a long time - and we don?t want to change it. It?s also a direction to make the external dependencies smaller - not bigger - and I see the custom things added from packager perspective as a dependency. Best regards, Michal > On 2 Dec 2021, at 01:04, Thomas Goirand wrote: > > On 11/18/21 1:33 PM, Micha? Nasiadka wrote: >> Hello Koalas, >> >> On the PTG we have discussed two topics: >> >> 1) Deprecate and drop binary type of Kolla images >> 2) Use a common base (single Linux distribution) for Kolla images >> >> This is a call for feedback - for people that have not been attending the PTG. >> >> What this essentially mean for consumers: >> >> 1) In Yoga cycle we will deprecate binary type of Kolla images, and in Z cycle those will be dropped. >> 2) We are not going to support CentOS Stream 9 (cs9) as a base operating system, and the source type build will rely on CentOS Stream 8 in Z release. >> 3) Beginning from A release Kolla will build only Debian source images - but Kolla-Ansible will still support deployment of those images on CentOS/Ubuntu/Debian Host operating systems (and Rocky Linux to be added in Yoga to that mix). >> >> Justification: >> The Kolla project team is limited in numbers, therefore supporting current broad mix of operating systems (especially with CentOS Stream 9 ,,on the way??) is a significant maintenance burden. >> By dropping binary type of images - users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images jobs as voting). >> In Xena we?ve already changed the default image type Kolla-Ansible uses to source. >> We also feel that using a unified base OS for Kolla container images is a way to remove some of the maintenance burden (including CI cycles and >> >> Request for feedback: >> If any of those changes is a no go from your perspective - we?d like to hear your opinions. >> >> Best regards, >> Michal Nasiadka > > Hi, > > While I fully support moving to a Debian only world (anyone who knows me > isn't surprised to read this...), I really wonder if moving to a "source > only" world is the right step. > > If you don't have enough people, why don't you just move to a Debian > package only type of install, rather than re-implementing all by > yourself? The very point of packages is to abstract for you many things, > like for example, the fact that Nova has a reserved UID/GID of 64060 in > Debian, and will always use that one, and automatically set that up for > you, plus put the Nova user in the right group... Or if you need another > example, making sure that swift-proxy starts with the right "route = .* > addheader:Date: ${httptime[]}" uwsgi parameter... etc. > > Now, if you have a limited amount of contributors, all these tiny tweaks > that the package maintainers are doing for you, you'll have to > re-implement them yourself. Worse: it's going to be even more > complicated if you put stuff in containers. > > Using source only images, you also don't get all the testing that's done > by distro on funny arch which you probably didn't think of. Yes, the > openvswitch package in Debian is tested and working on the 10 official > Debian arch. The lz4tools contains a 32 bits patch. Or is it that you > don't care about anything else than x86_64? > > So why don't you just take the other direction, and drop the source > images? I'm sure this will save you a lot of work. Plus myself and > Michal will make sure everything works, and is available in time for > every release, like we always did (did you notice Debian is often (if > not always) the first distro to have available packages for each release?). > > Cheers, > > Thomas Goirand (zigo) > > P.S: I'm using puppet-openstack myself, so I wont ever contribute to > Kolla and/or OSA, but I still would like to support you... > From zigo at debian.org Thu Dec 2 08:07:23 2021 From: zigo at debian.org (Thomas Goirand) Date: Thu, 2 Dec 2021 09:07:23 +0100 Subject: [nova] Spawning instance that will do PXE booting In-Reply-To: <620fe1cf-cd03-4d76-8614-aeeb83cf103d@www.fastmail.com> References: <620fe1cf-cd03-4d76-8614-aeeb83cf103d@www.fastmail.com> Message-ID: <5af59ddc-669f-09cf-233e-5f85f0e89999@debian.org> On 12/2/21 12:51 AM, Clark Boylan wrote: > I'm not super familiar with all the details but I believe ironic does something similar in their devstack plugin [2]. They do this so they can create fake baremetal instances that are actually VMs that ironic manages. But a similar setup will probably work for your use cases if PXE is what you are starting with. > > [2] https://opendev.org/openstack/ironic/src/branch/master/devstack/lib/ironic#L2109 Hi, Thanks Clark for your answer. I've read the script a little bit, and I have to admit I do not understand what it does... :( If some Ironic falks can explain, that'd be great! Cheers, Thomas Goirand (zigo) From zigo at debian.org Thu Dec 2 08:15:55 2021 From: zigo at debian.org (Thomas Goirand) Date: Thu, 2 Dec 2021 09:15:55 +0100 Subject: [kolla] Plan to deprecate binary and unify on single distrubition In-Reply-To: References: <7B0C2125-975E-437C-B332-9E88F725D248@gmail.com>

Message-ID: <0cb15dca-99d0-9358-233d-4e85b5d1104d@debian.org> Hi Michal, Thanks for your reply. I'm sorry to say that your reply shows a poor understanding of what distributions and packaging are in general, and what Debian does for OpenStack in particular. But I'm not surprised, this isn't the first time I see this. It also happened when I was employed by Mirantis, and with cloudwatt. People usually just dismiss packaging because they see it as a black-box they cannot act on, because they just happen to not do packaging themselves. On 12/2/21 8:37 AM, Micha? Nasiadka wrote: > Hi Thomas, > > Thanks for your opinion - but we can?t really wait until each Debian OpenStack release to test all the features (and what will be broken) - we already trail long time after the official OpenStack release due to other issues. > That would significantly lengthen the delay and the process involved. This isn't fair, and IMO isn't truth. Usually, Debian packages are ready *before* the final release, often just a week after the first RCs are out. The only reason why there's always one or 2 glitches, is because I couldn't install the new release until everything is finished (and from my side, including updating my puppet scripts for the new release of puppet-openstack). So, we're talking about just a few days delay after the release. This normally gives you enough time to fix things, and have Kolla ready the day of the release. I used to package all the beta releases, twice per OpenStack release. Though nobody ever consumed them. And these days, not all projects are release beta releases, so it is kind of useless. > It?s also a direction to make the external dependencies smaller - not bigger - and I see the custom things added from packager perspective as a dependency. IMO, that's a very wrong perspective. Package maintainers (that's how we're called, not "packager" please...) are adding automations and system integrations. If you refuse them, this means you'll have to implement them yourself. Remember that I use puppet myself, so I very well know what I'm talking about, when discussing config management and package integration. When I can make a choice of where to do the automation, system dependency, etc., then it goes to the packaging: this is the normal and natural place to do it. A config management system should not be the one taking care of any of the things that packages normally take care of (like dependencies). Handling them in your config management system is not only an heresy, it's also using the wrong tool for it, and achieving a poorer result. Also, handing dependency management using something like pip is a non-sense, because it only knows about Python dependencies (not anything else), and it's been demonstrated so many times how bad pip is as a dependency solver: for example, it broke the CI so many times, showing its defects. Another thing you're seeing wrong, is about smaller dependencies. First, having one more Python package will not hurt, and if it is there, it is for a reason. Second, packages are designed to have the smaller amount of dependency possible. Always. As a rule. If there's something wrong there, it's easy to fix (and you could contribute to it...). And we also make sure that everything works together, adding patches when needed (how are you going to manage patches?). I'm not hoping to convince you, I feel it's already too late. Though I can't help myself to let you know I believe you're doing the wrong technical choice. Cheers, Thomas Goirand (zigo) From mdemaced at redhat.com Thu Dec 2 11:10:09 2021 From: mdemaced at redhat.com (Maysa De Macedo Souza) Date: Thu, 2 Dec 2021 12:10:09 +0100 Subject: [kuryr] Propose to EOL stable branches (Stein, Rocky and Queens) for all the kuryr scope In-Reply-To: <3c2cbd0af92ff7dffb3fae4ce6c30015abd94b6b.camel@redhat.com> References:

<3c2cbd0af92ff7dffb3fae4ce6c30015abd94b6b.camel@redhat.com> Message-ID: Hello, Here is the patch[1] proposing the eol for pike, queen, rocky and stein branches. If anyone wants to keep those branches, let us know. [1] https://review.opendev.org/c/openstack/releases/+/820144/ Cheers, Maysa. On Wed, Dec 1, 2021 at 9:59 AM Micha? Dulko wrote: > Yes, let's remove them. It has little sense to keep these versions and > we're actually actively working to keep the compatibility with older > OpenStack versions anyway. > > On Fri, 2021-11-26 at 23:50 +0100, Maysa De Macedo Souza wrote: > > Hello again, > > > > We also have Pike as a stable branch[0], so that is the older one, > > which would also be EOL. > > > > [0] > > > https://review.opendev.org/q/(project:%255Eopenstack/kuryr.*)AND((branch:stable/queens)OR(branch:stable/rocky)OR(branch:stable/stein)OR(branch:stable/pike)) > > > > Cheers, > > Maysa. > > > > On Fri, Nov 26, 2021 at 11:42 PM Maysa De Macedo Souza > > wrote: > > > Hello, > > > > > > We have plenty of stable branches in Kuryr repositories still open > > > with the oldest being stable/queens. > > > We haven't seen many backports[0] proposed to Stein, Rocky and > > > Queens, so I would like to propose retiring these branches. > > > > > > Let me know if anybody is interested in keeping any of those > > > branches. > > > > > > [0] > > > > https://review.opendev.org/q/(project:%255Eopenstack/kuryr.*)AND((branch:stable/queens)OR(branch:stable/rocky)OR(branch:stable/stein)) > > > > > > Thank you, > > > Maysa Macedo. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.therond at bitswalk.com Thu Dec 2 11:57:35 2021 From: gael.therond at bitswalk.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=) Date: Thu, 2 Dec 2021 11:57:35 +0000 Subject: Windows imaging process In-Reply-To: References:

Message-ID: Hi Patryk, Thanks a lot for the link and sorry for the late answer! As stated in my previous email, this is not going to work on our side of things as our security process prohibits us from modifying the Original ISO. Not that I CAN'T do it as I obviously have the hand on the whole image creation, just that if I'm not respecting the workflow those images won't pass the qualification gate. What really astonish me is that KVM is CDRom IDE HW Bus aware and able to mount multiple of them for a same instance, Nova itself knows about those specific HW bus too as you can actually specify it on the image metadata, what's really missing in my process for now is the ability to let nova spawn a VM with both ISO and VIRTIO drivers as CDRom devices. I'm really wondering why we can't specify any additional HW resources to nova at spawn time (from Horizon and CLI) except using native nova client such as instructed in here: https://access.redhat.com/solutions/1225473 or did I miss something? Thanks a lot for your answer! Le mar. 30 nov. 2021 ? 00:13, Patryk Jakuszew a ?crit : > On Tue, 30 Nov 2021 at 01:11, Ga?l THEROND > wrote: > > > > Starting from an unaltered Microsoft originated ISO image is a mandatory > requirement for this project (Because of security constraints that I can?t > have any impact on). > > > > Does that mean you cannot alter the original image? There are methods > for inserting the virtio drivers into the installation media, but that > will require generating a new installer ISO out of the modified files. > > This article seems to be describing the procedure correctly: > > https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e000000bt28CAA > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Dec 2 13:15:21 2021 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 2 Dec 2021 08:15:21 -0500 Subject: cpu pinning In-Reply-To: References: Message-ID: Did you try hw:numa_nodes=2 ? Sent from my iPhone > On Dec 1, 2021, at 10:30 PM, open infra wrote: > > hw:numa_nodes='1' -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.bryant at canonical.com Thu Dec 2 13:25:16 2021 From: corey.bryant at canonical.com (Corey Bryant) Date: Thu, 2 Dec 2021 08:25:16 -0500 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

<50abb4f5-af13-435c-87c9-1c14d74dcfb2@www.fastmail.com>

Message-ID: On Wed, Dec 1, 2021 at 4:34 PM Clark Boylan wrote: > > > >> > >> If we want to be bold and try an experiment, we could also reduce > testing of the python versions to oldest and newest supported python > versions. For example python3.6 and python3.9 during Yoga. Don't worry > about python3.7 and python3.8 as it is likely they will continue to > function as long as 3.6 and 3.9 are happy. This would reduce the size of > the testing matrix. We can always reevaluate if problems for 3.7 and 3.8 > occur. > >> > > > > The issue here I think is trying to align on a default LTS distro > > python. CS8,18.04 is 3.6, Debian Buster is 3.7, 20.04 is 3.8 and CS9 > > will be 3.9. Personally I think 3.6/3.9 is sufficient because for the > > projects I contribute to this covers my cases. But this would exclude > > the 3.8 on 20.04. Would this be a problem for Ubuntu's UCA? > > Ubuntu 20.04 includes a python 3.9. I don't know how that would impact the > UCA or Ubuntu's packaging though. That said I have a strong suspicion that > if OpenStack runs on 3.6 and 3.9 that it should just work on 3.8 as well. > And as I mentioned if we prove that wrong through experience we can always > fix 3.8 and go back to explicitly testing it. I don't think this particular > change is super critical, but I know some people were concerned about the > number of pythons that would need testing. > > > Ubuntu will be supporting python3.8 (on 20.04) and python3.10 (on 22.04) for Yoga by default. Once python 3.10.1 is released, it will be backported to 20.04, so I was hoping to add non-voting py310 unit tests upstream. Tthoughts? We did that in the past, I forget what release. Python3.9 testing is probably good enough coverage for Python3.8. Generally testing with the min and max python versions seems sensible, although the gap feels like it's getting wider than it was in the past, likely due to python release cadence. Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Thu Dec 2 14:16:14 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 02 Dec 2021 14:16:14 +0000 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

<50abb4f5-af13-435c-87c9-1c14d74dcfb2@www.fastmail.com>

Message-ID: <95d04b19475514d1132720ee1fc6064152b31710.camel@redhat.com> On Thu, 2021-12-02 at 08:25 -0500, Corey Bryant wrote: > On Wed, Dec 1, 2021 at 4:34 PM Clark Boylan wrote: > > > > > > > > > > > > > > > If we want to be bold and try an experiment, we could also reduce > > testing of the python versions to oldest and newest supported python > > versions. For example python3.6 and python3.9 during Yoga. Don't worry > > about python3.7 and python3.8 as it is likely they will continue to > > function as long as 3.6 and 3.9 are happy. This would reduce the size of > > the testing matrix. We can always reevaluate if problems for 3.7 and 3.8 > > occur. > > > > > > > > > > The issue here I think is trying to align on a default LTS distro > > > python. CS8,18.04 is 3.6, Debian Buster is 3.7, 20.04 is 3.8 and CS9 > > > will be 3.9. Personally I think 3.6/3.9 is sufficient because for the > > > projects I contribute to this covers my cases. But this would exclude > > > the 3.8 on 20.04. Would this be a problem for Ubuntu's UCA? > > > > Ubuntu 20.04 includes a python 3.9. I don't know how that would impact the > > UCA or Ubuntu's packaging though. That said I have a strong suspicion that > > if OpenStack runs on 3.6 and 3.9 that it should just work on 3.8 as well. > > And as I mentioned if we prove that wrong through experience we can always > > fix 3.8 and go back to explicitly testing it. I don't think this particular > > change is super critical, but I know some people were concerned about the > > number of pythons that would need testing. > > > > > > > Ubuntu will be supporting python3.8 (on 20.04) and python3.10 (on 22.04) > for Yoga by default. Once python 3.10.1 is released, it will be backported > to 20.04, so I was hoping to add non-voting py310 unit tests upstream. > Tthoughts? We did that in the past, I forget what release. i think that likely would be a good idea. i know eventlets are currently adding inital 3.10 support and have had to adapt to some changes sicne py3.6 by increasing the min version of some of there deps like dns python getting a head up early and ensuring we can get our upper-constraits in order i think woudl help make that smother. https://github.com/eventlet/eventlet/pull/715 > > Python3.9 testing is probably good enough coverage for Python3.8. Generally > testing with the min and max python versions seems sensible, although the > gap feels like it's getting wider than it was in the past, likely due to > python release cadence. ya it is wider then in the past for yoga we will effectlyve need to support 3.6, 3.7, 3.8, and 3.9 during development and then 3.10 once ubuntu 22.04 release. long term supporting 5 python version i dont think is sutainable so if we can reduce that to 3.8 3.9 and 3.10 for Z i think that is what we should aim for. we might event want to aim for 3.9 and 3.10 only if the distro support matrix makes sense. suse is perhaps the only distro that may not supprot 3.9+ ? and they nolonger ship an openstack distro so perhaps we coudl limit to 3.9+ in z > > Corey From gmann at ghanshyammann.com Thu Dec 2 15:01:52 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 02 Dec 2021 09:01:52 -0600 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References:

<20211126143019.2o7rycs44ycnkgez@yuggoth.org> <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

<50abb4f5-af13-435c-87c9-1c14d74dcfb2@www.fastmail.com>

Message-ID: <17d7baa83ad.10b8913d2240727.1175999501627088346@ghanshyammann.com> ---- On Thu, 02 Dec 2021 07:25:16 -0600 Corey Bryant wrote ---- > > > On Wed, Dec 1, 2021 at 4:34 PM Clark Boylan wrote: > > >> > >> If we want to be bold and try an experiment, we could also reduce testing of the python versions to oldest and newest supported python versions. For example python3.6 and python3.9 during Yoga. Don't worry about python3.7 and python3.8 as it is likely they will continue to function as long as 3.6 and 3.9 are happy. This would reduce the size of the testing matrix. We can always reevaluate if problems for 3.7 and 3.8 occur. > >> > > > > The issue here I think is trying to align on a default LTS distro > > python. CS8,18.04 is 3.6, Debian Buster is 3.7, 20.04 is 3.8 and CS9 > > will be 3.9. Personally I think 3.6/3.9 is sufficient because for the > > projects I contribute to this covers my cases. But this would exclude > > the 3.8 on 20.04. Would this be a problem for Ubuntu's UCA? > > Ubuntu 20.04 includes a python 3.9. I don't know how that would impact the UCA or Ubuntu's packaging though. That said I have a strong suspicion that if OpenStack runs on 3.6 and 3.9 that it should just work on 3.8 as well. And as I mentioned if we prove that wrong through experience we can always fix 3.8 and go back to explicitly testing it. I don't think this particular change is super critical, but I know some people were concerned about the number of pythons that would need testing. > > > Ubuntu will be supporting python3.8 (on 20.04) and python3.10 (on 22.04) for Yoga by default. Once python 3.10.1 is released, it will be backported to 20.04, so I was hoping to add non-voting py310 unit tests upstream. Tthoughts? We did that in the past, I forget what release. Yeah, adding 3.10 as non-voting is a good idea like we did for py3.9. Anyways TC is going to discuss these in today's TC meeting, please join us there to conclude things. -gmann > Python3.9 testing is probably good enough coverage for Python3.8. Generally testing with the min and max python versions seems sensible, although the gap feels like it's getting wider than it was in the past, likely due to python release cadence. > > Corey From openinfradn at gmail.com Thu Dec 2 15:03:01 2021 From: openinfradn at gmail.com (open infra) Date: Thu, 2 Dec 2021 20:33:01 +0530 Subject: cpu pinning In-Reply-To: References:

Message-ID: On Thu, Dec 2, 2021 at 6:45 PM Satish Patel wrote: > Did you try hw:numa_nodes=2 ? > Yes, I tried but I am getting the same error "No valid host was found. There are not enough hosts available." hw:cpu_cores='2', hw:cpu_policy='dedicated', hw:cpu_sockets='1', hw:cpu_threads='2', hw:numa_nodes='2' > > Sent from my iPhone > > On Dec 1, 2021, at 10:30 PM, open infra wrote: > > hw:numa_nodes='1' > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openinfradn at gmail.com Thu Dec 2 15:06:47 2021 From: openinfradn at gmail.com (open infra) Date: Thu, 2 Dec 2021 20:36:47 +0530 Subject: cpu pinning In-Reply-To: References:

Message-ID: I have only one worker and I hope it won't be an issue. On Thu, Dec 2, 2021 at 8:33 PM open infra wrote: > > > On Thu, Dec 2, 2021 at 6:45 PM Satish Patel wrote: > >> Did you try hw:numa_nodes=2 ? >> > > Yes, I tried but I am getting the same error "No valid host was found. > There are not enough hosts available." > > hw:cpu_cores='2', hw:cpu_policy='dedicated', hw:cpu_sockets='1', > hw:cpu_threads='2', hw:numa_nodes='2' > > > >> >> Sent from my iPhone >> >> On Dec 1, 2021, at 10:30 PM, open infra wrote: >> >> hw:numa_nodes='1' >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Thu Dec 2 15:46:18 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 02 Dec 2021 15:46:18 +0000 Subject: cpu pinning In-Reply-To: References: Message-ID: On Thu, 2021-12-02 at 08:58 +0530, open infra wrote: > Hi, > > I have created a flavor with following properties and created an instance. > Instance failed with the error "No valid host was found. There are not > enough hosts available." > When I set the cpu policy as 'shared' I can create the instance. The host > machine has two numa nodes and a total of 128 vcpu. > I can not figure out what's missing here. i suspect the issue is not with the flavor but with yoru host configurtion. you likely need to defience cpu_dedicated_set and cpu_shared_set in the nova.conf we do not support mixing pinned and floating cpus on the same host unless you partion the cpu pool using cpu_dedicated_set and cpu_shared_set. as of train cpu_dedicated_set replaced vcpu_pin_set as the supported way to report the pool of cpus to be used for pinned vms to placment. if you do "openstack resource provider inventory show " it should detail the avaiabel pcpu and vcpu inventories. when you use hw:cpu_policy='dedicated' it will claim PCPUs not VCPUs in placment. That is likely the issue you are encountering. by default we have a fallback query to make this work while you are upgrading https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_fallback_pcpu_query which we should be disabling by default soon. but i suspect that is likely why you are getting the no valid host. to debug this properly you should enable debug logging on the nova schduler and then confirm if you got host back form placment and then if the numa toplogy filter is rejectign the host or not. without the schduler debug logs for the instance creation we cannt really help more then this since we do not have the info required. > > controller-1:~$ openstack flavor show dn.large -c properties > > +------------+--------------------------------------------------------------------------------------------------------+ > > > Field | Value > | > > +------------+--------------------------------------------------------------------------------------------------------+ > > > properties | hw:cpu_cores='2', hw:cpu_policy='dedicated', > hw:cpu_sockets='1', hw:cpu_threads='2', hw:numa_nodes='1' | > > +------------+--------------------------------------------------------------------------------------------------------+ > > controller-1:~$ openstack hypervisor stats show > > +----------------------+--------+ > > > Field | Value | > > +----------------------+--------+ > > > count | 1 | > > > current_workload | 0 | > > > disk_available_least | 187 | > > > free_disk_gb | 199 | > > > free_ram_mb | 308787 | > > > local_gb | 219 | > > > local_gb_used | 20 | > > > memory_mb | 515443 | > > > memory_mb_used | 206656 | > > > running_vms | 7 | > > > vcpus | 126 | > > > vcpus_used | 49 | > > +----------------------+--------+ > > > > Regards, > > Danishka From fungi at yuggoth.org Thu Dec 2 15:51:08 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 2 Dec 2021 15:51:08 +0000 Subject: python_requires >= 3.8 during Yoga In-Reply-To: References: <17d5cdde95a.b95752d01381326.4462262438602968824@ghanshyammann.com>

<50abb4f5-af13-435c-87c9-1c14d74dcfb2@www.fastmail.com>

Message-ID: <20211202155107.3rg2t5yxsni5btvs@yuggoth.org> On 2021-12-02 08:25:16 -0500 (-0500), Corey Bryant wrote: [...] > Python3.9 testing is probably good enough coverage for Python3.8. > Generally testing with the min and max python versions seems > sensible, although the gap feels like it's getting wider than it > was in the past, likely due to python release cadence. It seems like we're primarily talking about unit tests here. There will still be a fair amount of direct 3.8 coverage as DevStack/Tempest/Grenade jobs use the default python3 on Focal unless we tell them not to. Same goes for docs builds, release jobs, et cetera. -- 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 Thu Dec 2 16:07:04 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 2 Dec 2021 11:07:04 -0500 Subject: [cinder] R-17 midcycle followup meeting poll Message-ID: We had some very useful discussions at yesterday's midcycle but ran out of time before we could discuss Gorka's new quotas proposals. It turns out that due to 8 December being a public holiday in many locations, the next Cinder meeting won't work for a video followup, so we'll hold a special half-hour video meeting on this topic next week. The meeting will be 1400-1430 UTC on one of Tuesday, Thursday, or Friday. If you have a preference, please express it in this poll: https://doodle.com/poll/mnddwtp99uu6hsuq The poll closes at 1300 UTC on Monday 6 December, and I'll announce the selected time shortly thereafter. cheers, brian From cdilorenzo at gmail.com Thu Dec 2 17:00:41 2021 From: cdilorenzo at gmail.com (Chris DiLorenzo) Date: Thu, 2 Dec 2021 12:00:41 -0500 Subject: [kolla[ Issue running masakari-hostmonitor Message-ID: Hello, I am running Kolla-12.0.0 with Openstack Victoria. I have mostly successfully deployed masakari. The instance monitoring works, I can set up segments in Horizon and via CLI. But I can't get masakari-hostmonitor to start: 2021-12-02 16:50:44.999 7 INFO oslo.privsep.daemon [-] Running privsep helper: ['sudo', 'privsep-helper', '--config-file', '/etc/masakari-monitors/masakari -monitors.conf', '--privsep_context', 'masakarimonitors.privsep.monitors_priv', '--privsep_sock_path', '/tmp/tmpf_65hc7m/privsep.sock'] 2021-12-02 16:50:44.892 261 INFO oslo.privsep.daemon [-] privsep daemon starting 2021-12-02 16:50:44.898 261 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0 2021-12-02 16:50:44.902 261 ERROR oslo.privsep.daemon [-] [Errno 1] Operation not permitted Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 593, in helper_main Daemon(channel, context).run() File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 403, in run self._drop_privs() File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 439, in _drop_privs capabilities.drop_all_caps_except(self.caps, self.caps, []) File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/capabilities.py", line 156, in drop_all_caps_except raise OSError(errno, os.strerror(errno)) PermissionError: [Errno 1] Operation not permitted 2021-12-02 16:50:45.001 7 DEBUG oslo_privsep.comm [-] EOF on privsep read channel _reader_main /var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep /comm.py:149 2021-12-02 16:50:45.475 7 WARNING oslo.privsep.daemon [-] privsep log: [Errno 1] Operation not permitted 2021-12-02 16:50:45.565 7 INFO oslo.privsep.daemon [-] Spawned new privsep daemon via rootwrap 2021-12-02 16:50:45.565 7 DEBUG oslo.privsep.daemon [-] Accepted privsep connection to /tmp/tmpf_65hc7m/privsep.sock __init__ /var/lib/kolla/venv/lib/pytho n3.8/site-packages/oslo_privsep/daemon.py:371 2021-12-02 16:50:45.467 267 INFO oslo.privsep.daemon [-] privsep daemon starting 2021-12-02 16:50:45.471 267 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0 2021-12-02 16:50:45.474 267 ERROR oslo.privsep.daemon [-] [Errno 1] Operation not permitted Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 593, in helper_main Daemon(channel, context).run() File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 403, in run self._drop_privs() File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 439, in _drop_privs capabilities.drop_all_caps_except(self.caps, self.caps, []) File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/capabilities.py", line 156, in drop_all_caps_except raise OSError(errno, os.strerror(errno)) PermissionError: [Errno 1] Operation not permitted sudoers in the container appears to be set up correctly. Thanks Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Dec 2 19:28:08 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 2 Dec 2021 20:28:08 +0100 Subject: [kolla[ Issue running masakari-hostmonitor In-Reply-To: References: Message-ID: Hi Chris, as for the issue itself - check if the container is running privileged (it should). As for the other details - Kolla-Ansible 12.x is for Wallaby, not Victoria, that could be causing issues. 12.0.0 is not the latest release for Wallaby either (12.2.0 is for today). Fixing these might help with the other issue. -yoctozepto On Thu, 2 Dec 2021 at 18:08, Chris DiLorenzo wrote: > > Hello, > > I am running Kolla-12.0.0 with Openstack Victoria. I have mostly successfully deployed masakari. The instance monitoring works, I can set up segments in Horizon and via CLI. But I can't get masakari-hostmonitor to start: > > 2021-12-02 16:50:44.999 7 INFO oslo.privsep.daemon [-] Running privsep helper: ['sudo', 'privsep-helper', '--config-file', '/etc/masakari-monitors/masakari > -monitors.conf', '--privsep_context', 'masakarimonitors.privsep.monitors_priv', '--privsep_sock_path', '/tmp/tmpf_65hc7m/privsep.sock'] > 2021-12-02 16:50:44.892 261 INFO oslo.privsep.daemon [-] privsep daemon starting > 2021-12-02 16:50:44.898 261 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0 > 2021-12-02 16:50:44.902 261 ERROR oslo.privsep.daemon [-] [Errno 1] Operation not permitted > Traceback (most recent call last): > File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 593, in helper_main > Daemon(channel, context).run() > File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 403, in run > self._drop_privs() > File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 439, in _drop_privs > capabilities.drop_all_caps_except(self.caps, self.caps, []) > File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/capabilities.py", line 156, in drop_all_caps_except > raise OSError(errno, os.strerror(errno)) > PermissionError: [Errno 1] Operation not permitted > 2021-12-02 16:50:45.001 7 DEBUG oslo_privsep.comm [-] EOF on privsep read channel _reader_main /var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep > /comm.py:149 > 2021-12-02 16:50:45.475 7 WARNING oslo.privsep.daemon [-] privsep log: [Errno 1] Operation not permitted > 2021-12-02 16:50:45.565 7 INFO oslo.privsep.daemon [-] Spawned new privsep daemon via rootwrap > 2021-12-02 16:50:45.565 7 DEBUG oslo.privsep.daemon [-] Accepted privsep connection to /tmp/tmpf_65hc7m/privsep.sock __init__ /var/lib/kolla/venv/lib/pytho > n3.8/site-packages/oslo_privsep/daemon.py:371 > 2021-12-02 16:50:45.467 267 INFO oslo.privsep.daemon [-] privsep daemon starting > 2021-12-02 16:50:45.471 267 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0 > 2021-12-02 16:50:45.474 267 ERROR oslo.privsep.daemon [-] [Errno 1] Operation not permitted > Traceback (most recent call last): > File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 593, in helper_main > Daemon(channel, context).run() > File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 403, in run > self._drop_privs() > File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", line 439, in _drop_privs > capabilities.drop_all_caps_except(self.caps, self.caps, []) > File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/capabilities.py", line 156, in drop_all_caps_except > raise OSError(errno, os.strerror(errno)) > PermissionError: [Errno 1] Operation not permitted > > sudoers in the container appears to be set up correctly. > > Thanks > Chris From katonalala at gmail.com Thu Dec 2 19:40:22 2021 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 2 Dec 2021 20:40:22 +0100 Subject: [neutron] Drivers meeting agenda - 03.12.2021 Message-ID: Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. I would like to discuss one bug which I feel is more an RFE: * https://bugs.launchpad.net/neutron/+bug/1952867 : [ml2][ovs] allow multiple physical networks map to one physical ovs bridge As physnet-bridge mapping is deep in Neutron I feel that a discussion is necessary to have a common understanding of the possible benefits and pitfalls of such shange. I wrote to Liu to ask him to join, but I'm not sure if he can participate. We have one more "On Demand" topic from Rodolfo: * https://review.opendev.org/c/openstack/python-openstackclient/+/819627/1: To deprecate "force" behaviour in OSC "quota" commands. This is currently the default behaviour in Neutron; what is proposed in this patch is to move Neutron to, by default, check the quota limits and use "--force" parameter to commit the quota limits without any check. [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 cdilorenzo at gmail.com Thu Dec 2 20:17:56 2021 From: cdilorenzo at gmail.com (Chris DiLorenzo) Date: Thu, 2 Dec 2021 15:17:56 -0500 Subject: [kolla[ Issue running masakari-hostmonitor In-Reply-To: References:

Message-ID: It's not running it privileged mode: ubuntu at control001-poc:~$ docker inspect --format='{{.HostConfig.Privileged}}' masakari_hostmonitor false The config in ansible/roles/masakari/defaults/main.yml looks like this: masakari-hostmonitor: container_name: masakari_hostmonitor group: masakari-hostmonitor enabled: true ipc_mode: host image: "{{ masakari_monitors_image_full }}" volumes: "{{ masakari_hostmonitor_default_volumes + masakari_hostmonitor_extra_volumes }}" dimensions: "{{ masakari_hostmonitor_dimensions }}" The reason I am running 12.0.0 is that the hostmonitor code isn't in 11.x Thanks, Chris On Thu, Dec 2, 2021 at 2:28 PM Rados?aw Piliszek < radoslaw.piliszek at gmail.com> wrote: > Hi Chris, > > as for the issue itself - check if the container is running privileged > (it should). > > As for the other details - Kolla-Ansible 12.x is for Wallaby, not > Victoria, that could be causing issues. > 12.0.0 is not the latest release for Wallaby either (12.2.0 is for today). > Fixing these might help with the other issue. > > -yoctozepto > > On Thu, 2 Dec 2021 at 18:08, Chris DiLorenzo wrote: > > > > Hello, > > > > I am running Kolla-12.0.0 with Openstack Victoria. I have mostly > successfully deployed masakari. The instance monitoring works, I can set > up segments in Horizon and via CLI. But I can't get masakari-hostmonitor > to start: > > > > 2021-12-02 16:50:44.999 7 INFO oslo.privsep.daemon [-] Running privsep > helper: ['sudo', 'privsep-helper', '--config-file', > '/etc/masakari-monitors/masakari > > -monitors.conf', '--privsep_context', > 'masakarimonitors.privsep.monitors_priv', '--privsep_sock_path', > '/tmp/tmpf_65hc7m/privsep.sock'] > > 2021-12-02 16:50:44.892 261 INFO oslo.privsep.daemon [-] privsep daemon > starting > > 2021-12-02 16:50:44.898 261 INFO oslo.privsep.daemon [-] privsep process > running with uid/gid: 0/0 > > 2021-12-02 16:50:44.902 261 ERROR oslo.privsep.daemon [-] [Errno 1] > Operation not permitted > > Traceback (most recent call last): > > File > "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", > line 593, in helper_main > > Daemon(channel, context).run() > > File > "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", > line 403, in run > > self._drop_privs() > > File > "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", > line 439, in _drop_privs > > capabilities.drop_all_caps_except(self.caps, self.caps, []) > > File > "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/capabilities.py", > line 156, in drop_all_caps_except > > raise OSError(errno, os.strerror(errno)) > > PermissionError: [Errno 1] Operation not permitted > > 2021-12-02 16:50:45.001 7 DEBUG oslo_privsep.comm [-] EOF on privsep > read channel _reader_main > /var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep > > /comm.py:149 > > 2021-12-02 16:50:45.475 7 WARNING oslo.privsep.daemon [-] privsep log: > [Errno 1] Operation not permitted > > 2021-12-02 16:50:45.565 7 INFO oslo.privsep.daemon [-] Spawned new > privsep daemon via rootwrap > > 2021-12-02 16:50:45.565 7 DEBUG oslo.privsep.daemon [-] Accepted privsep > connection to /tmp/tmpf_65hc7m/privsep.sock __init__ > /var/lib/kolla/venv/lib/pytho > > n3.8/site-packages/oslo_privsep/daemon.py:371 > > 2021-12-02 16:50:45.467 267 INFO oslo.privsep.daemon [-] privsep daemon > starting > > 2021-12-02 16:50:45.471 267 INFO oslo.privsep.daemon [-] privsep process > running with uid/gid: 0/0 > > 2021-12-02 16:50:45.474 267 ERROR oslo.privsep.daemon [-] [Errno 1] > Operation not permitted > > Traceback (most recent call last): > > File > "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", > line 593, in helper_main > > Daemon(channel, context).run() > > File > "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", > line 403, in run > > self._drop_privs() > > File > "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/daemon.py", > line 439, in _drop_privs > > capabilities.drop_all_caps_except(self.caps, self.caps, []) > > File > "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_privsep/capabilities.py", > line 156, in drop_all_caps_except > > raise OSError(errno, os.strerror(errno)) > > PermissionError: [Errno 1] Operation not permitted > > > > sudoers in the container appears to be set up correctly. > > > > Thanks > > Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: