- openstack-discuss - lists.openstack.org

Fwd: Regarding Trove-Openstack error
by skumari 13 Dec '24

13 Dec '24

---------- Original Message ---------- From: skumari <skumari(a)cdac.in> To: jimmy(a)openstack.org, communitymngr(a)openstack.org Date: December 9, 2024 at 10:03 AM Subject: Regarding Trove-Openstack error Hi Sir, In trove-openstack while iam trying to create a database instance iam getting this error: Polling request timed out. | | fault_date | 2024-12-06T10:45:59 | | fault_details | Traceback (most recent call last): | | | File "/var/lib/kolla/venv/lib/python3.11/site-packages/trove/common/utils.py", line 208, in wait_for_task | | | return polling_task.wait() | | | ^^^^^^^^^^^^^^^^^^^ | | | File "/var/lib/kolla/venv/lib/python3.11/site-packages/eventlet/event.py", line 124, in wait | | | result = hub.switch() | | | ^^^^^^^^^^^^ | | | File "/var/lib/kolla/venv/lib/python3.11/site-packages/eventlet/hubs/hub.py", line 310, in switch | | | return self.greenlet.switch() | | | ^^^^^^^^^^^^^^^^^^^^^^ | | | File "/var/lib/kolla/venv/lib/python3.11/site-packages/oslo_service/loopingcall.py", line 154, in _run_loop | | | idle = idle_for_func(result, self._elapsed(watch)) | | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | | | File "/var/lib/kolla/venv/lib/python3.11/site-packages/oslo_service/loopingcall.py", line 349, in _idle_for | | | raise LoopingCallTimeOut( | | | oslo_service.loopingcall.LoopingCallTimeOut: | | | Looping call timed out after 1808.67 seconds | | | | | | During handling of the above exception, another exception occurred: | | | | | | Traceback (most recent call last): | | | File "/var/lib/kolla/venv/lib/python3.11/site-packages/trove/taskmanager/models.py", line 447, in wait_for_instance | | | utils.poll_until(self._service_is_active, | | | File "/var/lib/kolla/venv/lib/python3.11/site-packages/trove/common/utils.py", line 224, in poll_until | | | return wait_for_task(task) | | | ^^^^^^^^^^^^^^^^^^^ | | | File "/var/lib/kolla/venv/lib/python3.11/site-packages/trove/common/utils.py", line 210, in wait_for_task | | | raise exception.PollTimeOut | | | trove.common.exception.PollTimeOut: Polling request timed out. I even increased poll request timeout also . can you please help me to solve the error Thankyou Kumari. ------------------------------------------------------------------------------------------------------------ [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------

4 4

[nova][tc] Removing md5 in password injection
by Thomas Goirand 13 Dec '24

13 Dec '24

Hi, I didn't feel it would be controversial, though it seems removing md5 password injection is still up to debate: https://review.opendev.org/c/openstack/nova/+/935512 Of course, I'd like the TC to agree with me that injecting md5-hashed passwords is, in 2024, to be considered a security problem that should be fixed (and backported) ASAP. BTW, IMO this patch could be using the new feature from oslo_utils.secretutils that Takashi managed to get in: https://review.opendev.org/c/openstack/oslo.utils/+/931899 https://review.opendev.org/c/openstack/oslo.utils/+/935525 These, IMO, should also be backported to earlier oslo.utils releases, so we can fix earlier OpenStack releases in a nicer way. Cheers, Thomas Goirand (zigo)

6 14

[blazar] Next IRC meeting cancelled
by Pierre Riteau 13 Dec '24

13 Dec '24

Hello, Due to the holiday season, the next IRC meeting scheduled for December 26 is cancelled. We will meet again on January 9. I wish you all happy holidays. Cheers, Pierre Riteau (priteau)

1 0

[watcher] Canceling Dec 26th and Jan 2nd weekly meetings
by Douglas Viroel 12 Dec '24

12 Dec '24

Hi all o/ Since most of us will be out during the holidays, we agreed[1] on canceling watcher's weekly meetings[2] on Dec 26th and Jan 2nd. The last meeting of 2024 will be next week, on Dec 19th, and the first one of 2025 will be on Jan 9th. BR, [1] https://meetings.opendev.org/meetings/watcher/2024/watcher.2024-12-12-12.00… -- Douglas Viroel - dviroel

1 0

[cinder][ceph rbd] change volume type
by Tony Liu 12 Dec '24

12 Dec '24

Hi, With Antelope, old volume type is on replicated pool and new volume type is on EC pool. Change volume type doesn't work, volume type remains and no error returns. Is such change supported? I also tried change volume type from one replicated pool to another replicated pool. Doesn't work either. Am I missing anything? Thanks! Tony

2 1

[Openstack-ansible][Rabbitmq] Rabbitmq role is installing latest version of rabbitmq even after setting package version in variable file
by Danish Khan 12 Dec '24

12 Dec '24

Dear All, I have upgraded few of my openstack clusters from Ussuri to Wallaby successfully. But it seems rabbitmq repo is changed and now rabbitmq is getting its packages from: https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-server/deb/ubuntu Everything was working fine until I face below issue while running rabbitmq playbook: TASK [rabbitmq_server : Apply rabbitmq policies] ******************************************************************************************************* failed: [rabbit_mq_container] (item={'name': 'HA', 'pattern': '^(?!(amq\\.)|(.*_fanout_)|(reply_)).*', 'priority': 0, 'tags': 'ha-mode=all'}) => {"ansible_loop_var": "item", "changed": false, "cmd": "/usr/sbin/rabbitmqctl -q -n '' set_policy -p / HA '^(?!(amq\\.)|(.*_fanout_)|(reply_)).*' '{\"ha-mode\": \"all\"}' --priority 0", "item": {"name": "HA", "pattern": "^(?!(amq\\.)|(.*_fanout_)|(reply_)).*", "priority": 0, "tags": "ha-mode=all"}, "msg": "Error:\nValidation failed\n\n[{<<\"ha-mode\">>,<<\"all\">>}] are not recognised policy settings", "rc": 69, "stderr": "Error:\nValidation failed\n\n[{<<\"ha-mode\">>,<<\"all\">>}] are not recognised policy settings\n\n", "stderr_lines": ["Error:", "Validation failed", "", "[{<<\"ha-mode\">>,<<\"all\">>}] are not recognised policy settings", ""], "stdout": "", "stdout_lines": []} It seems ha-mode=all is deprecated in latest version of Rabbitmq (4.0.4). I tried to install 3.8 or some other compatible version of rabbitmq but anyway the latest version of rabbitmq is getting installed. I have updated below entries of file /etc/ansible/roles/rabbitmq_server/vars/debian.yml : _rabbitmq_package_version: "3.8.14-1" and _rabbitmq_erlang_version_spec: "{{ (rabbitmq_install_method == 'external_repo') | ternary('1:23.3.4.15-1', '1:22.*') }}" Can someone please help me with this? I guess either I need to find a away to install specific version of rabbitmq to fox rabbitmq policy issue or I need to update parameters of command while applying policy. Regards, Danish Khan

2 2

[KOLLA-Ansible] default values for cpu_allocation_ratio
by Oliver Weinmann 12 Dec '24

12 Dec '24

Hi all, what are the default values for: cpu_allocation_ratio ram_allocation_ratio disk_allocation_ratio when using kolla-ansible? I can't seem to find any clear statement about it. Currently I assume they are 1.0 for each. Cheers, Oliver

2 2

[magnum] Cluster type (vm, ubuntu, kubernetes) not supported
by Satish Patel 12 Dec '24

12 Dec '24

Folks, I am trying to create a template for magnum but getting the following error. I am running the 2024.1 release. Anything changed or missing here? openstack image create ${IMAGE_NAME} --disk-format=qcow2 --container-format=bare --property os_distro=${OS_DISTRO} --file=${IMAGE_NAME}.qcow2; \ openstack coe cluster template create \ --image $(openstack image show ${IMAGE_NAME} -c id -f value) \ --external-network public \ --dns-nameserver 8.8.8.8 \ --master-lb-enabled \ --master-flavor gen.c4-m8-d30 \ --flavor gen.c4-m8-d30 \ --network-driver calico \ --docker-storage-driver overlay2 \ --coe kubernetes \ --label kube_tag=${version} \ k8s-${version}; Cluster type (vm, ubuntu, kubernetes) not supported (HTTP 400) (Request-ID: req-7c7f27b2-d67c-4f5b-aacf-01754b35bba8)

4 7

Re: [nova][security-sig] Communicating SSH host keys on
by Jeremy Stanley 12 Dec '24

12 Dec '24

first boot (was: Removing md5 in password injection) Reply-To: In-Reply-To: <8a163fa2-f071-4744-aae3-2182c048351c(a)redhat.com> On 2024-12-11 16:30:40 +0000 (+0000), Sean Mooney wrote: [...] > > Tangential, sorry, but could this sort of mechanism also be used to > > provide an out-of-band verification of SSH hostkeys generated on > > first boot for *nix type guests? We used to splat them to the > > primary terminal and then try to scrape them from the console log, > > but having a structured API response would be a lot cleaner (or did > > something similar already get added and I missed it?). [...] > i see the merrit in supprot some kind of reporting for limited > trusted boot type use cases such as providing the ssh host key > fingerprint so you can validate that the vm is the one you expect > it to be. > > im not sure how i would feel about allowing arbiarty metadata to > be store this way. > > is there something beyond the host key that would be useful for > you to record on boot? Nothing else comes to mind. Basically it's the desire to avoid ToFU style finger-crossing that the SSH host key you get on initially connecting to a newly booted server instance is really coming from that instance and not a MitM or honeypot. It's possible in most providers to create an authenticated backchannel by abusing the console log, as I described, but that has its own challenges. I suppose there might be alternative management protocols similar to SSH which rely on asymmetric key algorithms to authenticate hosts, but I'm not personally familiar with any (none with the near ubiquity of SSH at any rate). > perhaps we can try and capture this is a spec or separate thread > and work out what an mvp would look like. there would basically be > two part, one extednign the metadata api to support recording the > host key fingerprint somewhere, and then making that discoverable > via the main api perhaps in server show. That would make sense, and it would probably also be a good idea to try to involve e.g. a cloud-init maintainer in any such design discussion, as this would need client-side integration eventually anyway in whatever's going to communicate the key back to nova. > is we allowed read write access to all instance metadata we would > would not actually need to modify the main api as you can already > list metadata on an instance but im worried that could be abused > so i don't know if that is a good idea. Yes, that sounds like a security nightmare. > the nova metadata api is not intended a a high performance key > value store so i dont necessarily think it would be a good idea to > extned this to a generic crud api but we certainly could provide > limited support for targeted uscease liek the one you raise. Agreed, I suppose the field could be given a more generic name in case certain kinds of guests wanted to store functionally similar things in it, but as I said I don't know what else that would end up being anyway. -- Jeremy Stanley

1 1

Some questions about ironic
by Johnny Hao 12 Dec '24

12 Dec '24

Hi Buddies, I am new to ironic, after some study, I have several questions about it, could anyone help to answer? Thanks a lot. 1. According to the workflow chart below, what's the communication method between nova-compute and Ironic API? HTTP API call or RPC call through mq like rabbitmq? So are the communications between Ironic Conductor and other components of Neutron, Glance and Cinder/Swift etc? 2. Where do Ironic services run (Ironic API/Conductor/Drivers and DB)? In the controller node? Or a separate node is also supported? ** -- Best regards QingFeng Hao

2 1