- openstack-discuss - lists.openstack.org

[kolla] Upgrading from Train to Wallaby
by Albert Braden 23 Nov '23

23 Nov '23

Is it possible to upgrade kolla-ansible from Train to Wallaby in one step, or do we need to step through Ussuri and Victoria?

4 3

[keystone] temporary workaround for deprecated _member_ role?
by Christian Stelter 23 Nov '23

23 Nov '23

Hi! As someone who hasn't yet delved very deeply into keystone and the policies of the individual OpenStack services, I wondered whether setting member as the implied role for _member_ could pick up all those users who didn't manage to rotate their application credentials before switching to Zed Antelope. Is this a valid approach or could it cause problems? Kind regards, Christian

4 8

[ironic] Multiple vendor drivers being deprecated
by Julia Kreger 22 Nov '23

22 Nov '23

Greetings everyone, During Ironic's last PTG[0], we discussed the future path for drivers and the overall direction in the vendor ecosystem. The overall consensus was that DMTF Redfish is largely achieving its overall goal to standardize interfaces for interactions with Baseboard Management Controllers. Most of the vendors we collaborate with are in the process of determining their support and migration paths to Redfish. But as with any Open Source project with drivers, we also haven't heard from some vendors recently for a variety of reasons. It is with that in mind, we've made the decision to deprecate and eventually remove[1] some of the vendor drivers in cases where we've not heard from the maintainers and there is a forward path. * ibmc - We've not heard from the maintainer in some time due to geopolitical circumstances, but when we last heard from the developer/maintainer, they indicated work was actively underway to achieve redfish compliance in their employer's hardware. * xclarity - This driver was a driver which was designed to talk to the Lenovo xClarity Controller. This driver largely had no forward path, as we believe the underlying API support it used was also deprecated by Lenovo with the release of xClarity Controller v3. We have received numerous reports that the upstream redfish hardware type works as expected against Lenovo hardware, and at this point it just seems logical to move beyond this early driver. * iDRAC WSMAN driver flavors - The Dell team at a point long in the past decided Redfish was the future direction, and they created a set of "Redfish" interfaces in their driver, which replaced "WebServices for Management", better known as WSMAN interfaces which hail back to the days of iDRAC 6 (2008). At this point, given iDRAC7 (2012) firmware updates are available with Redfish support, we believe Redfish is generally suitable moving forward. The specific modules going away are the "-wsman" variant interfaces under the idrac hardware type. In case you are now wondering about the Fujitsu iRMC and HPE iLO drivers, we've heard from those teams recently and they too are focusing on Redfish as their forward path. The exact shape and form remains to be determined as each vendor has unique constraints and requirements to work with. As a result of this, their driver interfaces are not impacted by this decision by the community. If you have any questions or concerns, please feel free to reach out or join the Ironic team during our weekly meeting[2]. -Julia [0]: https://etherpad.opendev.org/p/ironic-ptg-october-2023 [1]: https://review.opendev.org/c/openstack/ironic/+/901501 [2]: https://wiki.openstack.org/wiki/Meetings/Ironic

1 0

Re: [SDK][CLI][API][OpenAPI] Status Update
by Artem Goncharov 22 Nov '23

22 Nov '23

Hi all, as promised here is status update of the OpenAPI work, and sorry in advance for another long message Short version ========== I have extended codegerator [1] to build OpenAPI specs from the sources of the services. All the exposed URLs with wherever possible query parameters/request/body are placed into the OpenAPI spec and whenever available generated information is extended with descriptions from rendered API-Ref html to keep life easier. This helped me to spot a variety of issues: unknown/undesired routes exposed, undocumented routes, documentation for unexposed routes, etc Sadly not all services are having all the required information to build the spec so the generator is created in the way that supports extension and overrides for every service. - Nova has route versions, request_body and response codes, but no information about response json - Glance is not bad, but not every request/response info is available directly on the controller. - Cinder is not having query parameters information, no response body schema - Keystone is not having much of useful information directly attached to the routes, but is having useful part schemas in the code - Neutron is very special - Octavia is having request and response info available (as wsme, but I have written wsme=>jsonschema convertor) Current state of schemas can be found under [2]. Schemas are still with gaps, but general structure can be seen [1] https://review.opendev.org/c/openstack/openstacksdk/+/882326 [2] https://github.com/gtema/openstack-openapi/tree/main/specs Long version ========= codegenerator is able to inspect source code of services in diverse ways (requires service to be "pip installed" into the env of codegenerator). Generally I am looking at the api router/mapper of the service and start traversing from there. This ensures we document all the routes and not what we think about. It helped me to figure out i.e. Cinder is exposing all routes with and without project_id (this was honestly new to me and would have helped to reduce insanity in project_id handling in the SDK code), Octavia exposes all routes with /v2, /v2/lbaas, /v2.0 and /v2.0/lbaas prefixes (altogether 4 times same operations). It is also possible to provide rendered html of the API-Ref and codegenerator will try to extract all methods descriptions and even try to get parameters description as long as it is possible (no magic, best effort approach). Nova: uses typical wsgi + routes. All exposed routes in all versions can be seen. There are validations attached to all routes what provides jsonschemas about query parameters and request body. There is some non standard mess with flavors actions (flavor delete/create/update are exposed as wsgi actions what under the hood exposes /flavors/{flavor_id}/action with corresponding json bodies. Validation for those fails, but that results in a wrong errors being returned to the user. I assume this is rather a bug and not a feature. Sadly there are no schemas describing api responses at all, so this needs to be provided separately/manually. Cinder: similar to Nova, except that also no query parameters information is available. Glance: Glance is sometimes having useful information attached to the routes by having serializer/deserializer classes available. This helped getting nearly all metadefs documented at no effort. Sadly there are also negative exceptions: image data operations are not having content-type information attached directly, so this requires a hack in the generator to build a correct spec for those operations. Still I was positively surprised with the amount of useful info I was able to get out of the source code without "hacks". Keystone: Flask is a tricky thing. Looking at all the routes exposed I got specs for all the resources in HEAD mode. Current API Ref mentions that, but they are not described at all. But that is not a big deal. A more severe problem is that the same controller is exposed for /<RESOURCE> and /<RESOURCE>/{resource_id} routes. This leads to the fact that user can send i.e. DELETE/PUT to /projects which will fail with 500 because project_id is a positional argument in the controller and not having default. But that heavily depends on the function signature and in my eyes this is a huge potential vulnerability and a quality gap (what would happen when somebody accidentally adds default value to that parameter?). This is the same for all routes exposed and not only relevant to projects. Sadly no extractable information about query parameters is available, but jsonschemas of resources are there (even for the /auth/tokens ). This requires manual mapping in the generator to know where schemas can be obtained from. Neutron: This one caused me a 4 day long headache. I have solved most of the issues, but there is still work to be done - inspecting the app requires neutron to be running (with a db created, all the schemas populated, config with all the plugins/extensions enabled, ....) Here the problem is to have actually all the plugins configured (some of them appears just don't like to work together with others) - some routes are exposed as wsgi app (the extensions app), but basic resources (networks, subnets, ports) are exposed as not inspectable pecan stuff (using dynamic _lookup to find route controller is just too complex for inspection) - neutron is having api definition which can be treated as a schema, but requires sophisticated logic (describing bulk requests is actually a no-brainer this way either) - still current biggest item is to have a max configuration so that codegenerator can look at every possible plugin Octavia: It is also using the Pecan framework with dynamic lookups which is a huge problem for the inspection, but the amount of those is rather an exception that allows me to traverse through "static" paths and supplement them with "exceptions". In contrast to all the other services Octavia is attaching full request and response definitions to the routes. Those are not jsonschema (wsme types), but jsonschema can be generated out of that with ~100 magic lines Heat: have not started, but the first look tells it is also using routes lib so it should be easy to get exposed routes. However it doesn't seem to have any usable api schemas in the code. Swift: I created the spec manually before I started working on generating specs from source. Luckily Swift is not having any/major api changes so it should not be a problem. With API-Ref info flowing into the spec we can get very usable specs automatically. Ideally all this information should be in docstrings (this is where initial descriptions are coming from and stay if api-ref match is not found). In the meanwhile I got requests about the topic from some other contributors which is why I feel myself confirmed I am not working on something nobody needs. As such we might need to restructure how and where the work is done and eventually get a few new projects to host codegenerator and openapi specs. Ideally I would like openapi specs to be belonging to services themselves, but I think getting them together separately is a better choice for the current phase until generation is finalized. Anyway, having a generator allows us to create jobs generating new specs for the services. With the generated specs I am already able to generate cli code (and sdk and ansible modules and etc) Next steps ======== - decide on where to host the generator (currently under the openstacksdk project) and where to store the specs - continue adding missing information to the already generated specs - decide on how to deal with sphinx-openapi. It is present and Stephen seems to be a maintainer of it, but even ignoring OpenStack API specialities it just produces not the output we used to have with current os-api-ref. So eventually a new project for rendering specs in the current style is necessary. Doesn't look like a complex task though - continue looking at other services (heat, magnum, etc) Feel free to ping me directly for collaboration and/or questions. Regards, Artem

2 1

[manila] Cancelling Nov 23rd weekly meeting
by Carlos Silva 22 Nov '23

22 Nov '23

Hello Zorillas! As a lot of people from our regular audience have holidays during this week, we are cancelling the Nov 23rd Manila weekly meeting. In the Nov 30th meeting, we would like to use most of the time to review backports, so please join us to help getting some fixes landing in the stable branches. Thanks and regards, carloss

1 0

[publiccloud-sig] Summary meeting CW 47
by Felix Kronlage-Dammers 22 Nov '23

22 Nov '23

Hi, in today’s publiccloud-sig meeting we’ve continued the topic of “flavor discoverability”, a topic that has been part of our discussion for a while. Before I dive into that, a quick heads-up: So far we’ve been meeting in the odd weeks. We’ll be switching that to the even weeks. This means, we’ll be meeting again next week (Nov. 29th). For today’s meeting: The minutes for the meeting are here: https://etherpad.opendev.org/p/publiccloud-sig-meeting Since this was a videocall (and as such no meetingbot logs), here a quick summary (thanks @joek-office). ======= 0. Discussion on flavor/image/volume "search engine" aka flavor-discovery - (gtema) The most informations that can be interessting for clients to search resources are at the respective services (nova/glance/cinder) in place - nova has traits but this is not searchable (possible extension - nova mentioned this as a tricky development), especially for clients - the traits has the ability to give out internal informations about the infrastructure, so cloud provider's possibly not happy with this solution - (gtema) problems with finding the right flavor/image in a openstack cloud - The flavor definitions are more or less a range in that nova scheduler will do its best to meet the criteria, no guarantee to get what you want @gtema pls update/delete this - The architecture of the instance is more defined by the image than from the flavor - thats because in the image are the appropriate sources for a cpu architecture - at the moment two possible ideas idea 1: extend the services with the appropriate features to meet the requirements cons: - long development pros: - no moderation/weighting of results possible idea 2: build up a new service with required metadata based on the .wellknown concept supported by sdk right now (or discoverable via service catalogue - that's not in scope of the service catalog, but the new "discovery" service may be added into the catalog) cons: pros: - the service can moderate/weight results to meet criterias from cloud provider AND client side - available for older OpenStack versions ========= For people interested in this subject, we (at least gtema and me) are going to continue this discussion tomorrow at 1400 CET here: https://conf.scs.koeln:8443/OIF-public-cloud-sig felix -- Felix Kronlage-Dammers Product Owner IaaS & Operations Sovereign Cloud Stack Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[kolla] Weekly meeting cancelled today (22nd Nov 2023)
by Michał Nasiadka 22 Nov '23

22 Nov '23

Hello, Due to key participants absence - the weekly Kolla meeting is cancelled today. Let’s meet next week Thanks, Michal

1 0

[cinder][backup] backup_max_operations configuration is not working
by Pureewat Kaewpoi 22 Nov '23

22 Nov '23

Hi communities I have set cinder backup with these configurations backup_max_operations = 4 backup_workers = 4 When I create 20 backups simultaneously According to logs It still creating backups at the same time. 2023-11-07 06:17:42.029 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:17:42.038 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:17:44.328 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:17:44.334 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:17:46.665 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:17:46.672 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:17:49.005 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:17:49.018 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:17:51.378 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:17:51.389 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:17:54.004 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:17:54.017 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:17:56.094 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:17:56.113 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:17:58.523 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:17:58.536 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:01.017 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:01.027 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:03.146 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:03.162 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:05.622 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:05.649 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:07.800 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:07.818 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:10.129 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:10.148 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:12.684 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:12.775 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:16.356 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:16.400 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:17.480 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:17.575 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:20.227 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:20.249 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:22.115 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:22.165 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:24.379 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:24.435 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:27.681 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:28.074 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:29.440 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:30.324 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) 2023-11-07 06:18:31.846 555360 INFO cinder.backup.manager [] Create backup started, backup: <BACKUP-ID> volume: <VOLUME-ID> 2023-11-07 06:18:31.874 555360 INFO cinder.backup.manager [] Call Volume Manager to get_backup_device for Backup(*TRUNCRATED*) The expected result is creating 4 backups simultaneously Have anyone face this issue ? or Do I config a wrong configuration ? Thanks Pureewat Kaewpoi

3 3

[openstack][octavia] octavia scale
by Nguyễn Hữu Khôi 21 Nov '23

21 Nov '23

Hello everyone, I would like to know how can we scale octavia. For example, if octavia is full ram or cpu, how we can resize them. I just google and I cannot see docs about it. Thank you.

2 4

[openstack][magnum] cinder AZ for magmum
by Nguyễn Hữu Khôi 21 Nov '23

21 Nov '23

Hello guys. When I create k8s cluster with magnum, I can choose AZ for nodes but if I want to put my cluster to a specified cinder AZ. How can we do it? Thank you. Nguyen Huu Khoi

2 2

Nominate Nicolas Bock for charms-stable-maint
by Corey Bryant 21 Nov '23

21 Nov '23

I would like to nominate Nicolas Bock for charms-stable-maint. Nicolas has a solid history of contributions and reviews for various OpenStack projects, he is a previous PTL for the Designate project, and over the past 3+ years, he has been contributing to charm reviews [1]. I trust that Nicolas will continue to provide value and quality reviews for the OpenStack charms project. [1] https://review.opendev.org/q/reviewer:nicolas.bock%2540canonical.com+projec… Corey

5 5

[charms] Nominate Brian Haley for charms-stable-maint
by Corey Bryant 21 Nov '23

21 Nov '23

I would like to nominate Brian Haley for charms-stable-maint. Brian has a long history of contributions to OpenStack, is the currentl PTL for the Neutron project, and over the past year, Brian has also been contributing to charm reviews [1]. I have no doubt that Brian will continue providing quality reviews to the OpenStack charms project and will be a great asset in helping the project move forward. [1] https://review.opendev.org/q/reviewer:haleyb.dev%2540gmail.com+project:%255… Thanks, Corey

4 4

Isolating OpenStack Project
by open infra 21 Nov '23

21 Nov '23

Hi, Sorry for cross posting. I need to create a new project and expect to isolate all VMs and underline resources from other projects. I have a default 'admin' project with 20+ workers with a bunch of VMs which are already occupied. Is there a guide for this? My intention is to create a new project and all VMs are only scheduled on reserved workers where no other project is able to schedule workloads on those machines. My Openstack deployment is on top of StarlingX 7.0 We say isolation of complete projects, is it possible to count storage (ceph) as well? Regards, Danishka

2 1

RE: openstack-discuss - Openstack Kolla-ansible Nova Compute - Error | Urgent
by Asma Naz Shariq 20 Nov '23

20 Nov '23

Hi Berndbausch, Thankyou for your reply. I tried to resolve the compute node host in /etc/hosts file through (ip : computenode-virtual-machine). I can check that logs have been changed for nova-compute log on compute node as attached. I am unable to find the solution. Can you check this for me and guide me how to resolve these issues. I would appreciate if you schedule a session for it. T -----Original Message----- From: berndbausch(a)gmail.com <berndbausch(a)gmail.com> Sent: Monday, November 20, 2023 2:24 PM To: 'Asma Naz Shariq' <asma.naz(a)techavenue.biz>; openstack-discuss(a)lists.openstack.org Subject: RE: openstack-discuss -Nova Compute - Error | Urgent The compute node tries to register with Nova on the controller but can't communicate with it. The problem appears to be at RabbitMQ, which says it can't reach the controller. First things you should check: Unsynchronized clocks and incorrect configuration of name resolution on the compute node. -----Original Message----- From: Asma Naz Shariq <asma.naz(a)techavenue.biz> Sent: Monday, November 20, 2023 3:50 PM To: openstack-discuss(a)lists.openstack.org Subject: RE: openstack-discuss -Nova Compute - Error | Urgent Hi Openstack Community, I am deploying Openstack zed release Multinode cluster with 1x Controller and 1x compute and 1x storage. At the time of deployment, I encountered a below error for failed to register the compute service: TASK [nova-cell: Fail if nova-compute service failed to register] *********************************** fatal: [X.X.X.X]: FAILED! => {"changed": false, "msg": "The Nova compute service failed to register itself on the following hosts: computenode-virtual-machine"} fatal: [X.X.X.X]: FAILED! => {"changed": false, "msg": "The Nova compute service failed to register itself on the following hosts: computenode-virtual-machine"} The logs in nova-compute.log at compute node state the ERROR: 2023-11-20 11:54:32.008 7 ERROR oslo. messaging._drivers.impl_rabbit [None req-f8176572-75bf-4c27-a9be-e096cb43e2e3 - - - - - -] Connection failed: [Errno 113] EHOSTUNREACH (retrying in 31.0 seconds): OSError: [Errno 113] EHOSTUNREACH. Can anyone guide me how to resolve this issue? Thanks -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, November 20, 2023 10:16 AM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 61, Issue 70 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe 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. Re: about magnum capi for production (Nguyễn Hữu Khôi) ---------------------------------------------------------------------- Message: 1 Date: Mon, 20 Nov 2023 12:16:11 +0700 From: Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> Subject: Re: about magnum capi for production To: Satish Patel <satish.txt(a)gmail.com> Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <CABAODRfcEA38QRLCpr_DtC5Dbxmr2x=G9nD8hENptAdh0Z0QXg(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="000000000000068859060a8e96ec" Hello guys. This is a doc which is about how to make Magnum CAPI to work with Openstack deployed by Kolla Ansible.. https://github.com/ngyenhuukhoi/openstack-note/blob/main/Magnum%20Cluster%2… Feel free to ask. If I can help, I will. Nguyen Huu Khoi On Mon, Nov 20, 2023 at 12:09 PM Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> wrote: > Hello. > It uses prebuild Ubuntu to provision k8s cluster, > > On Mon, Nov 20, 2023 at 11:47 AM Satish Patel <satish.txt(a)gmail.com> > wrote: > >> Hi Folks, >> >> Tell me if I am wrong. CAPI is just kubernetes images to build k8s >> clusters instead using coreOS and install a bunch of stuff via heat. >> In documentation all I can see are imported images. Reference doc: >> https://vexxhost.github.io/magnum-cluster-api/user/getting-started/ >> >> Do I need to install anything else to make it work? >> >> On Fri, Nov 17, 2023 at 11:30 AM Mohammed Naser <mnaser(a)vexxhost.com> >> wrote: >> >>> Thanks! Happy to see that it is working smoothly 😊 >>> >>> >>> >>> Appreciate any docs, comments or issues. >>> >>> >>> >>> *From: *Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Date: *Friday, November 17, 2023 at 8:57 AM >>> *To: *Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc: *OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject: *Re: about magnum capi for production >>> >>> Hello guys. >>> >>> >>> >>> I have successfully implemented Magnum CAPI on my openstack system. >>> My deployment tool for Openstack is Kolla-Ansible. It worked >>> greatly, I am testing with create, delete and resize k8s cluster. It >>> is smooth when compared with Heat Driver. I will make some docs for new users to use it. >>> >>> >>> >>> Thank you vexxhost.com and contributors for very nice production. >>> >>> >>> >>> I will keep testing and reporting to help it be much better in the >>> future. >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Tue, Nov 14, 2023 at 5:50 AM Nguyễn Hữu Khôi < >>> nguyenhuukhoinw(a)gmail.com> wrote: >>> >>> Hello. >>> >>> I get it now; >>> >>> Thank you very much. >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Nov 13, 2023 at 11:20 PM Mohammed Naser >>> <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there, >>> >>> >>> Nope – it is simply a different driver, so if you try to create >>> Fedora CoreOS clusters – it’ll use the old heat driver. Otherwise, >>> it will use the Cluster API if the image is marked as Ubuntu >>> >>> >>> >>> Thanks! >>> >>> Mohammed >>> >>> >>> >>> *From: *Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Date: *Monday, November 13, 2023 at 1:58 AM >>> *To: *Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc: *OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject: *Re: about magnum capi for production >>> >>> Hello Mohammed, >>> >>> >>> >>> I found that >>> >>> >>> >>> >>> https://vexxhost.github.io/magnum-cluster-api/user/getting-started/# >>> creating >>> >>> >>> >>> I would like to know that if we use cluster api, does it overwrite >>> heat when deploying new k8s cluster from horizon? >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:49 PM Nguyễn Hữu Khôi < >>> nguyenhuukhoinw(a)gmail.com> wrote: >>> >>> Awesome, thank you so much! >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:31 PM Mohammed Naser <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Sounds good, thank you. >>> >>> >>> >>> We also have a channel on the Kubernetes Slack that is relatively >>> active if you need help — it’s in the README :) >>> >>> >>> >>> Thanks! >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Monday, October 30, 2023 8:23:07 AM >>> *To:* Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* Re: about magnum capi for production >>> >>> >>> >>> Hello. >>> >>> Thank you very much. I am planning to use Magnum CAPI for my system. >>> I will feedback later. >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:03 PM Mohammed Naser <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there! >>> >>> >>> >>> It works out of the box since the goal is to have an API that is >>> compatible so that all the ecosystem tools such as Terraform, >>> Ansible, CLI, Horizon all continue to work just fine! >>> >>> >>> >>> We’ve even made some quality of life improvements to the Magnum >>> plugin like letting you download KUBECONFIG from it. >>> >>> >>> >>> Thanks >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Monday, October 30, 2023 1:09:10 AM >>> *To:* Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* Re: about magnum capi for production >>> >>> >>> >>> Hello, >>> >>> >>> >>> Thank you for your sharing, Could you tell me how we use it with >>> Horizon or we need custom Horizon to use Magnum CAPI. >>> >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 11:10 AM Mohammed Naser >>> <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there. >>> >>> >>> >>> We deploy this driver in production in our public cloud as well as >>> many private clouds and as part of Atmosphere and we’ve been fully >>> maintaining it on our side here. >>> >>> >>> >>> Let me know if you have any questions >>> >>> >>> >>> Thanks >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Sunday, October 29, 2023 10:22:22 PM >>> *To:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* about magnum capi for production >>> >>> >>> >>> Hello guys. >>> >>> Could you share with me some experience about using Magnum CAPI in >>> production? >>> >>> >>> >>> https://github.com/vexxhost/magnum-cluster-api >>> >>> >>> >>> Thank you so much. >>> >>> >>> Nguyen Huu Khoi >>> >>>

2 2

[SQLAlchemy 2.x][cloudkitty][ironic-inspector][masakari][murano][trove][sahara][senlin][vitrage][zaqar] No SQLA 2.x support in a few projects
by Thomas Goirand 20 Nov '23

20 Nov '23

Hi, As in Debian, a few packages need SQLAlchemy 2.x, I am working toward adding all SQLA 2.x patches as backport to Bobcat. So far, I managed to backport patches for Heat and Glance, and I'll work on Cinder and Manila next. However, a few packages are failing when using SQLAlchemy 2.x, as per the experimental pseudo-excuse page for sqlalchemy: https://qa.debian.org/excuses.php?experimental=1&package=sqlalchemy So, the list of packages is (in alphabetical order): - cloudkitty - ironic-inspector - masakari - murano - trove - sahara - senlin - vitrage - zaqar These projects need to urgently work toward supporting SQLAlchemy 2.x, both because SQLA 2 will be in distros, and because the OpenStack project requirements needs to move on and bump SQLA to 2.0. Is there anyone working on this? I'm especially interested having Cloudkitty fixed, since we use it in production, but I'm not sure I have the skills for it. Stephen, who wrote the patches for Cinder, Manila, Glance, Heat and Nova at least, doesn't have the time to work on these, he told me on IRC. Cheers, Thomas Goirand (zigo)

4 5

[neutron] Bug Deputy Report November 13-19
by Jakub Libosvar 20 Nov '23

20 Nov '23

Hi all, this is the bug report for Neutron for the week of November 13. There is nothing that requires immediate attention, one critical bug that is handled and about to merge the fix as of now. Critical ———— - Unit test jobs with neutron-lib master(3.9.0) failing https://bugs.launchpad.net/neutron/+bug/2043959 Assigned to: Yatin Fix proposed: https://review.opendev.org/c/openstack/neutron/+/901430 Medium ——— - Some init_router_port steps are unnecessary for new devices https://bugs.launchpad.net/neutron/+bug/2043558 Fix proposed: https://review.opendev.org/c/openstack/neutron/+/900553 Assigned to: Adam Oswick - list_ip_routes should only fetch needed devices https://bugs.launchpad.net/neutron/+bug/2043564 Fix proposed: https://review.opendev.org/c/openstack/neutron/+/900415 Assigned to: Adam Oswick - Creating subnet for exsiting external network is time-comsuming https://bugs.launchpad.net/neutron/+bug/2043761 Assigned to: Liu Fix proposed: https://review.opendev.org/c/openstack/neutron/+/901225 Duplicate ———— - [ovn] no need rpc notifier if no l2 agent https://bugs.launchpad.net/neutron/+bug/2043759 duplicate of https://bugs.launchpad.net/neutron/+bug/1992352

1 0

[publiccloud-sig] Reminder - next meeting November 22nd - 0800 UTC
by Felix Kronlage-Dammers 20 Nov '23

20 Nov '23

Hi everyone, this Wednesday the next meeting of the public cloud sig is going to happen. Since we do every other meeting as a videosession, we’ll be meeting at 0800 UTC here: https://conf.scs.koeln:8443/OIF-public-cloud-sig In parallel we will be on irc on #openstack-operators as well of course. Am very much looking forward to wednesday morning! :) felix -- Felix Kronlage-Dammers Product Owner IaaS & Operations Sovereign Cloud Stack Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

RE: openstack-discuss -Nova Compute - Error | Urgent
by Asma Naz Shariq 20 Nov '23

20 Nov '23

Hi Openstack Community, I am deploying Openstack zed release Multinode cluster with 1x Controller and 1x compute and 1x storage. At the time of deployment, I encountered a below error for failed to register the compute service: TASK [nova-cell: Fail if nova-compute service failed to register] *********************************** fatal: [X.X.X.X]: FAILED! => {"changed": false, "msg": "The Nova compute service failed to register itself on the following hosts: computenode-virtual-machine"} fatal: [X.X.X.X]: FAILED! => {"changed": false, "msg": "The Nova compute service failed to register itself on the following hosts: computenode-virtual-machine"} The logs in nova-compute.log at compute node state the ERROR: 2023-11-20 11:54:32.008 7 ERROR oslo. messaging._drivers.impl_rabbit [None req-f8176572-75bf-4c27-a9be-e096cb43e2e3 - - - - - -] Connection failed: [Errno 113] EHOSTUNREACH (retrying in 31.0 seconds): OSError: [Errno 113] EHOSTUNREACH. Can anyone guide me how to resolve this issue? Thanks -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, November 20, 2023 10:16 AM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 61, Issue 70 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe 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. Re: about magnum capi for production (Nguyễn Hữu Khôi) ---------------------------------------------------------------------- Message: 1 Date: Mon, 20 Nov 2023 12:16:11 +0700 From: Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> Subject: Re: about magnum capi for production To: Satish Patel <satish.txt(a)gmail.com> Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <CABAODRfcEA38QRLCpr_DtC5Dbxmr2x=G9nD8hENptAdh0Z0QXg(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="000000000000068859060a8e96ec" Hello guys. This is a doc which is about how to make Magnum CAPI to work with Openstack deployed by Kolla Ansible.. https://github.com/ngyenhuukhoi/openstack-note/blob/main/Magnum%20Cluster%2… Feel free to ask. If I can help, I will. Nguyen Huu Khoi On Mon, Nov 20, 2023 at 12:09 PM Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> wrote: > Hello. > It uses prebuild Ubuntu to provision k8s cluster, > > On Mon, Nov 20, 2023 at 11:47 AM Satish Patel <satish.txt(a)gmail.com> > wrote: > >> Hi Folks, >> >> Tell me if I am wrong. CAPI is just kubernetes images to build k8s >> clusters instead using coreOS and install a bunch of stuff via heat. >> In documentation all I can see are imported images. Reference doc: >> https://vexxhost.github.io/magnum-cluster-api/user/getting-started/ >> >> Do I need to install anything else to make it work? >> >> On Fri, Nov 17, 2023 at 11:30 AM Mohammed Naser <mnaser(a)vexxhost.com> >> wrote: >> >>> Thanks! Happy to see that it is working smoothly 😊 >>> >>> >>> >>> Appreciate any docs, comments or issues. >>> >>> >>> >>> *From: *Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Date: *Friday, November 17, 2023 at 8:57 AM >>> *To: *Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc: *OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject: *Re: about magnum capi for production >>> >>> Hello guys. >>> >>> >>> >>> I have successfully implemented Magnum CAPI on my openstack system. >>> My deployment tool for Openstack is Kolla-Ansible. It worked >>> greatly, I am testing with create, delete and resize k8s cluster. It >>> is smooth when compared with Heat Driver. I will make some docs for new users to use it. >>> >>> >>> >>> Thank you vexxhost.com and contributors for very nice production. >>> >>> >>> >>> I will keep testing and reporting to help it be much better in the >>> future. >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Tue, Nov 14, 2023 at 5:50 AM Nguyễn Hữu Khôi < >>> nguyenhuukhoinw(a)gmail.com> wrote: >>> >>> Hello. >>> >>> I get it now; >>> >>> Thank you very much. >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Nov 13, 2023 at 11:20 PM Mohammed Naser >>> <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there, >>> >>> >>> Nope – it is simply a different driver, so if you try to create >>> Fedora CoreOS clusters – it’ll use the old heat driver. Otherwise, >>> it will use the Cluster API if the image is marked as Ubuntu >>> >>> >>> >>> Thanks! >>> >>> Mohammed >>> >>> >>> >>> *From: *Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Date: *Monday, November 13, 2023 at 1:58 AM >>> *To: *Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc: *OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject: *Re: about magnum capi for production >>> >>> Hello Mohammed, >>> >>> >>> >>> I found that >>> >>> >>> >>> >>> https://vexxhost.github.io/magnum-cluster-api/user/getting-started/# >>> creating >>> >>> >>> >>> I would like to know that if we use cluster api, does it overwrite >>> heat when deploying new k8s cluster from horizon? >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:49 PM Nguyễn Hữu Khôi < >>> nguyenhuukhoinw(a)gmail.com> wrote: >>> >>> Awesome, thank you so much! >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:31 PM Mohammed Naser <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Sounds good, thank you. >>> >>> >>> >>> We also have a channel on the Kubernetes Slack that is relatively >>> active if you need help — it’s in the README :) >>> >>> >>> >>> Thanks! >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Monday, October 30, 2023 8:23:07 AM >>> *To:* Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* Re: about magnum capi for production >>> >>> >>> >>> Hello. >>> >>> Thank you very much. I am planning to use Magnum CAPI for my system. >>> I will feedback later. >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 7:03 PM Mohammed Naser <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there! >>> >>> >>> >>> It works out of the box since the goal is to have an API that is >>> compatible so that all the ecosystem tools such as Terraform, >>> Ansible, CLI, Horizon all continue to work just fine! >>> >>> >>> >>> We’ve even made some quality of life improvements to the Magnum >>> plugin like letting you download KUBECONFIG from it. >>> >>> >>> >>> Thanks >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Monday, October 30, 2023 1:09:10 AM >>> *To:* Mohammed Naser <mnaser(a)vexxhost.com> >>> *Cc:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* Re: about magnum capi for production >>> >>> >>> >>> Hello, >>> >>> >>> >>> Thank you for your sharing, Could you tell me how we use it with >>> Horizon or we need custom Horizon to use Magnum CAPI. >>> >>> >>> >>> Nguyen Huu Khoi >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2023 at 11:10 AM Mohammed Naser >>> <mnaser(a)vexxhost.com> >>> wrote: >>> >>> Hi there. >>> >>> >>> >>> We deploy this driver in production in our public cloud as well as >>> many private clouds and as part of Atmosphere and we’ve been fully >>> maintaining it on our side here. >>> >>> >>> >>> Let me know if you have any questions >>> >>> >>> >>> Thanks >>> >>> Mohammed >>> >>> >>> >>> Get Outlook for iOS <https://aka.ms/o0ukef> >>> ------------------------------ >>> >>> *From:* Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> >>> *Sent:* Sunday, October 29, 2023 10:22:22 PM >>> *To:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> >>> *Subject:* about magnum capi for production >>> >>> >>> >>> Hello guys. >>> >>> Could you share with me some experience about using Magnum CAPI in >>> production? >>> >>> >>> >>> https://github.com/vexxhost/magnum-cluster-api >>> >>> >>> >>> Thank you so much. >>> >>> >>> Nguyen Huu Khoi >>> >>>

2 1

kolla-toolbox problem in multinode deploy
by Bursztynowski Dariusz 19 Nov '23

19 Nov '23

Hello, I'm facing a problem with kolla-toolbox while deploying zed-ubunu-jammy-aarch64 on a Raspberry Pi cluster using kolla-ansible. I 've built the images myself (on Raspbbery Pi) using kolla-build because images for Ubuntu-aarch64 were missing in standard repos (for Debian/aarch64, stuff installs from quay.io and works fine, but wanted to try out Ubuntu). The error can be seen at the very end of a fragment of the ansible log pasted below. As seen, images in my local repo are reachable (fluentd & kolla-toolbox restart succesfully). But in task "Initializing kolla-toolbox container" three hosts fail with the notification "Container xyz is restarting, wait until the container is running", while the fourth one gives "unable to upgrade to tcp, received 409". Interestingly, in a preceding task "Ensuring config directories have correct owner and permission" (the very first part of the log below), kolla-toolbox check is skipped. I can provide more data, create a bug report in appropriate place, etc. But please instruct me what and where. Best regards, Darek TASK [common : Ensuring config directories have correct owner and permission] ************************************************************************************************ ok: [ost64] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) ok: [ost61] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) skipping: [ost64] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) skipping: [ost61] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost62] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) skipping: [ost62] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost63] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) skipping: [ost63] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost64] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost61] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost62] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) ok: [ost63] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) TASK [common : Copy rabbitmq-env.conf to kolla toolbox] ********************************************************************************************************************** changed: [ost61] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/rabbitmq-env.conf.j2) changed: [ost64] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/rabbitmq-env.conf.j2) changed: [ost62] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/rabbitmq-env.conf.j2) changed: [ost63] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/rabbitmq-env.conf.j2) TASK [common : Copy rabbitmq erl_inetrc to kolla toolbox] ******************************************************************************************************************** changed: [ost64] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/erl_inetrc.j2) changed: [ost61] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/erl_inetrc.j2) changed: [ost62] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/erl_inetrc.j2) changed: [ost63] => (item=/home/ubuntu/labs/ostack/kolla-ansible-zed/share/kolla-ansible/ansible/roles/common/templates/erl_inetrc.j2) TASK [common : Check common containers] ************************************************************************************************************************************** changed: [ost62] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) changed: [ost61] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) changed: [ost64] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) changed: [ost63] => (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/fluentd:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) changed: [ost64] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost61] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost62] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost63] => (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/kolla-toolbox:zed-ubuntu-jammy-aarch64', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost61] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost62] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost64] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) changed: [ost63] => (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': '192.168.2.59:443/openstack.kolla/cron:zed-ubuntu-jammy-aarch64', 'environment': {'KOLLA_LOGROTATE_SCHEDULE': 'daily'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) TASK [common : Creating log volume] ****************************************************************************************************************************************** ok: [ost64] ok: [ost61] ok: [ost62] ok: [ost63] TASK [common : Link kolla_logs volume to /var/log/kolla] ********************************************************************************************************************* changed: [ost64] changed: [ost61] changed: [ost62] changed: [ost63] TASK [common : Flush handlers] *********************************************************************************************************************************************** RUNNING HANDLER [common : Restart fluentd container] ************************************************************************************************************************* changed: [ost63] changed: [ost64] changed: [ost62] changed: [ost61] RUNNING HANDLER [common : Restart kolla-toolbox container] ******************************************************************************************************************* changed: [ost62] changed: [ost61] changed: [ost63] changed: [ost64] RUNNING HANDLER [common : Initializing toolbox container using normal user] ************************************************************************************************** fatal: [ost62]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.064846", "end": "2023-11-19 21:46:19.187519", "msg": "non-zero return code", "rc": 1, "start": "2023-11-19 21:46:19.122673", "stderr": "Error response from daemon: Container 34d4dcc029d807cb70061bcab3f21e1980ec2541b6e116764dab22917d1ba602 is restarting, wait until the container is running", "stderr_lines": ["Error response from daemon: Container 34d4dcc029d807cb70061bcab3f21e1980ec2541b6e116764dab22917d1ba602 is restarting, wait until the container is running"], "stdout": "", "stdout_lines": []} fatal: [ost61]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.170840", "end": "2023-11-19 21:46:19.383867", "msg": "non-zero return code", "rc": 1, "start": "2023-11-19 21:46:19.213027", "stderr": "Error response from daemon: Container fbe3a84809b7b5e23dbc84e896735bcc8c72fbd300b53637061bd305a6bd45eb is restarting, wait until the container is running", "stderr_lines": ["Error response from daemon: Container fbe3a84809b7b5e23dbc84e896735bcc8c72fbd300b53637061bd305a6bd45eb is restarting, wait until the container is running"], "stdout": "", "stdout_lines": []} fatal: [ost63]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.422087", "end": "2023-11-19 21:46:19.579842", "msg": "non-zero return code", "rc": 1, "start": "2023-11-19 21:46:19.157755", "stderr": "Error response from daemon: Container 2b8c1c77cd75d8780ad358407178d0e8d431e22885fc0f58ae1e08e746928d9d is restarting, wait until the container is running", "stderr_lines": ["Error response from daemon: Container 2b8c1c77cd75d8780ad358407178d0e8d431e22885fc0f58ae1e08e746928d9d is restarting, wait until the container is running"], "stdout": "", "stdout_lines": []} fatal: [ost64]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.693630", "end": "2023-11-19 21:46:19.859925", "msg": "non-zero return code", "rc": 1, "start": "2023-11-19 21:46:19.166295", "stderr": "unable to upgrade to tcp, received 409", "stderr_lines": ["unable to upgrade to tcp, received 409"], "stdout": "", "stdout_lines": []}

1 1

[release] Release countdown for week R-19, Nov 20-24
by Herve Beraud 17 Nov '23

17 Nov '23

Development Focus ----------------- We are now past the Caracal-1 milestone. Teams should now be focused on feature development. General Information ------------------- Our next milestone in this development cycle will be Caracal-2, on January 11, 2024. This milestone is when we freeze the list of deliverables that will be included in the 2024.1 Caracal final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/caracal directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- Caracal-2 Milestone: January 11, 2024 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[kolla-ansible][cinder]Backend problems
by Franck VEDEL 16 Nov '23

16 Nov '23

Hi, I come back to a point that caused me a big problem, because I would like to understand something that I did not do correctly. I have a lab with an Openstack (2023.1, kolla-ansible, ubuntu 22-04, 2 nodes) and to show that it works, I start with an LVM backend. Everything is working. I'm adding a Ceph (Pacific) cluster and want to switch from LVM backend to CEPH. If we edit the globals.yml file and make the changes, then the "deploy" command, the LVM backend is still in the list of backends. If we restart the cinder containers, same thing. If we do "stop" then "deploy": same thing. I had to do "stop", "destroy", "deploy" to no longer have the LVM backend but only the CEPH backend. My question is therefore the following: what should we do in this situation? Is there a solution to easily no longer take into account a backend? Thansk for your help Franck

2 2

[kolla][masakari] Deprecating Masakari Support in Kolla-Ansible
by Michał Nasiadka 16 Nov '23

16 Nov '23

Hello, Since the Kolla-Ansible CI jobs for Masakari using 2023.2 have been failing [1] due to some time - we are deprecating Masakari support in Kolla/Kolla-Ansible. As I can see - even the OpenStack bot patches have not been merged in 2023.2 branch [2]. If there is anybody willing to go the extra mile of reviving Masakari stable/2023.2 branch - please reach out - ideally by commenting on the deprecation patch in Gerrit [3]. [1]: https://zuul.opendev.org/t/openstack/builds?job_name=kolla-ansible-ubuntu-m… [2]: https://review.opendev.org/q/project:openstack/masakari+is:open+branch:stab… [3]: https://review.opendev.org/c/openstack/kolla-ansible/+/901193

1 0

[neutron] Drivers meeting cancelled next two weeks
by Brian Haley 16 Nov '23

16 Nov '23

Hello Neutrinos: Due to the lack of agenda, Friday's drivers meeting is cancelled. Have a nice weekend! Also canceling next week's since with the US Thanksgiving holiday we will likely not have quorum. -Brian

1 0

openstack: how can you remove volumen from postgres database on openstack controller?
by kjme001＠gmail.com 16 Nov '23

16 Nov '23

Hello, I have a problem with the volume, I can't delete it, it's still in the deleting state how can you remove volumen from postgres database on openstack controller? Thank you for your help

1 0

[neutron] How to divide a provider network into address segments for different projects to use
by 韩光宇 16 Nov '23

16 Nov '23

Hi, I have a victoria cluster. And all node have two nic. Same to neutron doc[1], one nic is management interface, other is provider interface. Assuming provider network is same as the example in the Neutron deployment doc, which is the 203.0.113.0/24 with gateway 203.0.113.1. I hope use different address segment for different project. For example: project_A: 203.0.113.11,203.0.113.30 project_B: 203.0.113.31,203.0.113.60 project_C: 203.0.113.61,203.0.113.90 I am currently considering one method: Creating different VLAN networks for different projects, but it requires configuring the physical switch ports as trunks. Is there any other way to achieve this? I would prefer to use a flat network. I will appreciate for any help. Best regards, Han Guangyu [1]: https://docs.openstack.org/neutron/latest/install/environment-networking-ob…

1 0