- openstack-discuss - lists.openstack.org

[publiccloud-sig] Reminder - next meeting February 21st - 0800 UTC
by Felix Kronlage-Dammers 20 Feb '24

20 Feb '24

Hi everyone, This Wednesday (February 21st) the next meeting of the public cloud sig is going to happen. Since the majority of participants in the sessions started to like the videocalls, we’ll be doing this as a videocall again. We’ll be meeting at 0800 UTC here: https://conf.scs.koeln:8443/OIF-public-cloud-sig See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG We’ve had a lively discussion couple of weeks ago and Artem (gtema) did make a good head start in regards to sketching out the discovery service. I’m fairly certain that this will be part of tomorrow’s meeting ;) See you tomorrow! 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 ansible all in one VM instance creation fails
by KK CHN 20 Feb '24

20 Feb '24

List 1. I followed the tutorial https://kifarunix.com/deploy-all-in-one-openstack-with- kolla-ansible-on-ubuntu-22-04/?expand_article=1 and able to get things up and running upto horizon dashboard login.( with the runinit once script ) which brings the default cirros image and default flavors and default networks. 2. When I tried to create a cirros instance either through the horizon dashboard or through openstack CLI the instance not up and running resulting in error . 3. NOTE: This kolla-ansible-all-in-one I am trying on a VM( Ubuntu22.04 VM deployed on ESXi 7.0 host). 4. Do I need to edit or enable something on the ESXi host machine or the Ubuntu base VM where I am trying the all-in-one installation ? ERROR as follows 2024-02-19 22:14:17.881 7 ERROR nova.compute.manager [instance: ca98a487-8214-4b41-bdbc-6eed0a9390cf] libvirt.libvirtError: unsupported configuration: Emulator '/usr/bin/qemu-system-x86_64' does not support virt type 'kvm' 2024-02-19 22:14:17.881 7 ERROR nova.compute.manager [instance: ca98a487-8214-4b41-bdbc-6eed0a9390cf] 2024-02-19 22:14:17.885 7 INFO os_vif [None req-133b5da1-40ad-45d4-af54-7e4fa299aeed 76b826e348324acb8ebf005721c0213a e83c8d350df24c51851c44bf6d6fc7d5 - - default default] Successfully unplugged vif VIFBridge(active=False,address=fa:16:3e:cc:95:02,bridge_name='qbr40ec669f-fc',has_traffic_filtering=True,id=40ec669f-fc19-4c1e-af03-5180819758a6,network=Network(db91c3c3-d0ca-41d1-9497-6511e79f2b10),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap40ec669f-fc') 2024-02-19 22:14:18.176 7 INFO nova.compute.manager [None req-133b5da1-40ad-45d4-af54-7e4fa299aeed 76b826e348324acb8ebf005721c0213a e83c8d350df24c51851c44bf6d6fc7d5 - - default default] [instance: ca98a487-8214-4b41-bdbc-6eed0a9390cf] Took 0.29 seconds to deallocate network for instance. 2024-02-19 22:14:18.280 7 INFO nova.scheduler.client.report [None req-133b5da1-40ad-45d4-af54-7e4fa299aeed 76b826e348324acb8ebf005721c0213a e83c8d350df24c51851c44bf6d6fc7d5 - - default default] Deleted allocations for instance ca98a487-8214-4b41-bdbc-6eed0a9390cf 2024-02-19 22:14:20.426 7 WARNING nova.virt.libvirt.driver [None req-00027f3f-4666-4f97-a672-085105be0946 - - - - - -] This host appears to have multiple sockets per NUMA node. The `socket` PCI NUMA affinity will not be supported. 2024-02-19 22:15:20.419 7 WARNING nova.virt.libvirt.driver [None req-00027f3f-4666-4f97-a672-085105be0946 - - - - - -] This host appears to have multiple sockets per NUMA node. The `socket` PCI NUMA affinity will not be supported. root@ubuntu-VM:/home/ubuntu# Greetings Krish

1 1

[tc] Next Meeting Tomorrow, Feb 20, 1800 UTC
by Jay Faulkner 20 Feb '24

20 Feb '24

Hi all, the next weekly meeting of the OpenStack Technical Committee is tomorrow, Feb 20, at 1800 UTC. The proposed agenda is: Agenda - Roll call - Follow up on tracked action items - Gate health check - Implementation of Unmaintained branch statuses - Testing runtime for 2024.2 release (gmann) - https://review.opendev.org/c/openstack/governance/+/908862 - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews Thanks, Jay Faulkner OpenStack TC Chair

1 0

Request for support for the openstack trial
by Richard Buregeya 20 Feb '24

20 Feb '24

Hello team, My nova-compute is in disable mode and here are the logs and nova-compute is down... 2024-02-19 10:49:43.131 7 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 638, in init_host 2024-02-19 10:49:43.131 7 ERROR oslo_service.service self._do_quality_warnings() 2024-02-19 10:49:43.131 7 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 604, in _do_quality_warnings 2024-02-19 10:49:43.131 7 ERROR oslo_service.service caps = self._host.get_capabilities() 2024-02-19 10:49:43.131 7 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line 705, in get_capabilities 2024-02-19 10:49:43.131 7 ERROR oslo_service.service xmlstr = self.get_connection().getCapabilities() 2024-02-19 10:49:43.131 7 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line 516, in get_connection 2024-02-19 10:49:43.131 7 ERROR oslo_service.service raise exception.HypervisorUnavailable(host=CONF.host) 2024-02-19 10:49:43.131 7 ERROR oslo_service.service HypervisorUnavailable: Connection to the hypervisor is broken on host: node001 2024-02-19 10:49:43.131 7 ERROR oslo_service.service Regards Richard.

2 1

Removal of boto from Debian
by Thomas Goirand 20 Feb '24

20 Feb '24

Hi, There's currently an ongoing effort to remove boto from Debian. The reason is: there's boto3, and boto is not maintained anymore. These a number of packages that are still using it. Affected packages in the OpenStack world are (at least for Bobcat, we'll see for Caracal): - glance-store - swift - heat-cfntools This IMO requires immediate action from the concerned team, to hopefully get rid of this requirement before Caracal is released. My excuses in advance if the work has already been done. Cheers, Thomas Goirand (zigo)

2 1

[kolla-ansible][Antelope][Senlin] Stop In Progress Updates
by Devin Patterson 19 Feb '24

19 Feb '24

Hello, We are using Senlin to create scaling groups and monitor VM health as well as do rolling updates. Does anyone know of a way to stop an in progress rolling update? For example, if we trigger Senlin to use a new profile, can we stop the update once it is started? Even better, is there a way to connect Senlin health policies to the rolling updates to stop the update if previous node health fails? Regards, Devin

1 0

[neutron] bug deputy report for week of 2024-02-12
by Bence Romsics 19 Feb '24

19 Feb '24

Hi All, We had a handful of new bug reports last week: gate-failure: * https://bugs.launchpad.net/neutron/+bug/2052915 "neutron-ovs-grenade-multinode" and "neutron-ovn-grenade-multinode" failing in 2023.1 and Zed proposed fixes: https://review.opendev.org/q/topic:bug/2052915 * https://bugs.launchpad.net/neutron/+bug/2053227 [ovn-octavia-provider] ovn-octavia-provider-functional-master is broken by ovn build failure proposed fix: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/909074 unassigned: * https://bugs.launchpad.net/neutron/+bug/2053274 [ovn] mtu for metadata veth interface is not set high: * https://bugs.launchpad.net/neutron/+bug/2052937 Policy: binding operations are prohibited for service role proposed fixes: https://review.opendev.org/q/topic:bug/2052937 * https://bugs.launchpad.net/neutron/+bug/2054203 Default flag change in netaddr breaks (at least) unit tests proposed fix: https://review.opendev.org/c/openstack/neutron/+/909317 rfe: * https://bugs.launchpad.net/neutron/+bug/2052906 [RFE] OpenVSwitch HTB QoS not efficient for a lot of interfaces Cheers, Bence

1 0

[Cinder] PTL non-candidacy
by Rajat Dhasmana 19 Feb '24

19 Feb '24

Hello everyone, I'm sending this email out to let everyone know that I will not be running for PTL for the Cinder project during the 2024.2 (Dalmatian) cycle. I started my PTL journey with the Zed cycle and it's been a great experience leading the Cinder project for 4 cycles. I think it is time for someone else to step up and bring their insights into the PTL tasks since I believe a new perspective will surely benefit the project. I would like to thank the Cinder team for their support, without which, it would have been a very hard task to accomplish. Last but not the least, Brian and Jay (former Cinder PTLs) helped out a lot to run things smoothly and in making complex decisions so a special thanks for all their help and support. Thanks Rajat Dhasmana

7 6

[all] Upcoming incompatible changes in netaddr 1.0.x
by Takashi Kajinami 18 Feb '24

18 Feb '24

Hello, While looking into some test failures in an attempt to bump netaddr from 0.10.x to 1.0.x[1], we learned that there are a few changes in netaddr 10.0.x impacting our current usage. I'll attempt to summarize a few important ones in this email, and would like to ask each team to look into your project to assess the impacts caused by these changes. 1. INET_PTON (more restrictive check by default) is used by default In 1.0.1, all features dependent on ip address parsing uses INET_PTON by default instead of INET_ATON. With this change a few "strange" address values such as '192.0' or even '1' is no longer accepted. In case you want to restore the previous behavior then you have to add flags=netaddr.core.INET_ATON to each call. See [2] for example. This is caught in neutron unit tests[4] but my need to be further check in libraries handling IP addresses. 2. valid_ipvN raises exception for non-string value. Previously netaddr.valid_ipv(4|6) returned False for non-string values such as None. This was (unintentionally) changed in 1.0.x. I proposed restoring the old behavior but the maintainer preferred strictness about the input type, and we eventually agreed on throwing more explicit exception (TypeError). At this moment this affects only manila unit tests which I'm fixing by [5], but I wonder if there is any specific use case in any project dependent on the previous behavior. If so then probably we can add our own logic to handle non-string value, for example in oslo_utils.netutils. 3. A few deprecated interfaces are removed. At this moment I'm aware of only impact on heat (caused by implicit_prefix removed), but double-check my be better. Thank you, Takashi [1] https://review.opendev.org/c/openstack/requirements/+/909300 [2] https://review.opendev.org/c/openstack/oslo.utils/+/909307 [3] https://github.com/netaddr/netaddr/issues/368 [4] https://bugs.launchpad.net/neutron/+bug/2054203 [5] https://review.opendev.org/c/openstack/manila/+/909298 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[kolla][rabbitmq]: Error when ensuring rabbitmq users exists
by Winicius Allan 18 Feb '24

18 Feb '24

Hello o/, After an upgrade of nodes packages, we have been facing a problem when reconfiguring RabbitMQ and Nova. In the tasks that ensures RabbitMQ users exists the output of task is: FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (5 retries left). FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (4 retries left). FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (3 retries left). FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (2 retries left). FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (1 retries left). I've already tried to redeploy rabbit and reconfigure after that, but does not work neither Anyone can help? I'm unable to perform any operation in my environment. Thanks! Winicius.

3 6

How to enable or disable a hypervisor via openstack python module
by Saeed 17 Feb '24

17 Feb '24

Hello, I use this module to find if any hypervisors are disabled: https://github.com/openstack/openstacksdk I can find and see if any hypervisor is disabled and see the reason, but I didn't find any docs about how to enable (or even disable) a hypervisor. This is my code to find disabled hypervisors: import openstack > regions = ['region1', 'region2', 'region3'] > openstack.enable_logging(debug=False)disabled_hypervisors = [] > for region in regions: > conn = openstack.connect(cloud=region) # clouds.yaml > for server in conn.compute.hypervisors(details=True): > a = server.to_dict() > if a['status'] == 'disabled' and > a['service_details']['disabled_reason'] != None: > disabled_hypervisors.append({'name': a['name'], 'ip': > a['host_ip'], 'disabled_reason': a['service_details']['disabled_reason']}) Regards, Saeed

2 2

Subject: [tc][election] gouthamr's TC Candidacy for 2024.2
by Goutham Pacha Ravi 17 Feb '24

17 Feb '24

Hello Stackers, I'm expressing my interest to join the OpenStack Technical Committee with your acceptance. I have had a long and exciting stint with OpenStack; and can probably claim to have evolved along with it. I began my active contribution journey in the Liberty release, and have had the pleasure to build a community around the OpenStack Manila project for most of this time. In many ways, my efforts here were rooted in the core ideology of this community: the fervent desire for openness that drives each decision [1]. I coupled that with my own penchant for mentoring; the result of which is a vast number of new contributors in the form of Outreachy, Google Summer of Code, Grace Hopper Celebrations, and student projects with numerous universities. All of this was done with similarly motivated fellow conspirators. This experience has helped me foster the diversity of thought in our community, and provided sustained energy to a small group of people chopping wood and carrying water around software whose relevance transcends hype cycles. I now wish to employ this energy and experience in service as a member of the TC. I set out the following goals to drive within the team: * Sustain and improve collaboration: I wish to extend TC's charter on investment opportunities with the "formal" mentorship engagements we have had in the community, including but not limited to Outreachy, GSOC, GSOD, GHC and university projects. I've new ideas here, and feel like a TC member can add a ton of excitement to this niche area of people enthusiastic to do this year on year. * Commit to a closer collaboration with adjacent communities: I am inspired by our willingness to engage with maintainers of software that work with OpenStack. My pitch is for us to identify TC representation within projects like Ceph, Kubernetes and others for active and periodic communication. * Drive long running efforts to completion: prime examples here are efforts for coherence for operators and users: Unified CLI, Limits, and Secure RBAC defaults. Thank you for considering my candidacy. I look forward to the opportunity to serve our community and contribute to the continued success of OpenStack. Warm regards, Goutham Pacha Ravi (gouthamr) [1] https://openinfra.dev/four-opens/ [2] https://review.opendev.org/c/openstack/election/+/909239

1 0

[manila][ceph] Collab Review/design discussion for Cback Share Backup driver
by Goutham Pacha Ravi 17 Feb '24

17 Feb '24

Hello Zorillas and other interested stackers, Folks at CERN have been working with Manila's share backup feature and are authoring a new backup driver for CBack [1]. We are hosting a call to dive into the implementation and discuss how the feature works with CephFS shared file systems. If this is of interest to you, please join us on: Date: 22nd February 2024 Time: 1600 UTC Location: https://meetpad.opendev.org/manila-caracal-cback-driver Etherpad: https://etherpad.opendev.org/manila-caracal-cback-driver <https://meetpad.opendev.org/manila-caracal-cback-driver> [1] https://cds.cern.ch/record/2767135?ln=en Thanks, Goutham

1 0

[ironic] PTL non-candidacy
by Jay Faulkner 17 Feb '24

17 Feb '24

As I've mentioned in IRC, and various times throughout the cycle -- I do not intend to run for PTL of Ironic for Dalmation. I encourage Ironic contributors to run for PTL and will gladly offer any assistance to whomever is elected. Thanks, Jay Faulkner Ironic PTL

1 0

[release] Release countdown for week R-6, Feb 19-23
by Elõd Illés 16 Feb '24

16 Feb '24

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on February 22nd, 2024. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2024.1 branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (February 29th, 2024) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, February 29th, 2024. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/2024.1 branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/2024.1 branches are cut for a repo, the ability to approve any necessary backports into those branches for 2024.1 Caracal will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 22nd, 2024 (R-6 week) Client library freeze: February 29th, 2024 (R-5 week) Caracal-3 milestone: February 29th, 2024 (R-5 week) Cycle Highlights Due: March 7th, 2024 (R-4 week) 2024.1 Caracal final release: April 3rd, 2024 Dalmatian PTG: April 8-12, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[keystone] Reviewathon canceled
by Dave Wilde 16 Feb '24

16 Feb '24

I’m on PTO today and won’t be able to host the reviewathon so I’m cancelling it. Please reach out if you need anything. Thanks! /Dave

1 0

[Cinder] User visible information in Volume Types
by Josephine Seifert 16 Feb '24

16 Feb '24

Hi, as discussed in the Cinder midcycle meeting: I would like to add something to the volume types to be able to see certain information. I am also working out a spec for this, but here are the options I have in mind/we have discussed yesterday: Use Cases -------------- As a non-admin user creating a volume I would like to see various information about the volume type. Some of them are already available (e.g. multiattach). While others are either not available at all or not available for non-admin users. Two of those information are: 1. Whether a volume type can be used to create encrypted volumes 2. Whether a volume type creates replicated volumes, either through Cinder or through a configured backend like ceph The first information comes from the encryption type within the volume, that is only accessible for the admin role. The second information can either be set and directly seen in the volume type extra_specs or is indirectly a part of the configuration of the backend. There might be other use cases, where an operator wants to set certain information about the volume type. As there are more and more tools that automatically create IaaS resources, those information should be accessible in a uniform way. Possible changes ------------------------ Here are a few ways to solve this problem. 1. Using the already existing user facing "properties" field. Administrators can already set key,value pairs here and user visible extra_specs can be seen in this field. This would lead to a problem in the volume scheduler, as EVERY input is going into the extra_specs table and the scheduler will try to fulfill every key=value pair a volume type requests when looking for a fitting backend for the volume. 1.a) This could be solved in creating a whitelist or blacklist, so not every extra_spec is checked in the scheduler. Either all only informational extra_specs should be ignored or a list of extra_specs, that will be checked could be created. 1.b) Another option would be to create another database table: metadata and put every key=value pair in there at the time of their creation, that should not be used in the scheduling process. The "properties" field would then be build in the API from a merge of the extra_specs and the metadata table. (This may also prevent the volume type from getting unusable, when some adds a key=value pair to the "properties", that is not meant for the scheduler - right now this would break the volume creation process) 2. Creating a new "metadata" field, that will contain such user facing information. This would include API changes to address the new view of the volume type as well as a new API endpoint to set information as key value pairs for this metadata field. A new database table for those metadata is also necessary. The downside on this is, it might confuse people, as user facing information would be in two different fields: "propertied" for multiattach, replication_enabled and AZ, but "metadata" for some things like encryption_enabled and backend_replication, etc... It would also not solve the problem, that key-value pairs not meant for scheduling purposes can still be put into the properties/extra_specs and will only lead to Errors in the scheduling process later on. 3. Facing use cases individually: 3.a) Information about whether a volume type creates encrypted volumes or not could be calculated in the API calls for list/show volume types from the presence of an encryption type. The information would be shown in the "properties" field. This would be a very minimal patch, but will not solve other use cases, that would benefit from user facing information. 3.b) Creating an extra field for the encryption in the volume type table, that is automatically set when creating or deleting an encryption type. This would need a database change and a change of the view of the volume_types. 3.c) Looking into the different drivers and how they handle internal configurable replication and whether there are ways to let OpenStack know this and propagate it to users. This is very hard to achieve, maybe even impossible without input from an operator, who configured the backends and volume types. ----- If you have any other options in mind or want to state your opinion on this, please let me know. greetings Josephine (Luzi)

2 2

Reg cinder because Iscsi and TGT giving problems
by Rohit Sansiya 16 Feb '24

16 Feb '24

Hello all, i want a new cinder because iscsi and tgt giving some problem. tell me how to configure give some handouts. version: openstack yoga os: ubuntu 20.04 multi -node i m working please help its urgent Your message is ready to be sent with the following file or link attachments: Rohit Sansiya https://sites.google.com/view/rpgcloud/research-india Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled.

1 0

How to enable or disable a hypervisor via openstack python module
by Saeed 16 Feb '24

16 Feb '24

Hello, I use this module to find if any hypervisors are disabled: https://github.com/openstack/openstacksdk I can find and see if any hypervisor is disabled and see the reason, but I didn't find any docs about how to enable (or even disable) a hypervisor. This is my code to find disabled hypervisors: import openstack > regions = ['region1', 'region2', 'region3'] > openstack.enable_logging(debug=False)disabled_hypervisors = [] > for region in regions: > conn = openstack.connect(cloud=region) # clouds.yaml > for server in conn.compute.hypervisors(details=True): > a = server.to_dict() > if a['status'] == 'disabled' and > a['service_details']['disabled_reason'] != None: > disabled_hypervisors.append({'name': a['name'], 'ip': > a['host_ip'], 'disabled_reason': a['service_details']['disabled_reason']}) Regards, Saeed

1 0

OpenStack SAML Integration and Application Cred, CLI usage
by Nazan Cengiz 16 Feb '24

16 Feb '24

Hello I want to do SAML integration in OpenStack keystone. How can SAML integration be done? How can I use Application credential and OpenStack CLI with SAML-OpenStack integration? Environment version openstack:stein keystone: 15.0.1-0ubuntu1~cloud0 keystone federation: SAML Authentication Flows: SAML2.0 WebSSO Apache authentication method: Mellon

1 0

[neutron] qrouter namespace missing in controllers - opensack ussuri
by keshav bareja 16 Feb '24

16 Feb '24

Hi Team We are experiencing an issue of reachability in some of the projects, instances in the project are not reachable. It is a project specific issue. I tried to check router details and could observe . For the project having issues, I checked the router and could see that the qrouter namespace is not present in the command "ip netns" in any of the controllers. Problem started after a reboot of one controller. Do any one has faced a similar issue and any suggestions to recover this? Regards Keshav Bareja

2 2

[Kolla][Ironic] Ironic node validation failed
by Jayesh Chaudhari 16 Feb '24

16 Feb '24

Hi All, I am following the below document for implementing Ironic in my Kolla-Ansible Cloud which is on yoga version. https://docs.openstack.org/kolla-ansible/yoga/reference/bare-metal/ironic-g… I can add a baremetal node with this in the "baremetal node list" and make it available. But when I am trying to create a nova server it fails trying to find the host. I tried to troubleshoot and find that "openstack baremetal node validate <nodeid>" command shows 1. bios - Driver ipmi does not support bios (disabled or not implemented) 2. console - Driver ipmi does not support console (disabled or not implemented) 3. deploy - Node failed to validate deploy image info. Some parameters were missing. Missing are ['instance_info.image_source'] 4. inspect - Driver ipmi does not support inspect (disabled or not implemented) 5. raid - Driver ipmi does not support raid (disabled or not implemented) 6. rescue - Driver ipmi does not support rescue (disabled or not implemented) Can you please guide me with documentation for setting these options. Or correct me if I am missing anything. Also above documents show steps to create deploy-vmlinuz and deploy-initrd only. Please guide me for steps creating deploy_kernel and deploy_ramdisk. Thanks, Jayesh

3 4

Encountering a live migration issue on Kolla Ansible Deployment
by khurshidsx＠gmail.com 15 Feb '24

15 Feb '24

Hello all, I recently set up a cluster using Kolla Ansible, but I'm encountering a live migration issue. I would appreciate any advice or insights you can provide. Error Message is rule:create_port_binding is disallowed by policy Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee'] Here are some logs: 2024-01-25 04:55:51.599 23 INFO neutron.api.v2.resource [req-a380e1bc-a94b-4935-be0d-76fcc94becc4 req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee 636854b888d7441eafcd21255e1378f1 b07c4b6d7b2241c187ed84f30b163817 - - default default] create failed (client error): Access was denied to this resource. 2024-01-25 04:55:51.601 23 INFO neutron.wsgi [req-a380e1bc-a94b-4935-be0d-76fcc94becc4 req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee 636854b888d7441eafcd21255e1378f1 b07c4b6d7b2241c187ed84f30b163817 - - default default] 192.168.252.254,192.168.252.12 "POST /v2.0/ports/e70fab29-d0cd-4db4-8fbc-a572da1bff64/bindings HTTP/1.1" status: 403 len: 308 time: 0.0207033 Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee'] 2024-01-25 04:55:51.815 19 ERROR nova.conductor.manager Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee'] 2024-01-25 04:55:51.815 19 ERROR nova.conductor.manager Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee'] Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee']: nova.exception.Forbidden: rule:create_port_binding is disallowed by policy

3 5

The issue of not being able to create application credentials with federated users
by Nazan Cengiz 15 Feb '24

15 Feb '24

Hello, I implemented Cyberark integration in OpenStack. I used the SAML protocol during the integration. I created user groups in Active Directory and defined these groups in Openstack. I added users to the created groups. My goal is to send requests to the OpenStack API by creating application credentials. However, the federated user added to the groups created as a result of the Cyberark integration cannot create and use application credentials. It gives the following error: Unable to create application credential. Inventory openstack:stein keystone: 15.0.1-0ubuntu1~cloud0 Can you help me solve this problem? Thanks

1 0

[cinder] 2024.1 Caracal Midcycle-2 Summary
by Rajat Dhasmana 15 Feb '24

15 Feb '24

Hello Argonauts, Following is the summary of the 2024.1 Caracal Midcycle-2 held on 14th February, 2024. https://wiki.openstack.org/wiki/CinderCaracalMidCycleSummary#Session_Two:_R… Please go through the discussion points and action items assigned to you and let me know if any modification is required. Thanks Rajat Dhasmana

1 0