- openstack-discuss - lists.openstack.org

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

2 2

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

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

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

16 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 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