- openstack-discuss - lists.openstack.org

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

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

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

15 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

[elections][tc] Self-nomination for a TC seat
by Sylvain Bauza 15 Feb '24

15 Feb '24

Howdy folks, That's now been a long time I'm thinking about running for a TC seat but I never really thought about it until today. Now, I think this is the best time for me asking you to accept me as a TC member and I'll explain why below. First, in case you don't know me yet, I'm Sylvain Bauza (bauzas on IRC), working on OpenStack since... wow, 11 years already ? I first started to test OpenStack Diablo and Essex for a SME company but eventually moved to another (and then another) position and became contributor, first to the Blazar (that time named Climate) project and then Nova for 10 years now, eventually becoming nova-core and PTL. Time flies and now I'm still there, happy with what OpenStack became. Of course, it changed. But honestly, I haven't seen more operators using it previously than now, which means that we succeeded as a team to make OpenStack useful for our users. As a Nova PTL for the previous cycles, I know how important it is to get feedback from our operators and how much this is crucial to provide help for them. The last discussions I had with the community led to me think that this motto needs to be addressed as a whole and not only on a per-project basis, hence convincing myself that I should run for a TC seat. As someone evolving from a operations position in a SME company to a core developer working with large cloud deployments, I wish I could help the TC driving some efforts into shortening the feedback loop within the community. I'd also want to help the TC provide some guidance on the new SLURP release cadence model to all the projects so that we could really achieve a skip-release upgrade that would benefit to our operators. There are a couple of other stuff I do really care and I wish to help them. CI gate stability is one of them. Having transient failures close to a milestone is not a good experience for us and we need to really address those failures as top priorities when they occur. We should somehow recognize the very fews who dedicate time on chasing those issues and fixing them, as their contributors are mostly valuable, since not a single code of code can't merge when a gate is down. Maintaining our code is another important aspect to me. Recent experiences on not-so-well-maintained dependencies led us force to evaluate all the options and those decisions aren't easy to make. As someone caring about maintaining our code for stable releases, I wish I could help the TC to correctly identify risks and benefits of breaking changes and evaluate the impact it may have on our feature delivery. Enough talk, I'll end up here, saying that after those 10 years in the community, I'm still enjoying being part of it and how much I do love working with all of you. Cheers, -Sylvain

1 0