February 2024 - openstack-discuss

[octavia] Purging ERROR'ed amphora and load balancers stuck in transitional states
by Paul Browne 16 Feb '24

16 Feb '24

Hello Octavia users, For a while I've been trying to find a systematic way to remove Octavia LBs+Amphora that have become stuck in ERROR or transitional PENDING_* states ; $ openstack loadbalancer amphora list -f value | grep ERROR a2323f14-3aaa-418a-8249-111aaa9c21fe 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe ERROR MASTER 10.8.0.242 192.168.3.247 e5b236ba-e7ee-4ed7-9f58-57ce7a408489 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe ERROR BACKUP 10.8.0.190 192.168.3.247 6b556f28-93c9-49dd-b6ee-4379288e7957 d5e402fe-2c4b-49af-a700-532cb408cee5 ERROR MASTER 10.8.0.39 192.168.3.126 c669db5d-8686-4d5c-9e95-e02030b34301 d5e402fe-2c4b-49af-a700-532cb408cee5 ERROR BACKUP 10.8.0.174 192.168.3.126 $ openstack loadbalancer list -f value | grep -vi active 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe k8s-clusterapi-cluster-default-ci-6386871107-kube-upgrade-kubeapi 3a06571936a0424bb40bc5c672c4ccb1 192.168.3.247 PENDING_UPDATE amphora d5e402fe-2c4b-49af-a700-532cb408cee5 k8s-clusterapi-cluster-default-ci-6386871107-latest-kubeapi 3a06571936a0424bb40bc5c672c4ccb1 192.168.3.126 PENDING_DELETE amphora These resources are marked immutable and so cannot be failed over or deleted; $ openstack loadbalancer amphora failover a2323f14-3aaa-418a-8249-111aaa9c21fe Load Balancer 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe is immutable and cannot be updated. (HTTP 409) (Request-ID: req-6e66c4e8-c3d3-4549-a03c-367017c8c8b3) $ openstack loadbalancer failover 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe Invalid state PENDING_UPDATE of loadbalancer resource 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe (HTTP 409) (Request-ID: req-84b44212-e7a8-4101-a16f-18c774c0577e) The backing Nova instances for these Amphora do seem to exist and be in good working order. Is there any API way to purge these out of Octavia's service state, or would (very careful) DB hackery be required here? Many thanks, Paul Browne ******************* Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pfb29(a)cam.ac.uk<mailto:pfb29@cam.ac.uk> Tel: 0044-1223-746548 *******************

3 4

[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 15 Feb '24

15 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 15 Feb '24

15 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