- openstack-discuss - lists.openstack.org

[largescale-sig] Next meeting: Nov. 29, at 16UTC
by Kristin Barrientos 28 Nov '23

28 Nov '23

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 16UTC. Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation

1 0

[tc] Next Technical Committee Meeting Nov 28 1800 UTC
by Jay Faulkner 28 Nov '23

28 Nov '23

Hi all, The next weekly meeting of the Technical Committee is tomorrow, November 28, at 1800 UTC. It will be held in #openstack-tc in OFTC. Agenda - Roll call - Follow up on tracked action items: https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-07-18.00.html - Rosmaita to propose amendment to unmaintained branch resolution allowing a single review group - Rosmaita to email mailing list about progress implementing unmaintained branch resolution - Gate health check - Leaderless projects (gmann) - Implementation of Unmaintained branch statuses - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Upgrade issue between tooz and cinder - https://review.opendev.org/c/openstack/requirements/+/901131 - https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - Declare projects inactive for lack of ...? - Working py311 unit tests - Support for sqla2 - Broken CI since 2023.2 release - Do we want/need to look at specific deliverables or only whole projects? - Open Discussion and Reviews Thanks, Jay Faulkner TC Chair

1 0

[all] North Dakota State University Student Opportunity
by Kendall Nelson 28 Nov '23

28 Nov '23

Hello All! I was contacted by a professor at North Dakota State University wondering if there were projects in OpenStack that students could work on over the course of the coming semester (Jan -May). The students will be nearing the end of their Bachelors degree (this course being one of the final requirements to graduate) so should be relatively knowledgeable and adept and picking up the technologies required if they aren't already versed in them. If you have an idea for a project that you would want to work with a group of students on, please let me know ASAP. I will get you connected with the professor. Project descriptions are due to the professor by December 1st so we only have a couple weeks to get them together. Anyone interested? -Kendall Nelson Senior Upstream Developer Advocate OpenInfra Foundation

1 2

Is "nova-manage db online_data_migrations" cumulative across versions?
by Michel Jouvin 28 Nov '23

28 Nov '23

Hi, We realized that after a Stein -> Train upgrade of our cloud, we forgot to run "nova-manage db online_data_migrations" and did the Train -> Ussuri upgrade. We have not seen any bad side effect but where wondering if the online_data_migrations was cumulative across versions and if running it under Ussuri fixed potential changes related to Stein -> Train upgrade that we forgot to fix right after the Train upgrade. If not, are there things to do to cleanup the situation? Cheers, Michel

2 1

[neutron] Bug Deputy Report Nov 20-26
by Oleg Bondarev 28 Nov '23

28 Nov '23

Hello Neutron Team, Easy week, as usual for me :P 1 bug is undecided, more info requested, others are on track or fixed. Critical ----- - https://bugs.launchpad.net/neutron/+bug/2043959 - Unit test jobs with neutron-lib master(3.9.0) failing - Fix released: https://review.opendev.org/c/openstack/neutron/+/901430 - Fixed by yatinkarel High ----- - https://bugs.launchpad.net/neutron/+bug/2044272 - Inconsistent IGMP configuration across drivers - In progress: https://review.opendev.org/c/openstack/neutron/+/901753 - assigned to lucasagomes Medium ----- - https://bugs.launchpad.net/neutron/+bug/2044171 - External shared networks may not be seen by other projects - Invalid, not relevant for master ( https://review.opendev.org/c/openstack/neutron-lib/+/901565 closed) - handled by libosvar - https://bugs.launchpad.net/neutron/+bug/2044484 - Enabling DHCP after setting the subnet's 'enable_dhcp' to false does not recreate the metadata namespace - In progress https://review.opendev.org/c/openstack/neutron/+/901812 - assigned to huanghailun Undecided ----- - https://bugs.launchpad.net/neutron/+bug/2044215 - dns: Keyword is replaced by project_name instead of project_id - Incomplete, more info requested Thanks, Oleg

1 0

[cinder][kolla][OpenstackAnsible] 2023.2 Bobcat cycle-trailing release deadline
by Elõd Illés 28 Nov '23

28 Nov '23

Hello teams with trailing projects, The 2023.2 Bobcat cycle-trailing release deadline is in ~1 months [1], and all projects following the cycle-trailing release model must release their 2023.2 Bobcat deliverables by December 7th, 2023. The following trailing projects haven't been released yet for 2023.2 Bobcat (aside the release candidates versions if exists). Cinder team's deliverables: - cinderlib OSA team's deliverables: - openstack-ansible-roles - openstack-ansible Kolla team's deliverables: - kayobe - kolla - kolla-ansible - ansible-collection-kolla This is just a friendly reminder to allow you to release these projects in time. Do not hesitate to ping us if you have any questions or concerns. [1] https://releases.openstack.org/caracal/schedule.html#c-cycle-trail Thanks, Előd irc: elodilles @ #openstack-release

1 1

[release][puppet] Can we retire old stable branches ?
by Takashi Kajinami 27 Nov '23

27 Nov '23

Hi release team, The puppet-ceph repository in Puppet OpenStack project currently follows the independent release model. This is because the module is more aligned with Ceph releases rather than OpenStack release. In the past, we created a stable branches per Ceph stable release and we currently have the following three stable branches. - stable/jewel - stable/mimic - stable/luminous However we no longer use these branches because the old stable branches (eg train) using these old releases are already EOL. So I'm wondering if someone from the release team can create -eol tag from the latest commits and remove these branches. Ideally we may be able to create a release from the latest commits, but I doublt we can merge any patches cleanly to these ancient branches so I tend to just add -eol tag instead, assuming no one may need releases for these old contents. Thank you, Takashi Kajinami

2 1

[all] [taskflow] asyncore is removed in Python 3.12
by Corey Bryant 27 Nov '23

27 Nov '23

Hi All, As noted in the following bug, taskflow uses asyncore, which is removed in Python 3.12. tasklfow needs to be switched to asyncio as a result. Does anyone happen to be working on this? https://bugs.launchpad.net/ubuntu/+source/python-taskflow/+bug/2024588 Thanks, Corey

5 7

[publiccloud-sig] Reminder - next meeting November 29th - 0800 UTC
by Felix Kronlage-Dammers 27 Nov '23

27 Nov '23

Hi everyone, since we’re switching to even weeks with the publiccloud-sig meeting (as also announced last week[1] in my summary), I’m happy to share the reminder for this weeks meeting :) This Wednesday the next meeting of the public cloud sig is going to happen. We meet on IRC in #openstack-operators at 0800 UTC. See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG felix [1] <url: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…> -- 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

[tripleo] stepping down from TripleO core
by Takashi Kajinami 27 Nov '23

27 Nov '23

Hello, As you might know or notice, I recently joined a different company, and my focus has been changed. I'm still involved in the OpenStack community but I may no longer be involved in TripleO. To clarify my status I've removed myself from TripleO core. # Please be aware that I'm removing myself from release liason, # someone from the core team might want to replace me, though # I don't think there may be multiple releases created in the future. I'd like to thank all members in the team (current members and ex-menmbers) for your great collaboration and work in the project. Thank you, Takashi Kajinami

3 2

[puppet] Proposing EOL of stable/wallaby and xena
by Takashi Kajinami 24 Nov '23

24 Nov '23

Hello, Some of you may know this but currently CentOS 8 Stream integration jobs in stable branches are all broken. I've looked into some of these failures but tasks randomly get stuck which eventually caused timeout and I've not yet found any potential cause. While we may be able to spend some time to dig into the problem, I'm wondering if anyone still requires wallaby and xena which support CentOS 8 Stream. Most of the backports submitted to these old branches were for TripleO,but I've seen some patches indicating TripleO wallaby is being retired so I doubt anyone still need keeping these branches open for backports. Please let me know if you have any concern about the proposed EOL and are interested in fixing these jobs. The stable/yoga branch has already passed the EM phase, so is another candidate for EOL but my intention is to keep it for now and re-consider its EOL early next year. We may have to make all CentOS 8 jobs non-voting, though. (We have CentOS 9 jobs in this branch). Thank you, Takashi Kajinami

2 2

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

24 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 24 Nov '23

24 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 23 Nov '23

23 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 23 Nov '23

23 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 23 Nov '23

23 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 22 Nov '23

22 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 22 Nov '23

22 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 22 Nov '23

22 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 22 Nov '23

22 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 21 Nov '23

21 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