August 2023 - openstack-discuss - lists.openstack.org

[Watcher] How use Watcher to scheduler Openstack resource without cpu_usage
by Nguyễn Hữu Khôi 07 Mar '24

07 Mar '24

Hello guys. I want to use watcher to scheduler openstack resources but some openstack versions are missing cpu_usage metric. How do we use Watcher without it? Thank you. Nguyen Huu Khoi

3 5

[neutron][vpnaas][ovn] Pushing VPNaaS support through OVN
by Mohammed Naser 13 Feb '24

13 Feb '24

Hi all! One of the biggest show stoppers for us for OVN is VPNaaS but I think it’s time that we’d like to be involved in getting it over the line, I want to thank Bodo who has shown a lot of patience in getting the code necessary, and it seems that the code works for them in production as well. I’d like to ask if possible for folks to review these two outstanding changes: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/847007 https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353 I know Slawek had some concerns, so hoping that raising via the email list if Bodo can address those and over the next bit of time we can get this landed in, since it even has actual proper testing both in CI and with user feedback. Thanks! Mohammed

6 8

[designate] Proposal to deprecate the agent framework and agent based backends
by Michael Johnson 10 Jan '24

10 Jan '24

TLDR: The Designate team would like to deprecate the backend agent framework and the agent based backends due to lack of development and design issues with the current implementation. The following backends would be deprecated: Bind9 (Agent), Denominator, Microsoft DNS (Agent), Djbdns (Agent), Gdnsd (Agent), and Knot2 (Agent). Designate includes many backend DNS server drivers[1], many of which are "native" (also known as xfr type backends) backend implementations. In addition to the "native" backends, Designate has an agent backend[2] that supports other backends via an agent process. To quote the agent backend documentation[2]: This backend uses an extension[3] of the DNS protocol itself to send management requests to the remote agent processes, where the requests will be actioned. The rpc traffic between designate and the agent is both unauthenticated and unencrypted. Do not run this traffic over unsecured networks. Here are the reasons we are proposing to deprecate the agent framework now: 1. The agent protocol used by Designate is using an "unassigned"[4][5] DNS opcode (14) that is causing problems with the dnspython library >= 2.3.0 which is now validating the opcode when building DNS messages. It is a bad practice to use "unassigned" values as they may be officially assigned at any time, likely with an incompatible message format. 2. The agent backends are not tested in the OpenStack jobs[1]. 3. Many of the agent backends have been marked as "Experimental" since 2016 with no additional contributions beyond general repository code maintenance. 4. The protocol between the Designate worker process and the agent process is unauthenticated and unencrypted. 5. We do not know of a development resource to rewrite the agent framework protocol to address issue #1 and #4 above. 6. The introduction of catalog zones[6] may eliminate the need for some of the agent based backend drivers. By marking the agent framework and agent based backends "deprecated" in the Antelope cycle, we would remove the code no earlier than the "C" release of OpenStack (per the OpenStack deprecation policy[7]). In the meantime, issue #1 has been worked around by overriding the dnspython opcode validation[7] as needed in the Designate code (similar to a monkey patch). This is not a sustainable long term solution. The following backend agent based drivers would be marked "deprecated" in addition to the agent framework itself: Bind9 (Agent) Denominator Microsoft DNS (Agent) Djbdns (Agent) Gdnsd (Agent) Knot2 (Agent) We plan to propose patches for the deprecation over the next week, but will not merge them until at least January 24th to allow time for comment from the community. If you have concerns about this deprecation plan or are interested in rewriting the agent framework protocol to address the above issues, please reply to this announcement. Michael [1] https://docs.openstack.org/designate/latest/admin/support-matrix.html [2] https://docs.openstack.org/designate/latest/admin/backends/agent.html [3] https://github.com/openstack/designate/blob/master/designate/backend/privat… [4] https://www.rfc-editor.org/rfc/rfc6895.html#section-2.2 [5] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… [6] https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-08.txt [7] https://docs.openstack.org/project-team-guide/deprecation.html [8] https://review.opendev.org/c/openstack/designate/+/870678

3 13

[swift][OpenStackSDK][keystone] Warnings about (my) swift endpoint URL by keystoneauth1 discovery
by Christian Rohmann 14 Nov '23

14 Nov '23

Hey openstack-discuss, we use Ceph RadosGW (Quincy release) to provide Swift as part of an OpenStack cloud. The endpoints are configured as such: > # openstack endpoint list > +----------------------------------+--------+--------------+----------------+---------+-----------+----------------------------------------------------------------------+ > | ID | Region | Service Name | Service > Type | Enabled | Interface | URL | > +----------------------------------+--------+--------------+----------------+---------+-----------+----------------------------------------------------------------------+ > | 1234567890 | region | swift | object-store | True | > public | > https://object-store.region.cloud.example.com/swift/v1/AUTH_%(tenant_id)s > | > | 2345678901 | region | swift | object-store | True | > internal | > https://object-store.region.cloud.example.com/swift/v1/AUTH_%(tenant_id)s > | > | 3456789012 | region | swift | object-store | True | > admin | > https://object-store.region.cloud.example.com/swift/v1/AUTH_%(tenant_id)s > | > so according to https://docs.ceph.com/en/latest/radosgw/keystone/#cross-project-tenant-acce…, if I am not mistaken. I can also use the openstack client to access containers: > # openstack container list > +---------------+ > | Name | > +---------------+ > | containera | > | containerb | > +---------------+ and there is no warnings or other apparent issues. But when using "project cleanup" via e.g. "openstack project cleanup --dry-run --project $PROJECT" I see multiple warnings like > Failed to contact the endpoint at > https://object-store.region.cloud.example.com/swift/v1/AUTH_f2bc4bd34567ddc… > for discovery. Fallback to using that endpoint as the base url. > but only mentioning the swift endpoint. Following the warning string this originates from the discovery method of keystoneauth1, see https://github.com/openstack/keystoneauth/blob/28048af9593740315df8d9027c3b…. Could anybody help me understand what is issue might be? Why does this warning not appear for every use of object storage / swift via openstackclient? Is there any way for me to "fix" this? Could this even be a bug? Thanks and with kind regards Christian

4 10

[kolla] [train] [cinder] Cinder issues during controller replacement
by Albert Braden 20 Oct '23

20 Oct '23

We’re replacing controllers, and it takes a few hours to build the new controller. We’re following this procedure to remove the old controller: https://docs.openstack.org/kolla-ansible/train/user/adding-and-removing-hos… After that the cluster seems to run fine on 2 controllers, but approximately 1/3 of our volumes can’t be attached to a VM. When we look at those volumes, we see this: | os-vol-host-attr:host | qde4-ctrl1.cloud.ourdomain.com@rbd-1#rbd-1 | Ctrl1 is the controller that is being replaced. Is it possible to change the os-vol-host-attr on a volume? How can we work around this issue while we are replacing controllers? Do we need to disable the API for the duration of the replacement process, or is there a better way?

6 9

[OPENSTACK][rabbitmq] using quorum queues
by Nguyễn Hữu Khôi 18 Oct '23

18 Oct '23

Hello guys. IS there any guy who uses the quorum queue for openstack? Could you give some feedback to compare with classic queue? Thank you. Nguyen Huu Khoi

9 19

[all][tc] python 3.11 testing plan
by Ghanshyam Mann 28 Sep '23

28 Sep '23

Hi All, Some of you are part of discussion for python 3.11 testing but If you are not aware of it, below is the plan for python 3.11 testing in OpenStack. Non voting in 2023.2 ------------------------- You might have seen that python 3.11 job is now running as non voting in all projects[1]. Idea is to run it as non voting for this (2023.2) cycle which will give projects to fix the issue and make it green. As it is running on debian (frickler mentioned the reason of running it in debian in gerrit[2]), it need some changes in bindep.txt file to pass. Here is the example of fix[3] which you can do in your project also. Voting in 2024.1 -------------------- In next cycle (2024.1), I am proposing to make py3.11 testing mandatory [4] and voting (automatically via common python job template). You need to fix the failure in this cycle otherwise it will block the gate once the next cycle development start (basically once 891238 is merged). [1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891227/5 [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891146/1 [3] https://review.opendev.org/c/openstack/nova/+/891256 [4] https://review.opendev.org/c/openstack/governance/+/891225 [5] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891238 -gmann

12 27

[ironic] Mass retirement of old branches due to config errs
by Jay Faulkner 19 Sep '23

19 Sep '23

Hi all, Ironic is one of the major offenders remaining in the work to cleanup Zuul config errors. To resolve these issues, it's my plan to retire any impacted branches unless a contributor volunteers to clean them up. I will give folks until at least September 1, 2023, to object before I begin to take action. These branches have been broken for at least one year, and have gotten no patches or releases in that time. It's clear they have little need to continue existing. Please look at https://zuul.opendev.org/t/openstack/config-errors for the full list of potentially impacted branches; I will list here as best I can: openstack/ironic-prometheus-exporter - bugfix/2.1 - stable/train openstack/networking-generic-switch - stable/pike - stable/train - stable/ussuri - stable/victoria - stable/wallaby - stable/xena openstack/python-ironicclient - stable/train - stable/ussuri - stable/victoria - stable/wallaby - stable/xena - Note: stable/yoga is also in the config errors list, but is considered maintained and cannot be retired at this time. I will work to remove failing jobs and get this zuul config fixed manuallt. As an additional note, the following branches were retired months ago, but due to a bug were recreated. They have been fully deleted (again): openstack/ironic-python-agent - bugfix/8.0 openstack/ironic - bugfix/18.0

3 4

[cinder][kolla-ansible] cinder-volume active/active usage
by 韩光宇 15 Sep '23

15 Sep '23

Hello, I saw that kolla-ansible had allow cinder coordination backend to be configured. And it can be set to "redis" or "etcd" in /etc/kolla/gloabls.yml [1]. Based on my current understanding, this option enables cinder-volume active/active. 1. I would like to ask, between Redis and Etcd, which one is more recommended or what are their pros and cons? 2. And I have saw the spec of cinder-volume a/a[2]. Is it sufficient to configure [coordination]backend_url and [DEFAULT]cluster to use Cinder volume active/active, or are there any other considerations? Could any reference for Cinder volume active/active configuration and usage documentation be recommended ? I would appreciate for any help. Best wishes. Han Guangyu [1] https://github.com/openstack/kolla-ansible/blob/master/etc/kolla/globals.ym… [2] https://specs.openstack.org/openstack/cinder-specs/specs/ocata/ha-aa-job-di…

3 2

[ptl][tc][winstackers] Final call for Winstackers PTL and maintainers
by James Page 12 Sep '23

12 Sep '23

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

5 9