- openstack-discuss - lists.openstack.org

Magnum metrics-server not working
by Oliver Weinmann 05 May '22

05 May '22

Hi, Is the metrics-server broken by default in magnum? I tried for several hours to get it running, but running kubectl top nodes fails. Message: failing or missing response from https://10.100.2.4:8443/apis/metrics.k8s.io/v1beta1: Get "https://10.100.2.4:8443/apis/metrics.k8s.io/v1beta1": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) I also googled a lot but only found similar issues for k8s clusters not deployed via magnum. I remembered from my other cluster that I had to enable enable-aggregator-routing=true in kupe-apiserver and --kubelet-insecure-tls for the metrics-server. But this also doesn’t help. Any help would be highly appreciated. Best regards, Oliver

2 3

RE: Data Center Survival in case of Disaster / HW Failure in DC
by CHALANSONNET Stéphane (Acoss) 05 May '22

05 May '22

Hello, First Openstack isnt VMware.Crtiticals applications need to be design with a multiples regions/AZ aware. Best way was two regions , 2 contrôle plane (keystone , Galera cluster on both (not the same) 2 storage system and application spitted on both is the best pratice 😉 You can do also with two AZ but the control plane is share between two AZ (galezra cluster and RabbitMq ) If you are trying to do the same thing as a streched VMware Cluster on a dual-site it's complicated, i you have 3 sites (low latencies <1ms) you can ! 1.In case of any Sudden Hardware failure of one or more controller node OR Compute node OR Storage Node what will be the immediate redundant recovery setup need to be employed ? => You need to splt control plane throught multiples AZ (3 is the best for Galera cluster and RabbitMQ , 2 if you have HA VMware) => Network compute work with keepalived so also need to split them on two AZ/region, you need . Dhcp , Metadata services are also redundancy on multiples network node => compute : HA OpenStack (like VMware HA) seems to work since Wallaby with Masakari . Actually you need to do the job by yourself if you need to failover instances. The storage is also the bggest problem . You need a streched storage that work with Cinder : Ceph can do the job but you also need three site (quorum on monitor need 2 node alives).Netapp solution seems to work well (trident NFS) 2. In case H/W failure our recovery need to as soon as possible. For example less than30 Minutes after the first failure occurs. Galera Cluster and RabbitMq need to be check first With two sites 30mn is really a big challenge, with 3 site it should good ! 3. Is there setup options like a hot standby or similar setups or what we need to employ ? 2 AZ , 2 storage system and application spitted on both is the best pratice 😉 4. To meet all RTO (< 30 Minutes down time ) and RPO(from the exact point of crash all applications and data must be consistent) . Regards, Stéphane Chalansonnet -----Message d'origine----- De : openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Envoyé : jeudi 5 mai 2022 11:56 À : openstack-discuss(a)lists.openstack.org Objet : openstack-discuss Digest, Vol 43, Issue 12 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Data Center Survival in case of Disaster / HW Failure in DC (KK CHN) 2. [nova][placement] Incomplete Consumers return negative value after upgrade (Jan Wasilewski) 3. Re: [all][tc][Release Management] Improvements in project governance (Slawek Kaplonski) ---------------------------------------------------------------------- Message: 1 Date: Thu, 5 May 2022 14:46:11 +0530 From: KK CHN <kkchn.in(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Subject: Data Center Survival in case of Disaster / HW Failure in DC Message-ID: <CAKgGyB_UmDG+TknDaYLGAuyOnxY8ipSF3qC4tS90T0zHzu6fZg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" List, We are having an old cloud setup with OpenStack Ussuri usng Debian OS, (Qemu KVM ). I know its very old and we can't upgrade to to new versions right now. The Deployment is as follows. A. 3 Controller in (cum compute nodes . VMs are running on controllers too..) in HA mode. B. 6 separate Compute nodes C. 3 separate Storage node with Ceph RBD Question is 1. In case of any Sudden Hardware failure of one or more controller node OR Compute node OR Storage Node what will be the immediate redundant recovery setup need to be employed ? 2. In case H/W failure our recovery need to as soon as possible. For example less than30 Minutes after the first failure occurs. 3. Is there setup options like a hot standby or similar setups or what we need to employ ? 4. To meet all RTO (< 30 Minutes down time ) and RPO(from the exact point of crash all applications and data must be consistent) . 5. Please share your thoughts for reliable crash/fault resistance configuration options in DC. We have a remote DR setup right now in a remote location. Also I would like to know if there is a recommended way to make the remote DR site Automatically up and run ? OR How to automate the service from DR site to meet exact RTO and RPO Any thoughts most welcom. Regards, Krish -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Message: 2 Date: Thu, 5 May 2022 11:31:16 +0200 From: Jan Wasilewski <finarffin(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Subject: [nova][placement] Incomplete Consumers return negative value after upgrade Message-ID: <CAN4DDNgG=i8tGpPQW2PUXVUp72T9r4CWDdxmfRg-bX8T1eE5AA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, after an upgrade from Stein to Train, I hit an issue with negative value during upgrade check for placement: # placement-status upgrade check+------------------------------------------------------------------+| Upgrade Check Results |+------------------------------------------------------------------+| Check: Missing Root Provider IDs || Result: Success || Details: None |+------------------------------------------------------------------+| Check: Incomplete Consumers || Result: Warning || Details: There are -20136 incomplete consumers table records for || existing allocations. Run the "placement-manage db || online_data_migrations" command. |+------------------------------------------------------------------+ Seems that negative value is a result that I get such values from tables consumer and allocations: mysql> select count(id), consumer_id from allocations group by consumer_id;...1035 rows in set (0.00 sec) mysql> select count(*) from consumers;+----------+| count(*) |+----------+| 21171 |+----------+1 row in set (0.04 sec) Unfortunately such warning cannot be solved by execution of suggested command( placement-manage db online_data_migrations) as it seems it adds records to consumers table - not to allocations, which looks like to be a problem here. I was following recommendations from this discussion: http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018536… but unfortunately it doesn't solve the issue(even not changing a negative value). I'm just wondering if I skipped something important and you can suggest some (obvious?) solution. Thank you in advance for your time and help. Best regards, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Message: 3 Date: Thu, 05 May 2022 11:55:32 +0200 From: Slawek Kaplonski <skaplons(a)redhat.com> To: openstack-discuss(a)lists.openstack.org Cc: El?d Ill?s <elod.illes(a)est.tech> Subject: Re: [all][tc][Release Management] Improvements in project governance Message-ID: <3198538.44csPzL39Z@p1> Content-Type: text/plain; charset="utf-8" Hi, On ?roda, 20 kwietnia 2022 13:19:10 CEST El?d Ill?s wrote: > Hi, > > At the very same time at the PTG we discussed this on the Release > Management session [1] as well. To release deliverables without > significant content is not ideal and this came up in previous > discussions as well. On the other hand unfortunately this is the most > feasible solution from release management team perspective especially > because the team is quite small (new members are welcome! feel free to > join the release management team! :)). > > To change to independent release model is an option for some cases, > but not for every project. (It is less clear for consumers what > version is/should be used for which series; Fixing problems that comes > up in specific stable branches, is not possible; testing the > deliverable against a specific stable branch constraints is not > possiblel; etc.) > > See some other comments inline. > > [1] https://etherpad.opendev.org/p/april2022-ptg-rel-mgt#L44 > > El?d > > On 2022. 04. 19. 18:01, Michael Johnson wrote: > > Comments inline. > > > > Michael > > > > On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski<skaplons(a)redhat.com> wrote: > >> Hi, > >> > >> > >> During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance. > >> > >> One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle. > >> > >> Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too? > > In the past this has created confusion in the community about if a > > project has been dropped/removed from OpenStack. That said, I think > > this is the point of the "independent" release classification. > Yes, exactly as Michael says. > >> If yes, should we then automatically propose change of the release model to the "independent" maybe? > > Personally, I would prefer to send an email to the discuss list > > proposing the switch to independent. Patches can sometimes get > > merged before everyone gets to give input. Especially since the > > patch would be proposed in the "releases" project and may not be on > > the team's dashboards. > The release process catches libraries only (that had no merged > change), so the number is not that huge, sending a mail seems to be a fair option. > > (The process says: "Evaluate any libraries that did not have any > change merged over the cycle to see if it is time to transition them > to the independent release model > <https://releases.openstack.org/reference/release_models.html#openstack-rela…>. > Note: client libraries (and other libraries strongly tied to another > deliverable) should generally follow their parent deliverable release > model, even if they did not have a lot of activity themselves).") > >> What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team. > > It seems like this would be a straight forward script to write given > > we already have tools to capture the list of changes included in a > > given release. > > There are a couple of good signals already for TC to catch inactive > projects, like the generated patches that are not merged, for example: > > https://review.opendev.org/q/topic:reno-yoga+is:open > https://review.opendev.org/q/topic:create-yoga+is:open > https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:ope > n > > (Note that in the past not merged patches caused issues and discussing > with the TC resulted a suggestion to force-merge them to avoid future > issues) > > >> Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all? > > In the past we have simply not released projects that are broken and > > don't have people actively working on fixing them. It has been a > > signal to the community that if they value the project they need to > > contribute to it. > > Yes, that's a fair point, too, maybe those broken deliverables should > not be released at all. I'm not sure, but that might cause another > issues for release management tooling, though... > > Besides, during our PTG session we came to the conclusion that we need > another step in our process: > * "propose DNM changes on every repository by RequirementsFreeze (5 > weeks before final release) to check that tests are still passing with > the current set of dependencies" > Hopefully this will catch broken things well in advance. > > >> [1]http://lists.openstack.org/pipermail/openstack-discuss/2022-Marc > >> h/027864.html > >> > >> > >> -- > >> > >> Slawek Kaplonski > >> > >> Principal Software Engineer > >> > >> Red Hat > Thx for all inputs in that topic so far. Here is my summary and conclusion of what was said in that thread: * we shouldn't try automatically switch such "inactive" projects to the independent model, and we should continue bumping versions of such projects every cycle as it makes many things easier, * Release Management team will test projects about 5 weeks before final release - that may help us find broken projects which then can be discussed and eventually marked as deprecated to not release broken code finally, * To check potentially inactive projects TC can: * finish script https://review.opendev.org/c/openstack/governance/+/810037[1] and use stats generate by that script to periodically check projects' health, * check projects with no merged generated patches, like: https://review.opendev.org/q/topic:reno-yoga+is:open[2] https://review.opendev.org/q/topic:create-yoga+is:open[3] https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open[4] Feel free to add/change anything in that summary if I missed or misunderstood anything there or if You have any idea about other improvements we can do in that area. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/openstack/governance/+/810037 [2] https://review.opendev.org/q/topic:reno-yoga+is:open [3] https://review.opendev.org/q/topic:create-yoga+is:open [4] https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 43, Issue 12 *************************************************

1 0

[all][tc][Release Management] Improvements in project governance
by Slawek Kaplonski 05 May '22

05 May '22

Hi, During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance. One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle. Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too? If yes, should we then automatically propose change of the release model to the "independent" maybe? What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team. Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all? [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.ht… -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.ht…

4 4

[Kolla-ansible][xena] how to deploy multiple cinder backends?
by wodel youchi 05 May '22

05 May '22

Hi, I want to deploy multiple cinder backends, ceph SSD pool for high performance VMS, ceph SAS pool for normal VMS and NFS share for small VMS and for cinder backup. Could that be done while deploying or it has to be done after the initial deployment? Could you assist me with some examples, sometimes the documentation is not that obvious to understand. Regards.

2 1

[sdk] creating a blank volume with image properties
by John Ratliff 05 May '22

05 May '22

We're standing up a second openstack cluster to do a leapfrog migration upgrade. We are using the same ceph storage backend. I need to create volumes in the new openstack cluster that use the underlying ceph rbd. Currently, we are creating a volume in the new openstack cluster, deleting the rbd created by openstack, and renaming the original rbd to match the new openstack mapping. This process loses the image properties from the original volumes. We are using virtio-scsi for the disk block device, and want to continue doing that in the new cluster. When we create the server using the new volume in the new openstack cluster, it reverts to using virtio-blk (/dev/vda). What can I do to keep using our image properties in the newly created volume? I thought I could just pass volume_image_metadata as an argument to create_volume(), but it doesn't work. I end up with an image that has no image metadata properties. import openstack openstack.enable_logging(debug=False) conn = openstack.connect(cloud="test") v = conn.create_volume( name="testvol", size=5, wait=True, bootable=True, volume_image_metadata={ "hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi", "hw_qemu_guest_agent": "yes", "os_require_quiesce": "yes", "hw_rng_model": "virtio", "image_id": "00000000-0000-0000-0000-000000000000", }, ) What can I do to create this openstack volume while preserving my original volume properties? Since we don't care about the image, I thought about creating a blank image that the volume could be based on with those properties, but I'm looking for suggestions. Thanks. --John

2 1

Re: [all][tc] Technical Committee next weekly meeting on May 5, 2022 at 1500 UTC
by Ghanshyam Mann 04 May '22

04 May '22

Hello Everyone, Below is the agenda for Tomorrow's TC IRC meeting schedule at 1500 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting == Agenda for tomorrow's TC meeting == * Roll call * Follow up on past action items * CFN overview from Jie Niu, China Mobile Research Institute (30 min) ** http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028345.ht… * 'tick', 'tock' release cadence (~30 min) ** Legal checks on using 'tick', 'tock' *** https://review.opendev.org/c/openstack/governance/+/840354 ** release notes discussion <rest of the agenda if time permits otherwise we will cover that in the next weekly meeting(12th May onwards)> * Join leadership meeting with Board of Directors * Gate health check ** Fixing Zuul config error in OpenStack *** https://etherpad.opendev.org/p/zuul-config-error-openstack * New ELK service dashboard: e-r service ** https://opensearch.logs.openstack.org/_dashboards/app/discover?security_ten… ** https://review.opendev.org/c/openstack/governance-sigs/+/835838 * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann

1 0

Retiring and shutting down the ethercalc.openstack.org service
by Clark Boylan 04 May '22

04 May '22

Hello, The https://ethercalc.openstack.org service has become problematic for several reasons: * Our configuration management for the service is still based on Puppet and needs to be modernized to continue running the service. * The service itself isn't well maintained. Its build system is apparently broken [0]. * The service does not capture a history of changes like etherpad, confusing users. * The service crashes semi frequently. The major known user of this service was the PTG planning process. We've talked to the folks that help organize and plan the PTG, and they think other tools (like PTGBot) can be used instead without major trouble. Considering all of this, the OpenDev team would like to retire and shutdown this service. The current plan is to keep the service up and running until the end of the month. Then on May 31, 2022 shut down the server hosting the service, snapshot this server, and finally delete it. Please back up any data you would like to preserve before May 31, 2022. [0] https://github.com/audreyt/ethercalc/pull/781 If you have any questions or concerns feel free to respond to this thread or reach out to the OpenDev team. Clark

3 2

[horizon] Yoga: Syntax of new Parameter SYSTEM_SCOPE_SERVICES in local_settings.py
by Crandale 04 May '22

04 May '22

Hi there, We have started to analyze Openstack Yoga a bit and there, one of the major new feature is the activation of scope based token for regular use in nova. While after some long lasting back and forth in configuring our role assignments and policies we could make it work on one of our test environments (Ubuntu) via Openstack SDK, however, we are still struggling with some system scoped API calls to nova from horizon. We have an admin user for the domain 'Default' who has set the role ‚admin' for 'system all': +-------+---------------+-------+---------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +-------+---------------+-------+---------+--------+--------+-----------+ | admin | admin@Default | | | | all | False | +-------+---------------+-------+---------+--------+--------+-----------+ We have configured in local_settings.py: SYSTEM_SCOPE_SERVICES = ['compute', 'image', 'volume', 'network‘] (Note: this config line has been reverse engineered from horizon source code as the syntax is nowhere possible to be found in the docs yet … - so: not sure if it is correct) Policy files are identical for horizon as for the services. For the user admin, we then get an additional field in the domain/project top line menu adding a ‚system scope‘ switch (this is what we understand how it should look like) and - when switching to system scope - also a system menu in the sidebar (also as expected). If we then go to System->Systeminformation to see the nova service list, we get an error ‚Unable to get nova services list‘, given reason is an error: 'Policy doesn’t allow os_compute_api:os-services:list to be performed (HTTP 403)‘. Informations for network and volume services are shown normally (here scoped tokens are not activated yet). Further analysis indicated that horizon is using still a project-scoped token and not a system-scoped one for these requests although ’system scope’ is active. Putting the same request from Openstack SDK with the same user admin results in $ openstack compute service list /usr/lib/python3/dist-packages/secretstorage/dhcrypto.py:15: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes /usr/lib/python3/dist-packages/secretstorage/util.py:19: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes +----+------------------+-------------+----------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +----+------------------+-------------+----------+---------+-------+----------------------------+ | 4 | nova-consoleauth | controller | nova | enabled | down | 2019-10-31T14:59:33.000000 | | 5 | nova-scheduler | controller | nova | enabled | up | 2022-05-04T08:52:48.000000 | | 6 | nova-conductor | controller | nova | enabled | up | 2022-05-04T08:52:42.000000 | | 12 | nova-compute | compute3 | Crandale | enabled | up | 2022-05-04T08:52:40.000000 | | 13 | nova-conductor | controller3 | nova | enabled | down | 2020-06-28T14:45:31.000000 | | 14 | nova-scheduler | controller3 | nova | enabled | down | 2020-06-28T14:45:24.000000 | +----+------------------+-------------+----------+---------+-------+—————————————--------------—+ Which indicates that role assignments to user admin are correct. The same command with -—debug also proves that a system scoped token is generated. Before I consider to open a bug towards Horizon: Could someone indicate to me whether the syntax of the config needs some adaptions to make it work or confirm that it is correct? Is there any other aspect we overlooked? I am looking forward to your reply Best regards Clemens

2 1

[api=sig][i18n][infra][tc] Cleaning up more defunct mailing lists
by Jeremy Stanley 04 May '22

04 May '22

A quick audit of the mailing lists we host at lists.openstack.org turned up the following 11 which have had no new posts for at least three years now: * openstack-api-consumers * openstack-de * openstack-el * openstack-i18n-fr * openstack-ir * openstack-personas * openstack-ru * openstack-sos * openstack-tw * openstack-vi * third-party-announce I'd like to clean them up by removing their list configurations, but leaving any public archives intact. Are there any objections? Should any of the above have future messages redirected to a different list (though since they haven't had any for years, that's probably unnecessary)? -- Jeremy Stanley

5 8

[cinder] Bug deputy report for week of 05-04-2022
by Sofia Enriquez 04 May '22

04 May '22

This is a bug report from 04-27-2022 to 05-04-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/os-brick/+bug/1961613 "Could not find any paths for the volume." after instance restart." Unassigned. Low - https://bugs.launchpad.net/cinder/+bug/1970768 "Temporary volume accepts deletion while it is used." Fix merged on master. - https://bugs.launchpad.net/cinder/+bug/1971483 "Temporary volume could be deleted with force." Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1970624 "Volume reset-state API validation state checking is incorrect." Fix proposed to master. Wishlist - https://bugs.launchpad.net/cinder/+bug/1971154 "rbd_store_chunk_size in megabytes is an unwanted limitation." Unassigned. Cheers -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

Openstack Wallaby Overcloud Deployment- ERROR
by Lokendra Rathour 03 May '22

03 May '22

Hi, Team getting this error during Openstack Wallaby Deployment: Please check once and suggest your valuable input. r/log/heat-1651554808.1084332.log 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud [-] Exception occured while running the command: ValueError: Failed to deploy: ERROR: HEAT-E99001 Service neutron is not available for resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog. Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/heat/common/context.py", line 416, in wrapped return func(self, ctx, *args, **kwargs) File "/usr/lib/python3.6/site-packages/heat/engine/service.py", line 1300, in validate_template validate_res_tmpl_only=True) File "/usr/lib/python3.6/site-packages/osprofiler/profiler.py", line 160, in wrapper result = f(*args, **kwargs) File "/usr/lib/python3.6/site-packages/heat/engine/stack.py", line 971, in validate result = res.validate_template() File "/usr/lib/python3.6/site-packages/heat/engine/resource.py", line 1882, in validate_template self.t.resource_type File "/usr/lib/python3.6/site-packages/heat/engine/resource.py", line 200, in _validate_service_availability raise ex heat.common.exception.ResourceTypeUnavailable: HEAT-E99001 Service neutron is not available for resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog. 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud Traceback (most recent call last): 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/v1/overcloud_deploy.py", line 394, in _try_overcloud_deploy_with_compat_yaml 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud deployment_options=deployment_options) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/v1/overcloud_deploy.py", line 164, in _heat_deploy 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud self.working_dir) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/workflows/parameters.py", line 134, in check_deprecated_parameters 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud valid=True) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/workflows/roles.py", line 49, in get_roles 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud files, env_files) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/utils.py", line 1829, in build_stack_data 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud result = orchestration_client.stacks.validate(**fields) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heatclient/v1/stacks.py", line 350, in validate 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud resp = self.client.post(url, **args) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heatclient/common/http.py", line 292, in post 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud return self.client_request("POST", url, **kwargs) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heatclient/common/http.py", line 282, in client_request 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud resp, body = self.json_request(method, url, **kwargs) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heatclient/common/http.py", line 271, in json_request 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud resp = self._http_request(url, method, **kwargs) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heatclient/common/http.py", line 234, in _http_request 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud raise exc.from_response(resp) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud heatclient.exc.HTTPBadRequest: ERROR: HEAT-E99001 Service neutron is not available for resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog. 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud Traceback (most recent call last): 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/common/context.py", line 416, in wrapped 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud return func(self, ctx, *args, **kwargs) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/engine/service.py", line 1300, in validate_template 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud validate_res_tmpl_only=True) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/osprofiler/profiler.py", line 160, in wrapper 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud result = f(*args, **kwargs) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/engine/stack.py", line 971, in validate 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud result = res.validate_template() 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/engine/resource.py", line 1882, in validate_template 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud self.t.resource_type 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/engine/resource.py", line 200, in _validate_service_availability 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud raise ex 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud heat.common.exception.ResourceTypeUnavailable: HEAT-E99001 Service neutron is not available for resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog. 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud During handling of the above exception, another exception occurred: 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud Traceback (most recent call last): 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", line 34, in run 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud super(Command, self).run(parsed_args) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", line 39, in run 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud return super(Command, self).run(parsed_args) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/cliff/command.py", line 185, in run 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud return_code = self.take_action(parsed_args) or 0 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/v1/overcloud_deploy.py", line 1226, in take_action 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud user_tht_root, created_env_files) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/v1/overcloud_deploy.py", line 357, in deploy_tripleo_heat_templates 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud deployment_options=deployment_options) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/v1/overcloud_deploy.py", line 397, in _try_overcloud_deploy_with_compat_yaml 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud raise ValueError(messages) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud ValueError: Failed to deploy: ERROR: HEAT-E99001 Service neutron is not available for resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog. 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud Traceback (most recent call last): 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/common/context.py", line 416, in wrapped 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud return func(self, ctx, *args, **kwargs) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/engine/service.py", line 1300, in validate_template 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud validate_res_tmpl_only=True) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/osprofiler/profiler.py", line 160, in wrapper 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud result = f(*args, **kwargs) 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/engine/stack.py", line 971, in validate 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud result = res.validate_template() 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/engine/resource.py", line 1882, in validate_template 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud self.t.resource_type 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/heat/engine/resource.py", line 200, in _validate_service_availability 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud raise ex 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud heat.common.exception.ResourceTypeUnavailable: HEAT-E99001 Service neutron is not available for resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog. 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.119 548199 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud 2022-05-03 10:44:41.157 548199 ERROR openstack [-] Failed to deploy: ERROR: HEAT-E99001 Service neutron is not available for resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog. Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/heat/common/context.py", line 416, in wrapped return func(self, ctx, *args, **kwargs) File "/usr/lib/python3.6/site-packages/heat/engine/service.py", line 1300, in validate_template validate_res_tmpl_only=True) File "/usr/lib/python3.6/site-packages/osprofiler/profiler.py", line 160, in wrapper result = f(*args, **kwargs) File "/usr/lib/python3.6/site-packages/heat/engine/stack.py", line 971, in validate result = res.validate_template() File "/usr/lib/python3.6/site-packages/heat/engine/resource.py", line 1882, in validate_template self.t.resource_type File "/usr/lib/python3.6/site-packages/heat/engine/resource.py", line 200, in _validate_service_availability raise ex heat.common.exception.ResourceTypeUnavailable: HEAT-E99001 Service neutron is not available for resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog. 2022-05-03 10:44:41.209 548199 INFO osc_lib.shell [-] END return value: 1

1 1

OSA log location/enabling
by Derek O keeffe 03 May '22

03 May '22

Hi all, So after a few days of getting our config files correct we have a working horizon dashboard. We have created a network and flavour so we could spin up an instance to test what we've done so far. The issue is the image upload fails with Unable to create the image. and when we attached to the glance container there are no log files. In the openstack_user_config file we didn't specify a syslog server so were under the impression it would store them on the container or infra node. Maybe they need to be implicitly enabled somewhere that we've missed as the neutron & openvswitch logs are in /var/log/ on the infra node. If anyone has any info as to viewing or enabling the logs that would be greatly appreciated. Regards,Derek

2 1

question -dashboard horizon
by mahdi n 03 May '22

03 May '22

I login-ed in horizon but in page project http://ip:8000/project show error that : You are not authorized to access this page please login screenshot how to solve this?

4 4

[neutron] Bug deputy April 25 to May 2
by Nurmatov Mamatisa 02 May '22

02 May '22

Hi, I was bug deputy last week. Below is the week summary. Undecided bugs needs further triage. One expired bug was restored. Details: Critical -------- - https://bugs.launchpad.net/neutron/+bug/1970679 - neutron-tempest-plugin-designate-scenario cross project job is failing on OVN - Confirmed - Related fix: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/839763 - Assigned to yatin High ---- - https://bugs.launchpad.net/neutron/+bug/1970216 - not sending Nova notification when using neutron API on mod_wsgi - In progress: https://review.opendev.org/c/openstack/neutron/+/839218 - Assigned to Krzysztof Tomaszewski - https://bugs.launchpad.net/neutron/+bug/1970606 - Live migration packet loss increasing as the number of security group rules increases - Confirmed - Unassigned - https://bugs.launchpad.net/neutron/+bug/1970759 - Race during removal of the network from DHCP agent - In progress: https://review.opendev.org/c/openstack/neutron/+/839779 - Assigned to Slawek Kaplonski Low --- - https://bugs.launchpad.net/neutron/+bug/1970944 - Refactor neutron-keepalived-state-change - In progress: https://review.opendev.org/c/openstack/neutron/+/836140 - Assigned to Rodolfo Alonso Undecided --------- - https://bugs.launchpad.net/neutron/+bug/1971050 - Nested KVM Networking Issue - New - https://bugs.launchpad.net/neutron/+bug/1970948 - [VPNAAS] No start possible without rootwrap - New Expired ------- - https://bugs.launchpad.net/neutron/+bug/1719806 - IPv4 subnets added when VM is already up on an IPv6 subnet on the same network, does not enable VM ports to get IPv4 address - New Best regards, Mamatisa Nurmatov Advanced Software Technology Lab / Cloud Technologies Research

1 0

[neutron] Team meeting 3. 5. cancelled
by Lajos Katona 02 May '22

02 May '22

Hi, Tomorrow (3. May.) it seems that a lot of people will be offline during the Neutron Team meeting, so let's cancel it for this week. See you at the meeting next week. Lajos Katona (lajoskatona)

1 0

[neutron] CI meeting 3.05 cancelled
by Slawek Kaplonski 02 May '22

02 May '22

Hi, Tomorrow I will not be able to chair our CI meeting. There is nothing urgent to discuss really so lets cancel meeting this week. See You on the meeting on May 10th. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[nova][placement] Zed 1st spec review day on May 10th 2022
by Sylvain Bauza 02 May '22

02 May '22

What is said above ^ Contributors, sharpen your pens and please be able to upload your spec in Gerrit for this day. Please try to look also at Gerrit during this day, and if you can do, please be around on #openstack-nova IRC channel [1] Reviewers, please try to be able to look at the specs for this day. In case you would prefer to discuss with the contributor, try to ping him or her by IRC. We will try to have a second spec review day around end of June but it would be better if we could at least accept some specs for the Zed release before :-) Thanks, -Sylvain [1] https://docs.openstack.org/contributors/common/irc.html

1 0

[tacker] Cancelling meeting this week
by Yasufumi Ogawa 01 May '22

01 May '22

Hi, Since most of us joining from Japan will be off Tuesday this week for a holiday, we will cancel the meeting. Thanks, Yasufumi

1 0

[all][tc] What's happening in Technical Committee: summary April 29th, 22: Reading: 5 min
by Ghanshyam Mann 29 Apr '22

29 Apr '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on April 28. Most of the meeting discussions are summarized in this email. Meeting full logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-04-21-15.00.html * Next TC weekly meeting will be on May 5 Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by May 4. We will cover CFN and tick-tock release notes topic there and if time permits then cover any othe topic. 2. What we completed this week: ========================= * Resolution to drop the lower constraints maintenance[2] * Remove TC Liaisons framework[3] * Retired openstack-helm-docs[4] 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[5], we have started the many items. Open Reviews ----------------- * Seven open reviews for ongoing activities[6]. Change OpenStack release naming policy proposal ----------------------------------------------------------- We discussed it it PTG, TC decided to drop the name from release name process and keping the numbers. Slaweq proposed it on gerrit[7] and on ML[8]. Discussion is in progress as there are some objection from foundation marketting team. Migration from old ELK service to new Dashboard ----------------------------------------------------------- You might have seen that Daniel email about the new dashboard[9] and login information, we encourage community members to use it and provide feedback if any. Dainel also investigation about the e-r instance. Consistent and Secure Default RBAC ------------------------------------------- We discussed about the heat mostly in Tuesday call but could not get any consensus. Notes are in etherpad[10] and will continue the discussion on Tuesday 3rd May 14:00 UTC [11], FIPs community-wide goal ------------------------------- Ade has proposed the new milestone for this goal work, please review those and give feedback if any[12]. 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[13]. Feel free to check and provide feedback. Zed cycle Leaderless projects ---------------------------------- No updates on this. Only Adjutant project is leaderless/maintainer-less. We will check Adjutant's situation again on ML and hope Braden will be ready with their company side permission[14]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[15]. Project updates ------------------- * Add the cinder-three-par charm to Openstack charms[16] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[17]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [18] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/838004 [3] https://review.opendev.org/c/openstack/governance/+/837891 [4] https://review.opendev.org/c/openstack/governance/+/839100 [5] https://etherpad.opendev.org/p/tc-zed-tracker [6] https://review.opendev.org/q/projects:openstack/governance+status:open [7] https://review.opendev.org/c/openstack/governance/+/839897 [8] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028354.ht… [9] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028346.ht… [10] https://etherpad.opendev.org/p/rbac-zed-ptg#L103 [11] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… [12] https://review.opendev.org/c/openstack/governance/+/838601 [13] https://review.opendev.org/c/openstack/governance/+/836888 [14] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.ht… [15] https://etherpad.opendev.org/p/zuul-config-error-openstack [16] https://review.opendev.org/c/openstack/governance/+/837781 [17] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [18] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[dev][infra][tact-sig] Retiring the status.openstack.org server
by Jeremy Stanley 29 Apr '22

29 Apr '22

With the recent retirement of the Elastic-Recheck and OpenStack-Health services, as well as Zuul long ago growing its own status dashboard, the only other thing still being served from the status.openstack.org site is a very broken and empty ReviewDay interface. I'm planning to take status.openstack.org offline at the end of this month (late next week), so wanted to give everyone a heads up that anything still served from that site right now (basically just a link to the Zuul status page for our openstack tenant) will be going away. If you want the Zuul status page for openstack, the proper URL is https://zuul.opendev.org/t/openstack/status or you can just go to the root of the site and click the "status" link in the openstack tenant row. (There's also a white-label zuul.openstack.org site but that's primarily maintained in order to avoid breaking old tools people may have hard-coded to use it.) -- Jeremy Stanley

1 1

Need information
by Gk Gk 29 Apr '22

29 Apr '22

Hi All, I need information about availability zones in nova. I tried googling but cant find enough information. My questions are , 1. Why is it that we have two concepts of aggregates and AZs ? Is one not enough ? Like exposing aggregates and creating flavors with extra specs to match ? Why do we need AZs also ? 2. Why is it that one node should only be a part of one AZ but not two ? whereas in the case of aggregates, it can overlap ? 3. Also why cant we expose only aggregates like AZs but block the compute member list to the users ? Doing this way will serve the purpose of AZ as well ? Why we dont want to expose aggregates as AZs ? Thanks Kumar

2 1

regarding custom role creation
by Adivya Singh 29 Apr '22

29 Apr '22

Hi Team, i want to create a custom role in openstack, with privilege being 1> to allow them to make image public 2> to modify/change the flavor how can i do this, I have openstack installed with XENA regards Adivya Singh

2 1

ERROR trust id
by Firas Dehech 29 Apr '22

29 Apr '22

Hi all, I am working on a project Openstack in linux ubuntu 20.04. I want to create a cluster hadoop with one master-node and three worker-nodes and i have a problem with a cluster that doesn't work. Status ERROR: Creating cluster failed for the following reason(s): Failed to create trust Error ID: ef5e8b0a-8e6d-4878-bebb-f37f4fa50a88, Failed to create trust Error ID: 43157255-86af-4773-96c1-a07ca7ac66ed. links: https://docs.openstack.org/devstack/latest/ File local.conf : [[local|localrc]] ADMIN_PASSWORD=secret DATABASE_PASSWORD=secret RABBIT_PASSWORD=secret SERVICE_PASSWORD=$ADMIN_PASSWORD HOST_IP=10.0.2.15 LOGFILE=$DEST/logs/stack.sh.log SWIFT_REPLICAS=1SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5 SWIFT_DATA_DIR=$DEST/data enable_plugin sahara https://opendev.org/openstack/sahara enable_plugin sahara-dashboard https://opendev.org/openstack/sahara-dashboard Can you guys advise me about these errors. Is there anything to worry about? Regards.

1 0

[neutron] Drivers meeting - Friday 29.4.2022 - cancelled
by Lajos Katona 28 Apr '22

28 Apr '22

Hi Neutron Drivers! Due to the lack of agenda, let's cancel tomorrow's drivers meeting. See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

撤回: [all] New CFN(Computing Force Network) SIG Proposal
by niujie 28 Apr '22

28 Apr '22

niujie 将撤回邮件“[all] New CFN(Computing Force Network) SIG Proposal ”。

5 12

[Openstack Triple0 Wallaby] Deployment error
by Lokendra Rathour 28 Apr '22

28 Apr '22

Hi Team, we tried OpenStack deployment using *Triple0 Wallaby.* while we were trying to deploy the setup Undercloud was deployed successfully. For the Overcloud Deployment: we generated the templates: Command: ./usr/share/openstack-tripleo-heat-templates/tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered_at_wallaby -n /home/stack/templates/network_data.yaml -r /home/stack/templates/roles_data.yaml and using the below command to deploy overcloud: openstack overcloud deploy --templates \ -n /home/stack/templates/network_data.yaml \ -r /home/stack/templates/roles_data.yaml \ -e /home/stack/templates/environment.yaml \ -e /home/stack/templates/environments/network-isolation.yaml \ -e /home/stack/templates/environments/network-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml \ -e /home/stack/templates/ironic-config.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \ -e /home/stack/containers-prepare-parameter.yaml after which it fails with error: 2022-04-27 12:34:00.801 607453 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud [-] Exception occured while running the command: ValueError: Failed to deploy: ERROR: HEAT-E99001 Service neutron is not available for* resource type OS::TripleO::Network::Ports::ControlPlaneVipPort, reason: neutron network endpoint is not in service catalog.* Traceback (most recent call last): we were able to deploy Triple0 Victoria/ Train /ussuri using the same approach. Please suggest any further changes needed to include in our setup. -Lokendra

1 1

ELK services moving to OpenSearch
by Daniel Pawlik 28 Apr '22

28 Apr '22

Hello, We would like to announce the new Elasticsearch service based on Opensearch. As it was earlier mentioned [1], the old service logstash.openstack.org is deprecated and will be decommissioned in the near future. Same as earlier, each Zuul CI job results will be sent to the Elasticsearch service. With the new CI log processing system [2], we decided to add more logs to be proceeded [3]. If some important files are missing, please let me know. To use this new service, please check out the documentation [4][5] or use the following credentials: url: https://opensearch.logs.openstack.org/_dashboards/app/discover?security_ten… username: openstack password: openstack tenant: global I would also like to take this opportunity to ask for help with the OpenStack ci-log-processing project [6] which is providing configuration of the Opensearch service as well as tools required to process CI logs and push them into the Opensearch service. Cheers, Dan [1] https://lists.openstack.org/pipermail/openstack-discuss/2021-May/022359.html [2] https://lists.openstack.org/pipermail/openstack-discuss/2022-February/02736… [3] https://opendev.org/openstack/ci-log-processing/src/branch/master/logscrape… [4] https://docs.openstack.org/project-team-guide/testing.html#checking-status-… [5] https://governance.openstack.org/sigs/tact-sig.html#opensearch [6] https://opendev.org/openstack/ci-log-processing

1 0

Nova support for multiple vGPUs?
by Sigurd Kristian Brinch 28 Apr '22

28 Apr '22

Hi, As far as I can tell, libvirt/KVM supports multiple vGPUs per VM (https://docs.nvidia.com/grid/14.0/grid-vgpu-release-notes-generic-linux-kvm…) but in OpenStack/Nova it is limited to one vGPU per VM (https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#configure-a-f…) Is there a reason for this limit? What would be needed to enable multiple vGPUs in Nova? BR Sigurd

3 4

[Browbeat]performance/load testing
by Vishwanath 27 Apr '22

27 Apr '22

Hello, I installed openstack using kolla-ansible, i would like to do load/performance testing, i came across below openstack page. https://docs.openstack.org/self-healing-sig/latest/testing/tools-list.html Browbeat looks like a perfect fit for what i want to do.I read browbeat documentation . Questions i have is: - as per the browbeat documentation, in order to install this we need to have openstack installation via tripleo (undercloud/overcloud) , does browbeat work with non triiplo openstack deployment? - I don’t have undercloud/overcloud setup. Regards Vish

1 0

Openstack Trove - Polling request timed out
by Manish Bharti 27 Apr '22

27 Apr '22

Dear Team, We are trying to deploy OpenStack environment for our application and while deploying trove service we are facing the below error(attached screenshot)- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/trove/common/utils.py", line 207, in wait_for_task return polling_task.wait() File "/usr/lib/python3/dist-packages/eventlet/event.py", line 125, in wait result = hub.switch() File "/usr/lib/python3/dist-packages/eventlet/hubs/hub.py", line 313, in switch return self.greenlet.switch() File "/usr/lib/python3/dist-packages/oslo_service/loopingcall.py", line 154, in _run_loop idle = idle_for_func(result, self._elapsed(watch)) File "/usr/lib/python3/dist-packages/oslo_service/loopingcall.py", line 349, in _idle_for raise LoopingCallTimeOut( oslo_service.loopingcall.LoopingCallTimeOut: Looping call timed out after 870.99 seconds During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/trove/taskmanager/models.py", line 434, in wait_for_instance utils.poll_until(self._service_is_active, File "/usr/lib/python3/dist-packages/trove/common/utils.py", line 223, in poll_until return wait_for_task(task) File "/usr/lib/python3/dist-packages/trove/common/utils.py", line 209, in wait_for_task raise exception.PollTimeOut trove.common.exception.PollTimeOut: Polling request timed out. Please help us on this issue. -- Thank you , Manish Bharti Jodhpur, Raj - 342001. Contact:8875033000

2 1

[all][tc] Technical Committee next weekly meeting on April 28, 2022 at 1500 UTC
by Ghanshyam Mann 27 Apr '22

27 Apr '22

Hello Everyone, Technical Committee's next weekly meeting is scheduled for April 28, 2022 at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, April 27, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[openstack-helm] gnocchi chart removal
by Gage Hugo 27 Apr '22

27 Apr '22

Hey team, One of the topics from the last few PTGs have been reducing the scope of openstack-helm by evaluating which charts were being used and which ones have not been actively maintained and one of those charts that has been discussed was gnocchi. Besides a change to tolerations that was applied to most of the charts in the repo, the gnocchi chart has not seen much activity and there wasn't any immediate interest in maintaining it, so the current plan is to remove it from the repo. If you are someone who is actively using the gnocchi chart and would be interested in helping to maintain it, please let me know!

1 0

[all][qa] Dropping centos-8-stream support and testing
by Ghanshyam Mann 27 Apr '22

27 Apr '22

Hello Everyone, As you know, in zed cycle we are targeting centos-9-stream in testing runtime[1] and dropping the py3.6 support. By dropping the py3.6 support means stop testing the py3.6 and require "python_requires = >=3.8" , For example nova - https://github.com/openstack/nova/blob/5f5551448dcfcde26095963e223f973b90e6… With that centos-8-stream jobs are failing 100% and in qa meeting we decided to drop the support in devstack[2]. Dropping support in devstack means: 1. we will stop testing it[3] 2. Drop support from stack.sh. By disabling centos-8-stream from the supported_distro by default[4] in stack.sh (you can enable it by running with force flag). 1st is done and patch to remove the centos-8-stream job is merged (along with in Tempest and nova). For 2nd one we will wait for 1 more week and will discuss to do in next QA meeting. Please start removing or replacing the c8s jobs with c9s in your projects. You can keep gerrit topic 'drop-c8s-testing' to know the overall status. [1] https://governance.openstack.org/tc/reference/runtimes/zed.html [2] https://meetings.opendev.org/meetings/qa/2022/qa.2022-04-26-15.00.log.html#… [3] https://review.opendev.org/q/topic:drop-c8s-testing [4] https://github.com/openstack/devstack/blob/48417ca241cacff8f4398910792489a5… -gmann

3 4

[cinder] Bug deputy report for week of 04-26-2022
by Sofia Enriquez 27 Apr '22

27 Apr '22

This is a bug report from 04-20-2022 to 04-26-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/os-brick/+bug/1969794 "backport of the fix for bug #1947370 make lock_path a required config option when prvisouls it was optional." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1969373 "Simultaneous volume creation with the same image in multi-attach mode returns error." Assigned to Rajat. - https://bugs.launchpad.net/cinder/+bug/1969531 "NetApp NFS Storage Migration between backends is Failing." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1969643 "RBD: Unable to delete a volume which has snapshot/volume children." Assigned to Sofia Enriquez and Eric Harney. No fix proposed to master yet. - https://bugs.launchpad.net/cinder/+bug/1969784 "[Pure Storage] Replicated array communication failure not handled correctly." Assigned to Simon Dodsley. No fix proposed to master yet. Low - https://bugs.launchpad.net/cinder/+bug/1967683 "Wrong property to look up remote address." Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1970237 "[RBD] Multiple full backups cannot be created from one snapshot." Assigned to liuhuajie. No patch proposed to master yet. - https://bugs.launchpad.net/cinder/+bug/1969913 "[Documentation] Migration in cinder, lvm-rbd example is not correct." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1966904 "Complex config formula evaluation causes RecursionError." Fix proposed to master. Wishlist - https://bugs.launchpad.net/cinder/+bug/1970208 "Rebranding. Dell EMC must be renamed to Dell." Assigned to Alexander Malashenko. Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1970115 " [Enhancement] No way to disable image conversion." Assigned to Rico Lin. No fix proposed to master yet. - https://bugs.launchpad.net/cinder/+bug/1970114 " [Enhancement] Image conversion with RBD is not efficient." Unassigned. No fix proposed to master yet. Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

RDO Yoga Released
by Amy Marrich 27 Apr '22

27 Apr '22

The RDO community is pleased to announce the general availability of the RDO build for OpenStack Yoga for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Yoga is the 25th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network: - For CentOS Stream 8 http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-yoga - For CentOS Stream 9 http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-yoga/ The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. Interesting things in the Yoga release include: - RDO Yoga is the first RDO version built and tested for CentOS Stream 9. - In order to ease transition from CentOS Stream 8, RDO Yoga is also built and tested for CentOS Stream 8. Note that next release of RDO will be available only for CentOS Stream 9. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/yoga/highlights.html TripleO in the RDO Yoga release: Since the Xena development cycle, TripleO follows the Independent release model <https://specs.openstack.org/openstack/tripleo-specs/specs/xena/tripleo-inde…> and will only maintain branches for selected OpenStack releases. In the case of Yoga, TripleO will not support the Yoga release. For TripleO users in RDO, this means that: - RDO Yoga will include packages for TripleO tested at OpenStack Yoga GA time. - Those packages will not be updated during the entire Yoga maintenance cycle. - RDO will not be able to included patches required to fix bugs in TripleO on RDO Yoga. - The lifecycle for the non-TripleO packages will follow the code merged and tested in upstream stable/yoga branches. - There will not be any TripleO Yoga container images built/pushed, so interested users will have to do their own container builds when deploying Yoga. You can find details about this on the RDO Webpage <https://www.rdoproject.org/documentation/tripleo-in-xena/> *Contributors* During the Yoga cycle, we saw the following new RDO contributors: - Adriano Vieira Petrich - Andrea Bolognani - Dariusz Smigiel - David Vallee Delisle - Douglas Viroel - Jakob Meng - Lucas Alvares Gomes - Luis Tomas Bolivar - T. Nichole Williams - Karolina Kula Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 40 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories: - Adriano Vieira Petrich - Alan Bishop - Alan Pevec - Alex Schultz - Alfredo Moralejo - Amy Marrich (spotz) - Andrea Bolognani - Chandan Kumar - Daniel Alvarez Sanchez - Dariusz Smigiel - David Vallee Delisle - Douglas Viroel - Emma Foley - Gaël Chamoulaud - Gregory Thiemonge - Harald - Jakob Meng - James Slagle - Jiri Podivin - Joel Capitao - Jon Schlueter - Julia Kreger - Kashyap Chamarthy - Lee Yarwood - Lon Hohberger - Lucas Alvares Gomes - Luigi Toscano - Luis Tomas Bolivar - Martin Kopec - mathieu bultel - Matthias Runge - Riccardo Pittau - Sergey - Stephen Finucane - Steve Baker - Takashi Kajinami - T. Nichole Williams - Tobias Urdin - Karolina Kula - User otherwiseguy - Yatin Karel *The Next Release Cycle* At the end of one release, focus shifts immediately to the next release i.e Zed. *Get Started* To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. *Get Help* The RDO Project has the users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC. IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel in Libera Chat network, and #tripleo on OFTC), however we have a more focused audience within the RDO venues. *Get Involved* To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and #tripleo on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

1 0

[magnum] Proposing Michal Nasiadka for core-reviewer
by Spyros Trigazis 27 Apr '22

27 Apr '22

Dear all, I would like to nominate Michal Nasiadka for core reviewer in the magnum project. Michal has been helping with reviews for the past cycles and proposed features and fixes regularly. He would be a great addition to the team. Cheers, Spyros

1 0

[cinder] This week's meeting (Today) will be in video+IRC
by Rajat Dhasmana 27 Apr '22

27 Apr '22

Hello Argonauts, This is a reminder email about this week's meeting i.e. Today (27 April) will be in video + IRC mode. The timings are same as regular cinder meeting i.e. 1400-1500 UTC. The meeting will be held in video[1] and IRC[2]. The reason to keep this in both ways is some people are more comfortable in written communication than verbal and vice versa so we can hold discussions in video or IRC as per author's wish. Also the roll call will happen on IRC and a summary will be given there as well so make sure you're connected to the IRC channel during the meeting. [1] connection info: https://bluejeans.com/556681290 [2] openstack-meeting-alt channel on IRC Thanks and regards Rajat Dhasmana

1 0

[openstack-ansible] Nominate Damian Dąbrowski for openstack-ansible core team
by Dmitriy Rabotyagov 26 Apr '22

26 Apr '22

Hi OSA Cores! I'm happy to nominate Damian Dąbrowski (damiandabrowski) to the core reviewers team. He has been doing a good job lately in reviewing incoming patches, helping out in IRC and participating in community activities, so I think he will be a good match for the Core Reviewers group. So I call for current Core Reviewers to support this nomination or raise objections to it until 22nd of April 2022. If no objections are raised we will add Damian to the team next week. -- Kind regards, Dmitriy Rabotyagov

5 5

[tc][all][ Zed Virtual PTG RBAC discussions Summary
by Ghanshyam Mann 26 Apr '22

26 Apr '22

Hello Everyone, I tried to attend the RBAC-related sessions on various projects[i] but I am sure I might have missed a few of them. I am summarizing the RBAC discussion on what open questions were from the project side and what we discussed in TC PTG. Feel free to append the discussion you had in your project or any query you want TC to solve. Current status: ------------------ * I have started this etherpad[ii] to track the status of this goal, please keep it up to date as you progress the work in your project. Open question: ------------------ 1. heat create_stack API calling the mixed scope APIs (for example create flavor and create server). what is best scope for heat API so that we do not have any security leak. We have not concluded the solution yet as we need the heat team also join the discussion and agree on that. But we have a few possible solutions listed below: ** Heat accepts stack API with system scope *** This means a stack with system resources would require a system admin role => Need to check with services relying on Heat ** Heat assigns a project-scope role to the requester during a processing stack operation and uses this project scope credential to manage project resources ** Heat starts accepting the new header accepting the extra token (say SYSTEM_TOKEN) and uses that to create/interact the system-level resource like create flavor. 2. How to isolate the host level attribute in GET APIs? (cinder and manila have the same issue). Cinder GET volume API response has the host information. One possible solution we discussed is to have a separate API to show the host information to the system user and the rest of the volume response to the project users only. This is similar to what we have in nova. Then we have a few questions from the Tacker side, where tacker create_vnf API internally call heat create_stack and they are planning to make create_vnf API for non-admin users. Direction on enabling the enforce scope by default ------------------------------------------------------------ As keystone, nova, and neutron are ready with the new RBAC, we wanted to enable the scope checks by default. But after seeing the lack of integration testing and the above mentioned open question (especially heat and any deployment project breaking) we decided to hold it. As the first step, we will migrate the tempest tests to the new RBAC and will enable the scope for these services in devstack. And based on the testing results we will decide on it. But after seeing the amount of work needed in Tempest and on the open question, I do not think we will be able to do it in the Zed cycle. Instead, we will target to enable the 'new defaults' by default. We ran out of time in TC and will continue the discuss these in policy popup meetings. I will push the schedule to Ml. [i] https://etherpad.opendev.org/p/rbac-zed-ptg [ii] https://etherpad.opendev.org/p/rbac-goal-tracking -gmann

2 2

[Triple0 on Centos Stream] Wallaby Overcloud Deployment Issue
by Lokendra Rathour 26 Apr '22

26 Apr '22

Hi Team, We were trying to install Openstack Wallaby Release on Centos Stream. As we were trying the overcloud deployment, getting this error: 2022-04-26 17:20:51.768 374850 INFO tripleoclient.heat_launcher [-] Skipping container image pull. 2022-04-26 17:20:51.776 374850 INFO tripleoclient.heat_launcher [-] Checking that database is up 2022-04-26 17:20:52.251 374850 INFO tripleoclient.heat_launcher [-] Checking that message bus (rabbitmq) is up Error: Source image rejected: Error reading signature from https://access.redhat.com/webassets/docker/content/sigstore/ubi8/pause@sha2…: status 403 (Forbidden) 2022-04-26 17:20:57.687 374850 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud [-] Exception occured while running the command: subprocess.CalledProcessError: Command '['sudo', 'podman', 'play', 'kube', '/home/stack/overcloud-deploy/overcloud/heat-launcher/heat-pod.yaml']' returned non-zero exit status 125. 2022-04-26 17:20:57.687 374850 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud Traceback (most recent call last): 2022-04-26 17:20:57.687 374850 ERROR tripleoclient.v1.overcloud_deploy.DeployOvercloud File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", line 34, in run Please suggest. -- ~ Lokendra

2 2

[Kolla-ansible][Xena] Error deploying Cloudkitty
by wodel youchi 26 Apr '22

26 Apr '22

Hi, I am trying to deploy Cloudkitty, but I get this error message : TASK [cloudkitty : Creating Cloudkitty influxdb database] > ****************************************************** > task path: > /home/deployer/kollavenv/xenavenv/share/kolla-ansible/ansible/roles/cloudkitty/tasks/bootstrap.yml:36 fatal: [192.168.1.5 -> 192.168.1.5]: FAILED! => { > "action": "influxdb_database", > "changed": false, > "invocation": { > "module_args": { > "database_name": "cloudkitty", > "hostname": "dashint.cloud.cerist.dz", > "password": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER", > "path": "", > "port": 8086, > "proxies": {}, > "retries": 3, > "ssl": false, > "state": "present", > "timeout": null, > "udp_port": 4444, > "use_udp": false, > "username": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER", > "validate_certs": true > } > }, > "msg": "('Connection aborted.', RemoteDisconnected('Remote end closed > connection without response',))" > } On the influxdb container I did this : > [root@controllerb ~]# docker ps | grep inf > 68b3ebfefbec > 192.168.1.16:4000/openstack.kolla/centos-source-influxdb:xena > "dumb-init --single-…" 22 minutes ago Up 22 minutes > influxdb > [root@controllerb ~]# docker exec -it influxdb /bin/bash > (influxdb)[influxdb@controllerb /]$ influx > Failed to connect to http://localhost:8086: Get http://localhost:8086/ping: > dial tcp [::1]:8086: connect: connection refused > Please check your connection settings and ensure 'influxd' is running. > (influxdb)[influxdb@controllerb /]$ ps -ef > UID PID PPID C STIME TTY TIME CMD > influxdb 1 0 0 Apr18 ? 00:00:00 dumb-init > --single-child -- kolla_start > influxdb 7 1 0 Apr18 ? 00:00:01 /usr/bin/influxd > -config /etc/influxdb/influxdb.conf > influxdb 45 0 0 00:12 pts/0 00:00:00 /bin/bash > influxdb 78 45 0 00:12 pts/0 00:00:00 ps -ef > (influxdb)[influxdb@controllerb /]$ I have no log file for influxdb, the directory is empty. Any ideas? Regards.

4 7

Setup infrastructure failing
by Derek O keeffe 26 Apr '22

26 Apr '22

Hi all, We get the following error in the openstack.osa.db_setup : Create database for service task: failed: [infra1_keystone_container-e54c8ba5 -> infra1_utility_container-1a1eb7ce(xx.xx.xx.xxx)] (item={'name': 'keystone', 'users': [{'username': 'keystone', 'password': 'PASSWORD'}]}) => {"ansible_loop_var": "item", "changed": false, "item": {"name": "keystone", "users": [{"password": "PASSWORD", "username": "keystone"}]}, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (2003, \"Can't connect to MySQL server on 'xx.xx.xx.xxx' ([Errno 111] Connection refused)\")"} Also, ansible galera_container -m shell -a "mysql -h localhost -e 'show status like \"%wsrep_cluster_%\";'" is different to the example output: infra1_galera_container-90dd1571 | CHANGED | rc=0 >>Variable_name Valuewsrep_cluster_weight 1wsrep_cluster_capabilities wsrep_cluster_conf_id 1wsrep_cluster_size 1wsrep_cluster_state_uuid c06b8107-c53a-11ec-a54c-a20664362f6cwsrep_cluster_status Primary We checked our infra node and all the containers are present and mysql is installed on the infra1-galera-container and port 3306 is open. MariaDB [(none)]> show databases;+--------------------+| Database |+--------------------+| information_schema || mysql || performance_schema || sys |+--------------------+4 rows in set (0.001 sec) We are not sure what is causing this and it could possibly be that we have forgotten/skipped/missed a configuration step but we have gone over the process multiple times and cannot see what we may have missed. The previous playbooks did have a lot of "skipped" results compute1 : ok=120 changed=2 unreachable=0 failed=0 skipped=31 rescued=0 ignored=0 compute2 : ok=120 changed=2 unreachable=0 failed=0 skipped=31 rescued=0 ignored=0 infra1 : ok=156 changed=3 unreachable=0 failed=0 skipped=31 rescued=0 ignored=0 infra1_aodh_container-7c703324 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_ceilometer_central_container-7590db72 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_cinder_api_container-91806531 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_galera_container-90dd1571 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_glance_container-fff39ac4 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_gnocchi_container-ffd32a8b : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_heat_api_container-a4079838 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_horizon_container-9c041ec0 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_keystone_container-e54c8ba5 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_memcached_container-dc50bcd8 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_neutron_server_container-bfc4d0d2 : ok=92 changed=37 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_nova_api_container-f231bb13 : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_placement_container-108d79df : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_rabbit_mq_container-50ca98ed : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_repo_container-ccade01d : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 infra1_utility_container-1a1eb7ce : ok=89 changed=36 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 localhost : ok=19 changed=0 unreachable=0 failed=0 skipped=14 rescued=0 ignored=0 compute1 : ok=0 changed=0 unreachable=0 failed=0 skipped=10 rescued=0 ignored=0 compute2 : ok=0 changed=0 unreachable=0 failed=0 skipped=10 rescued=0 ignored=0 infra1 : ok=38 changed=0 unreachable=0 failed=0 skipped=35 rescued=0 ignored=0 infra1_galera_container-90dd1571 : ok=69 changed=3 unreachable=0 failed=0 skipped=12 rescued=0 ignored=0 infra1_memcached_container-dc50bcd8 : ok=16 changed=0 unreachable=0 failed=0 skipped=4 rescued=0 ignored=0 infra1_rabbit_mq_container-50ca98ed : ok=69 changed=33 unreachable=0 failed=0 skipped=14 rescued=0 ignored=0 infra1_utility_container-1a1eb7ce : ok=40 changed=18 unreachable=0 failed=0 skipped=11 rescued=0 ignored=0 A lot were around Galera tasks but we are not sure if they were skipped intentionally as the playbooks ran to completion.Any help or troubleshooting steps would be appreciated. Thanks in advance. Regards,Derek

2 1

[skyline] skyline-console whl package question
by Satish Patel 26 Apr '22

26 Apr '22

Folks, I am compiling skyline-apiserver on my bare metal server and found Makefile pulling skyline-console tarball from the following location but that package doesn't contain the latest merged patches. Does CI job is broken which compiles this tarball ? https://tarballs.opendev.org/openstack/skyline-console/

2 2

[oslo][ops] Change in default logging format
by Stephen Finucane 26 Apr '22

26 Apr '22

I'm not sure how many people read release notes for the various oslo libraries, so I'm posting this here since it might have a minor impact for some tooling operators are using. We've just merged [1] which changes the default logging format used by oslo.log, configured using the '[DEFAULT] logging_context_format_string' config option. Previously, our logging format was: %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(request_id)s %(user_identity)s] %(instance)s%(message)s This looks like e.g. 2022-04-26 10:49:14.629 4187413 WARNING nova.conductor.api [req-ffddccd3-8804-4fc3-a2f3-a05af1eb569f - - - - -] This has now been modified to include the global request ID as well as the local request ID: %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(global_request_id)s %(request_id)s %(user_identity)s] %(instance)s%(message)s This looks like e.g.: 2022-04-26 10:53:16.756 4187784 DEBUG nova.service [None req-f1698728-a2d6-4e02-a6b4-cf2cd398c02f - - - - -] Join ServiceGroup membership for this service compute This will affect pretty much all services using the out-of-the-box logging configuration. However, I suspect very few if any users are using the standard configuration. DevStack overrides '[DEFAULT] logging_context_format_string' for all services [2] and I suspect other installers probably do the same. If you are using the standard configuration, you might need to modify some log parsing/scraping tooling when this rolls around or manually set '[DEFAULT] logging_context_format_string' in your service configuration files. Cheers, Stephen [1] https://review.opendev.org/c/openstack/oslo.log/+/838190 [2] https://github.com/openstack/devstack/blob/3b0c035b9/functions#L677-L707

1 0

[all][neutron][neutron-vpnaas] Maintainers needed
by Lajos Katona 25 Apr '22

25 Apr '22

Hi, In the last few cycles neutron-vpnaas has no serious maintainers, and most patches merged were from Neutron core team or from Release team. Recently even neutron-vpnaas gate jobs started to fail. During the Zed PTG we discussed this topic (see [1]), For the maintenance we need someone to be the contact person for the project, who takes care of the project’s CI and review patches, answers bugs. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :) If we don’t have any new maintainer(s) before milestone Zed-2, which is July 11 - July 15 week according to [2], we will start marking neutron-vpnaas as deprecated and in the next cycle (AA, or perhapc 2023.1) we will propose to retire the project. So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects. [1]: https://etherpad.opendev.org/p/neutron-zed-ptg#L201 [2]: https://releases.openstack.org/zed/schedule.html Lajos Katona (lajoskatona)

2 2

[cinder] how cinder gets the volume name when restore from a backup?
by Tony Liu 25 Apr '22

25 Apr '22

Hi, Here is what I do. * Create a volume. * Create a backup of this volume. * Delete the volume. * Restore the volume from backup. The restored volume has different UUID, but the same name. I don't see volume name is stored in backup metadata. How does Cinder know the volume name when restore it from backup, given the volume is already deleted? Thanks! Tony

2 2

retention policy for deleted resource in database
by Tony Liu 25 Apr '22

25 Apr '22

Hi, I see the record for deleted resource stay in database. What's the retention policy for those records? Is it configurable? Any manual cleanup is required? Thanks! Tony

2 2

[neutron] Bug Deputy Report Apr 18 - Apr 24
by Oleg Bondarev 25 Apr '22

25 Apr '22

Hello Team, Bug report for the week of Apr 18 is below. Two OVN bugs (including Invalid one) need triage from the OVN team. High ------ - https://bugs.launchpad.net/neutron/+bug/1969615 - OVS: flow loop is created with openvswitch version 2.16 - Opinion - seems more an issue in OVS rather than a bug in Neutron - Unassigned Undecided -------------- - https://bugs.launchpad.net/neutron/+bug/1969592 - [OVN] Frequent DB leader changes causes 'VIF creation failed' on nova side - New - Unassigned Invalid --------- - https://bugs.launchpad.net/neutron/+bug/1969354 - ovn-controller don't update new flows - Invalid - but reporter updated with additional info - Unassigned Thanks, Oleg

1 0

[ironic][ptg] Zed PTG Summary
by Iury Gregory 25 Apr '22

25 Apr '22

Hello Ironicers! Sorry for the delay to provide a summary about our PTG =) First of all, thank you to all contributors that took some time to join our sessions! During the sessions we had a peak of 13 attendees on the last three days. Day1 We only had two topics: Feedback about the Yoga Cycle and What should we do about specs. During the of we did a retrospective about the Yoga Cycle, we discussed the good and bad things that happened during the cycle and how we can make things better. In the discussion about what we should do about specs we come up with some ideas to improve our process when we think a spec should be required. Day2: On this day most of the discussions were around topics that can be managing machines. How we can decrease the cost of Data Centers that needs to keep all their machine on even if they are not active or taking minimal load, we would provide a way to power tuning nodes that are already deployed (in the ironic perspective this is a way to reconfigure a node that is already active), we also talked about turning down power usage if we are able to identify that IPA is idle. The custom deploy timeout topic had no strong objections, since we have a single configuration that handles the timeout for all steps we think we can improve this, we still need to define some details related to the implementation after we have the RFE. We discussed how we can generate the inspector.ipxe configuration if we notice some changes in the configuration of the deployment. Day3: We started this day looking at the survey results, this gave us some ideas on possible areas we should improve. The ironic safeguard topic was focusing on two main things: queuing (limit the max number of concurrent cleaning operations) and data disk protection (only clean the root disk (or give a list of skip-disks/disks-to-clean). The community decided that this seems like a good idea and we defined some of the possible paths forwards related to how it could be implemented. The redfish gateway and related ideas topic brought an interesting idea to have an ironic driver that can execute a "script" that is required for their HW to start working properly, there is a recording from the first meeting that can provide more details =). The per-node clean steps topic had no objections, we think this will improve the operators experience for scenarios where they would need specific steps for running on a node that has different disk configuration. Day4: Most of the topics on this day were focused on networking. We discussed the status of OVN DHCP support and how we will move forward on our side to make things work after Neutron and OVN have all the necessary bits in place. During the next topic we talked about adding device configuration capabilities for networking-baremetal since in multi-tenant BMaaS there is a need to configure the ToR network devices (Access/Edge Switches) and many vendors have abandoned their ML2 mechanism plug-ins to support this, so now we are looking to add support for new mechanisms that have more features that could improve the operators experience. We focused on discussing the pros/cons about Netconf and Yang but also other alternatives solutions. The other topic we discussed were: - netboot deprecation: we discussed how we should move forward with some of our testing for partition images + UEFI. - Bluefield DPU: not much discussion since we didn't have many folks interested on the topic. - Anaconda driver: we talked about how we can get a CI for testing the driver. You can find more information about the topics and the discussions in our etherpad: https://etherpad.opendev.org/p/ironic-zed-ptg -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[largescale-sig] Skipping meeting this week
by Thierry Carrez 25 Apr '22

25 Apr '22

Hi everyone, Due to a shortage of participants and meeting chairs, we will skip the meeting planned this week for the Large Scale SIG. Our next meeting will be May 11th at 15UTC in #openstack-operators. You can add topics to discuss to our agenda etherpad: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez (ttx)

1 0