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

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

27 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 18 Sep '23

18 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 11 Sep '23

11 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

[Skyline] error username or password incorrect
by Satish Patel 11 Sep '23

11 Sep '23

Folks, Try to install skyline UI to replace horizon using doc: https://docs.openstack.org/skyline-apiserver/latest/install/docker-install-… Everything went well and I got a login page on http://x.x.x.x:9999 also it pulled Region/Domains. When I am trying to login with my account, I get an error: Username or Password is incorrect. I am using sqlite DB for skyline as per documents. No errors in logs command $ docker logs skyline When I use Chrome Developer Tools then it was indicating an error in these URLs. http://openstack.example.com:9999/api/openstack/skyline/api/v1/profile http://openstack.example.com:9999/api/openstack/skyline/api/v1/policies 401 Unauthorized ( {"detail":"no such table: revoked_token"} )

2 16

[openstack-ansible] Recommended branch for a production environment?
by Roger Rivera 05 Sep '23

05 Sep '23

Hello, We have deployed Openstack-Ansible in a test environment and we were wondering what the recommended repository branch is to deploy in a production environment that will be integrated with a separate Ceph cluster. 1. We are thinking about pinning to the stable/zed. Is that recommended over the master branch? 2. Are bugs ironed out on both master and stable/zed with the same cadence? 3. Additionally, is Debian 11 a better alternative than Ubuntu 22 for target hosts? We noticed Ubuntu 22.04 support was added recently, whereas Debian 11 has been supported for quite some time now which leads us to believe its stability/integration could be more mature at this point? Any suggestions will be appreciated. Thank you, -- *Roger *

3 7

[SDK][CLI][API][OpenAPI] Machine readable OpenStack API spec - time to do a next step?
by Artem Goncharov 01 Sep '23

01 Sep '23

Hey, Some of you may know that for certain time I was doing experiments on the sdk/cli/ansible_mod side with regards to the code generation. Reason for that is simple: huge codebases and too few resources. While not being the primary goal of this initiative, but still a pointer into the same direction is that most of the tools we need to maintain do the same stuff with some adaptations necessary for the framework in question. I did a lot of diverse attempts trying to take current OpenStackSDK codebase as a “source of truth” regarding what exists in which service and use it to generate code (OSC, AnsibleModule, etc). Pretty quickly it became clear that we do not have enough information to cover all the different needs: - when query parameter has been added into or dropped from the API - what is the type of the query parameter and whether in the case it is list it should be rendered as "?tags=a,b" or "?tags=a&tags=b” - which fields are necessary to be send in the request, which are optional and how to deal when you send name but get back UUID in the same field - what are the parameter/resource fields types in detail with respect to strongly typed programming languages (“int” is not good to differentiate between u8 and f64) - how to determine list of supported “actions” on the resource which are above the plain CRUD Firstly I tried to extend our current model of things in SDK, but even that was not so helpful. And then I decided to give another look at OpenAPI and our desires since multiple years to move into that direction. First of all it provides all the required information to do what is necessary. And so I tried to gather all the things we said about OpenAPI at OpenStack and which challenges we have and compare it against the OpenAPI 3.1. Problems: 1) OpenAPI does not support model of microversions. To be more precise on that you can’t describe different request/response body based on the header differentiator 2) URL + Method are representing unique combination making it impossible to represent different actions based on the content 3) All relevant Headers are supposed to be described in the spec. For example Swift is using X-Object-Meta-* prefix to allow user customisations what is not currently supported by the spec Actually that’s it, everything else was doable. Have I missed something? So what can we do about it: 1) OpenAPI 3.1 is now based upon jsonschema, what allows huge flexibility in describing object schema including inheritance and polymorphism (with composition, discriminator, etc). So we can describe the necessary Microversion Header and schema using “oneOf” whenever necessary. Moreover it is possible to extend type schema with “x-“ prefixed custom properties. So I went and started adding “x-openstack-“ prefixed properties where necessary 2) I personally agree with OpenAPI that URL+method should be enough to uniquely identify what is expected (while not a big deal for the API consumer, it would have been easier on the server side to have URL uniquely tied with the data and operation instead of dynamically looking at the request to figure out what to do. This is actually a most complex thing to deal with and the only solution that comes to my mind would be not to try to put everything into single spec, but rather have a dedicated specs for different operations. It makes it anyway easier to maintain such spec. Maybe at some next OpenAPI iteration this gets resolved and we can adopt changes. 3) A tricky thing, but there is nothing preventing us specifying headers as “x-object-meta-*” and defining custom processors for things like that to for example compose/decompose this into dictionary on the client side OpenAPI now even allows defining spec extensions if necessary, but I think at the moment we can cover all issues without that. Demo time: - server live migration (in my eyes one of the trickiest things I have seen so far from the OpenStack APIs). Here you have an action requiring a dedicated spec, multiple revisions with micro versions and even parameter type bool which can be a string as well: [2] https://paste.opendev.org/show/bcxFi2CrNX1YNEuTzoEh/ More real-life examples in [4] - image create and upload: [3] https://paste.opendev.org/show/bNN1t0qVmHEdVHu0Mtrn/ Here it is possible to put few methods into the single spec. You can also see here samples of different media-types, capture headers, readOnly/writeOnly properties (You can actually take those specs and paste them into https://editor-next.swagger.io/ and see how it looks like) Closing notes: I have implemented a WIP change [1] in SDK that consumes list of specs and performs requested operation. Series of SDK commands are converted to the new way dealing with APIs. This is backwards compatible, but opens a road to heavily reduce amount of code in SDK (precisely by dropping all those customisations that are necessary now). Honestly speaking my drafts even show performance improvement on SDK side in the area of 100-300ms for diverse API operations, but I am still not really able to explain why. Maybe because of avoiding most black magic of SDK. I assume after completion we could get another performance boost by dropping other unnecessary logic and abstractions. The work is not completed as the change title states. Once we have specs for the commands code generators can be updated to consume this data and produce much better code. BTW, I have now also a prototype of the new CLI written with Rust and this is a hypersonic bullet compared to the current OSC. But please do not push me more on that, it is still in a very early stages and depends heavily on the available specs. I can only say that it is now designed in the way that every API call can have a thin CLI coverage just by providing a spec, when additional logic is desired - surely will require human implementation. Code generators in the pipe: OSC, AnsibleModules, RustSDK (sync/async), RustCLI. Next thing that are on the radar: gopher cloud, terraform modules, async python sdk, JS SDK(?) If all of that gets executed properly and with some community traction we can all have following things covered: - improve standardisation of OpenStack internals and externals: glance and nova (at least those 2) are already using jsonschema internally in different areas to describe requests/responses. Why not to make this standard reaching the service consumers? - getting rid of api-ref work by updating our sphinx machinery to consume our customised specs and produce nice docs matching the reality - sharing specs between teams to improve interface (not like currently we need to read the api-ref with tons of bugs plus source code to understand how to cover new feature in service X). Maybe even a central repo with the specs per release. - there are plenty of code generators and server bindings for OpenAPI specs so that we can potentially align frameworks used by different teams to maintain less - less work for all of us who needs services talking to each other (not immediately right now, but once the code is switched on consuming specs) - request verification already on the client side not waiting for the response - finally show something to customers often annoying asking “where are your openapi specs” (no offence here ;-))? I know it is a long message. But I am pretty excited with the progress and would like to hear community opinions. For the more detailed discussion consider this as a pre-announcement of the topic for PTG in sdk/cli slots. Huge invest but huge outcome P.S. it can result in a good chunk of relatively easy work for students Regards, Artem [1] https://review.opendev.org/c/openstack/openstacksdk/+/892161 [2] https://paste.opendev.org/show/bcxFi2CrNX1YNEuTzoEh/ [3] https://paste.opendev.org/show/bNN1t0qVmHEdVHu0Mtrn/ [4] https://review.opendev.org/c/openstack/openstacksdk/+/893365

4 5

[all] osprofiler requirements on opentelemetry: is this reasonable?
by Thomas Goirand 01 Sep '23

01 Sep '23

Hi, I just saw that the last version of osprofiler requires opentelemetry-exporter-otlp and opentelemetry-sdk. Since osprofiler is used in almost all projects, and that opentelemetry is really HUGE, I wonder if this is all reasonable. This forces downstream distros to do a lot of packaging only for that. Is this avoidable? I started doing the packaging, and then stopped to write this message, seeing how much work that would represent. Your thoughts? Cheers, Thomas Goirand (zigo)

3 3

[Rally]
by Aayushi Gautam 31 Aug '23

31 Aug '23

Hello, I am Aayushi , an intern with Redhat working on ESI ( Elastic secure Infracstructure) group. We were trying to use Rally to test the performance of our codebase. I have created a Plugin and task . And getting an error. The same bug is also asked on the bug page of Rally, but it was not answered. I have attached the code of the plugin and task and the error message. Looking forward to hearing from you.

2 5

Issue with Live Migration
by Chris DiLorenzo 31 Aug '23

31 Aug '23

We are running zed deployed with kolla-ansible. We are running into an issue with Live Migration. These are the steps to reproduce the issue: - Create a VM - Attach a Cinder Volume. This will create a new Storage Controller. - Start writing data to the new disk. We used FIO. Let FIO run until it starts reporting IOPS data. - Live migrate the VM - The VM will migrate and FIO will continue to run. FIO will show 0 or no IOPS - lspci output will show that the new storage device is in error. - The VM will remain in this state until the user issues a hard reset command - Once the VM is rebooted, the issue can not be reproduced until another device is attached This also happens if we attach a new VNIC. Prior to migration, this is what we see: root@test-vm-cd:~# cat before_migration_lspci.txt | grep block 05:00.0 SCSI storage controller: Red Hat, Inc. Virtio block device (rev 01) Subsystem: Red Hat, Inc. Virtio block device 08:00.0 SCSI storage controller: Red Hat, Inc. Virtio block device (rev 01) Subsystem: Red Hat, Inc. Virtio block device Post migration we see this: 08:00.0 SCSI storage controller: Red Hat, Inc. Virtio block device (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: virtio-pci The original SCSI controller is fine. Outside of the above error, we don't see any other errors. From Openstack's perspective, the migration went fine. Any suggestions on where to look? Has anyone else seen this? Thanks, Chris

1 0