May 2024 - openstack-discuss - lists.openstack.org

[oslo][release] Changing back release model of tooz ?
by Takashi Kajinami 13 May '24

13 May '24

Hello, As you may know, tooz was moved to the independent release model[1] after wallaby release because of its stable code base at that time. However, we introduced several features/improvements in tooz during a few cycles and I'm wondering if we can revisit its status now. One actual problem I'm seeing now is that, we recently got a bug report[2] about the redis sentinel support which we added during 2024.1 cycle but we can't backport the required bug fix to 2024.1 because of no stable branch. Given the situation, I'm wondering if it makes sense (and is possible) to move tooz back to the cycle-with-intermediary model, and create 2024.1 branch from 6.1.0 (the last release during 2024.1 cycle) now, so that we can maintain 2024.1 releases with future bug fixes brackported. [1] https://review.opendev.org/c/openstack/releases/+/788230 [2] https://bugs.launchpad.net/python-tooz/+bug/2063857 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

4 5

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-20)
by Goutham Pacha Ravi 13 May '24

13 May '24

Hello Stackers, We're officially in milestone-1 week for the 2024.2 (Dalmatian) release cycle [1]. Teams are actively planning design specification freezes, hackathons, and bug squashes. I'm delighted to announce that three Outreachy interns have been funded to work with the OpenStack community [2]. Please join me in welcoming Mohd Ariq (tspyderboy), Okeke Christian Chima (cokeke), and Abby Nduta (AbbyNduta). Mohd Ariq and Christian will be working with members of the OpenStack Manila project team, while Abby will be working with members of the OpenStack Horizon project team. Congratulations, interns! These internships begins at the end of May and will conclude at the end of August. There have been a few governance changes in the past week that I'd like to brief you about: The "Consistent and Secure Default RBAC" goal has new milestone requirements. All projects are expected to transition oslo.policy's "enforce_scope" and "enforce_new_defaults" options to True during the 2024.2 release cycle. These options will be removed from oslo.policy during the 2025.1 release cycle. [3] openstack/kuryr and openstack/kuryr-libnetwork are now under the maintainership of the openstack/zun ("Container as a service") team. The TC has adopted a house rule to mark projects that have identified no leadership as "inactive" projects [4]. We've merged slaweq's summary of the 2023 OpenStack User Survey [5]. Thanks, slaweq, and to all of you who took the survey. === Weekly Meeting === Last week's TC meeting was held simultaneously on Zoom (a recording is on YouTube [6]) and IRC on May 7th, 2024. The meeting was logged to eavesdrop [7]. Over the years, we've come to realize that monitoring project activity through objective tools wasn't representing the picture accurately. Several mature/feature-complete projects will seemingly be "inactive," and what we're interested in assessing is whether there are active maintainers tackling security and project infrastructure concerns. Artem Goncharov (gtema) will write up a proposal to tag inactive projects more prominently. We discussed a proposal to change the Distributed Project Leadership model to require DPL liaisons to re-assert their interest at the beginning of each cycle. The proposal also suggests appointing liaisons from the TC to monitor projects that have this leadership model. TC Members would be welcome to nominate themselves as liaisons for projects following DPL if this proposal is accepted. We took some AIs to continue the cleanup of maintainers on OpenStack's packages on PyPI - an ongoing community-wide effort [8]. We discussed the open goal proposal to replace eventlet. The Technical Committee wants to ensure that we're not advocating for a one-size-fits-all solution to the problem of threading in OpenStack projects. Hence, we'd prefer not to merge the proposal to replace eventlet with asyncio. Instead, we want to encourage projects to independently explore solutions that make sense to their individual architecture - which could be asyncio, native threads, or any other threading paradigm/library. We are supportive of ensuring there's no imposition of any specific library or threading mechanism imposed via oslo libraries. JayF will be summarizing this view to this mailing list soon. The meeting concluded with an open discussion on DevStack setup time and an outdated (but relevant) proposal related to OSC as a service on DevStack. Tomorrow's meeting is back on OFTC/IRC, and the call details and agenda are at [9]. We look forward to seeing you there. The TC is always honored to chat with you, so please join us, and feel free to add anything to the agenda that you'd like to chat with us about! === Goal Proposals === As stated above, this goal proposal needs your weigh-in: - Migrate eventlet usages to asyncio (https://review.opendev.org/c/openstack/governance/+/902585) === Governance Proposals === ==== Merged ==== - Remove ref of bylaw Appendix 4 | https://review.opendev.org/c/openstack/governance/+/916942 - Add timeline to remove enforce_scope in RBAC goal | https://review.opendev.org/c/openstack/governance/+/915179 - Move openstack/kuryr and openstack/kuryr-libnetwork to Zun | https://review.opendev.org/c/openstack/governance/+/917517 - 2023 User Survey TC Question Analysis | https://review.opendev.org/c/openstack/governance/+/900516 - Add option to move leaderless project to Inactive status | https://review.opendev.org/c/openstack/governance/+/914726 ==== Open for review/discussion ==== - Update to include docs and miscellaneuos repos for AC status | https://review.opendev.org/c/openstack/governance/+/915021 - Add DPL model & liaison reset policy | https://review.opendev.org/c/openstack/governance/+/916833 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://releases.openstack.org/dalmatian/schedule.html [2] https://www.outreachy.org/alums/2024-05/#:~:text=Openstack [3] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [4] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [5] https://governance.openstack.org/tc/user_survey/analysis-2023.html [6] https://youtu.be/-WZT7PC3sig [7] https://meetings.opendev.org/meetings/tc/2024/tc.2024-05-07-18.00.log.html [8] https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup [9] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

openstack boot an instance from an IDE volume migrated from VMware
by luckydog xf 11 May '24

11 May '24

hi, list, I'm going to boot an instance from an existing volume, and it is a Windows 2016 migrated from VMware. So the bus must be set to 'ide' mode, otherwise it fails to boot up. Let's assume this volume UUID is xyz and it's bootable. I cloned it by clonezilla from VMware ESXI. since virtio drive wasn't installed in Windows, so it must be set to ide. So what's the right way to boot it from this volume and set it to IDE? I have tried lots of ways, like --- openstack server create test-windows --flavor 4 --nic net-id=7b57ee99-136f-4aa7-b3fe-a4958ec8c644 --block-device id=xxxx:disk_bus=ide and ... --block-device-mapping. But unfortunately, none of them work. And there are too many outdated docs like disk_bus=ide and bus=ide. Not sure which one works. This is fairly frustrating. I'm still struggling with this issue and need your help. Thanks a lot.

3 7

[tc][all][ec2-api] Retiring the ec2-api project
by Ghanshyam Mann 11 May '24

11 May '24

Hello everyone, As you might know, the ec2-api project is not active and was marked 'inactive' since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next step is to retire the project. I'm sending this email to propose the ec2-api retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

1 1

[tc][all][senlin] Retiring the Senlin project
by Ghanshyam Mann 11 May '24

11 May '24

Hello everyone, As you might know, the Senlin project is not active and was marked 'inactive' since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next step is to retire the project. I'm sending this email to propose the Senlin retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

1 1

[tc][all][solum] Retiring the Solum project
by Ghanshyam Mann 11 May '24

11 May '24

Hello everyone, As you might know, the Solum project is not active and was marked 'inactive' since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next step is to retire the project. I'm sending this email to propose the Solum retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

1 1

[tc][all][murano] Retiring the Murano project
by Ghanshyam Mann 11 May '24

11 May '24

Hello everyone, As you might know, the Murano project is not active and was marked 'inactive' since 2024.1 cycle[1]. Due to a critical bug in Murano, the TC needs to pass a resolution to stop its 2024.1 release[2]. In this cycle also, this project is leaderless[3] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[3], the next step is to retire the project. I'm sending this email to propose the Murano retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://governance.openstack.org/tc/resolutions/20240227-remove-murano-from… [3] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

1 1

[magnum][magnum-cluster-api] Scalling Master Node
by pahrialtkj＠gmail.com 11 May '24

11 May '24

Hello all, I created a k8s cluster with 1 master and 1 worker node, I want to increase the master node to 2 or 3, I tried to do it with cluster resize/update and nodegroup create seems to be not supported and does not work, it works for the worker node, has anyone tried scaling the master node?

3 3

Re: How to check the free RAM or CPU or Disk in openstack python module
by Lajos Katona 11 May '24

11 May '24

Hi, No I meant something like this: $ openstack resource provider list +--------------------------------------+-------+------------+--------------------------------------+----------------------+ | uuid | name | generation | root_provider_uuid | parent_provider_uuid | +--------------------------------------+-------+------------+--------------------------------------+----------------------+ | 0f916a23-403f-43c3-ac57-e109bc371dba | jammy | 2 | 0f916a23-403f-43c3-ac57-e109bc371dba | None | +--------------------------------------+-------+------------+--------------------------------------+----------------------+ $ openstack resource provider inventory list 0f916a23-403f-43c3-ac57-e109bc371dba +----------------+------------------+----------+----------+----------+-----------+-------+------+ | resource_class | allocation_ratio | min_unit | max_unit | reserved | step_size | total | used | +----------------+------------------+----------+----------+----------+-----------+-------+------+ | VCPU | 4.0 | 1 | 6 | 0 | 1 | 6 | 0 | | MEMORY_MB | 1.0 | 1 | 7936 | 512 | 1 | 7936 | 0 | | DISK_GB | 1.0 | 1 | 28 | 0 | 1 | 28 | 0 | +----------------+------------------+----------+----------+----------+-----------+-------+------+ $ openstack resource provider inventory list 0f916a23-403f-43c3-ac57-e109bc371dba +----------------+------------------+----------+----------+----------+-----------+-------+------+ | resource_class | allocation_ratio | min_unit | max_unit | reserved | step_size | total | used | +----------------+------------------+----------+----------+----------+-----------+-------+------+ | VCPU | 4.0 | 1 | 6 | 0 | 1 | 6 | 1 | | MEMORY_MB | 1.0 | 1 | 7936 | 512 | 1 | 7936 | 256 | | DISK_GB | 1.0 | 1 | 28 | 0 | 1 | 28 | 1 | +----------------+------------------+----------+----------+----------+-----------+-------+------+ Recently this API was also added to Horizon (the web gui for Openstack) as hypervisor API and the compute db behind it is not preferred. Best wishes Lajos Katona (lajoskatona) Saeed <s.fazl73(a)gmail.com> ezt írta (időpont: 2024. máj. 10., P, 13:12): > Hello, > > Thanks a lot, but I didn't find the proper way for this. > > In CLI, I run *openstack hypervisor show hypervisor.domain.com > <http://hypervisor.domain.com>*, it then shows all the needed information > and data. > I run *openstack service list*, I see this: > > > +----------------------------------+------------------+-------------------------+ > | ID | Name | Type > | > > +----------------------------------+------------------+-------------------------+ > | 0a289a58588d4d00ac27ef92da8128de | keystone | identity > | > | 2cdf38eca0c0467fa856f1f1d91f8de3 | heat | orchestration > | > | 44393da92532478abd2dc1bdba1454ce | nova_legacy | compute_legacy > | > | 4cee55fd6c524134b010c65a7d406857 | ironic | baremetal > | > | 4f47c9bd69a34b5a9e0ef149823b7785 | neutron | network > | > | 59053bba36ed4944aaac7e8eb0f9ac01 | freezer | backup > | > | 670cb0faa6c64f8f82f0d19315e085a5 | trove | database > | > | 828ba6c2709349d597e469bf7fa55766 | glance | image > | > | 8c2671e5ddde47e4ae1accd2ce2eb696 | placement | placement > | > | 8c6357e12abb40e5a46b10be5f950c79 | heat-cfn | cloudformation > | > | c211ea65a3d440d1bb2add6f74423056 | watcher | infra-optim > | > | ceba54fa82f543579b245569b9fc127e | masakari | instance-ha > | > | d5c2952cc6904a0385cb20e5d39d1afe | nova | compute > | > | e238634b10db492a942e27714ee9d9b1 | gnocchi | metric > | > | f545381f4aa649a39122a258f48833fc | ironic-inspector | > baremetal-introspection | > > +----------------------------------+------------------+-------------------------+ > > If I do understand your reply correctly, you mean I should run a single > command for each server to find its free memory or CPU? For example if I > have 100 servers, I should run 100 times a command with different server > names? > > On Fri, 10 May 2024 at 10:33, Lajos Katona <katonalala(a)gmail.com> wrote: > >> Hi, >> Instead of Compute API, Placement is used for such statistics, see the >> API reference: >> https://docs.openstack.org/api-ref/placement/ >> >> You have to follow the resource providers on your compute, and resource >> providers can be in a tree with a root provider. >> For the available resources (resource classes) you have to list the >> resource provider inventories, and for >> the used resource you have to follow the allocations. >> Check the API ref and see the possibilities with CLI first perhaps. Be >> careful Placement API is microversioned like Compute API. >> >> From python SDK you can find the relevant methods here: >> >> https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/plac… >> >> Best wishes >> Lajos Katona (lajoskatona) >> >> Saeed <s.fazl73(a)gmail.com> ezt írta (időpont: 2024. máj. 9., Cs, 19:06): >> >>> Hello, >>> >>> This is my python code: >>> >>>> import openstack >>> >>> openstack.enable_logging(debug=False) >>> >>> hypervisors = [] >>> >>> conn = openstack.connect(cloud='region1') >>> >>> for hypervisor in conn.compute.hypervisors(details=True): >>> >>> hypervisors.append(hypervisor.to_dict()) >>> >>> >>> I also run this: >>> >>>> for hypervisor in hypervisors: >>> >>> print(hypervisor) >>> >>> >>> This is the last result (other results are similar this): >>> >>>> {'cpu_info': None, 'host_ip': '1.1.1.1', 'hypervisor_type': 'QEMU', >>>> 'hypervisor_version': 6002000, 'name': 'some.fqdn.com', >>>> 'service_details': {'id': 'some-random-id', 'host': 'some.fqdn.com', >>>> 'disabled_reason': 'test'}, 'servers': None, 'state': 'up', 'status': >>>> 'disabled', 'uptime': ' 00:27:11 up 31 days, 10:14, 2 users, load >>>> average: 3.52, 3.20, 3.36\n', 'current_workload': None, 'disk_available': >>>> None, 'local_disk_used': None, 'local_disk_size': None, 'local_disk_free': >>>> None, 'memory_used': None, 'memory_size': None, 'memory_free': None, >>>> 'running_vms': None, 'vcpus_used': None, 'vcpus': None, 'id': >>>> 'some-random-id', 'location': Munch({'cloud': 'region1', 'region_name': >>>> 'Region1', 'zone': None, 'project': Munch({'id': 'somerandomid', 'name': >>>> None, 'domain_id': None, 'domain_name': None})})} >>> >>> >>> As you see, values like *cpu_info*, *disk_available*, *local_disk_used* >>> , *local_disk_size*, *local_disk_free*, *memory_used*, etc are *None*. >>> >>> How can I have the following values? In the Openstack UI I see it says >>> the free available disk, memory and CPU, but I don't know how to have them >>> in python. >>> >>> I see here >>> <https://docs.openstack.org/openstacksdk/latest/user/resources/compute/v2/hy…> >>> the above values, but for me all are None. >>> >>> Regards, >>> Saeed >>> >>

3 2

[manila][cinder][glance][nova][devstack][qa] Add ashrod98 to devstack-plugin-ceph core
by Goutham Pacha Ravi 10 May '24

10 May '24

Dear Stackers, I'd like to nominate Ashley Rodriguez to join the devstack-plugin-ceph core team. She has made significant contributions to Ceph integration and testing, especially with the Manila project. Ashley's work includes CI fixes and improvements to the cephadm installer, enabling multi-node installations and integrating ceph's new ingress service in our test jobs. She has also tackled tech debt in Manila's Ceph testing. If there are no objections, I'll add Ashley to the gerrit group next week. Ashley, your hard work is truly appreciated! Best regards, Goutham

4 4