February 2024 - openstack-discuss

nova-compute down and no data in log file
by russell.stather＠ignitiongroup.co.za 05 Feb '24

05 Feb '24

nova-compute showing as enabled but down. Log files are not being written to. Service is showing as running. This is a juju installation. Have tried pausing and resuming the nova-compute, and rabbitmq, and nova-cloud-controller.

1 0

[cinder] volume type properties / extra_specs
by Josephine Seifert 05 Feb '24

05 Feb '24

Hi, I was experimenting with the extra_specs of volume types for a project. And while I was able to set and unset properties freely, the volumes created from volume types with random properties could not be created. They always went into Error state. When I removed the properties from the volume type, volumes could be created again. Is it meant to behave like this? So in other words: Are custom properties not allowed for volume types? And if so, why am I allowed to set custom properties? I would expect an Error to happen in the volume type set --property ... process and not when creating a volume. greetings. Josephine (Luzi)

2 2

[oslo] Feature freeze.
by Daniel Bengtsson 04 Feb '24

04 Feb '24

Hi there, Just a friendly reminder that oslo's feature freeze will happen in 2 weeks (R-7 - Feb 12 - Feb 16). To know more about the freeze, we have a policy[1] that discusses it. The main thing is that if you have features you want to get into Oslo libraries this cycle, please make sure they merge by Friday. After that we will need to go through the FFE process and there is no guarantee we can land them. Feel free to ping us on IRC if you need code review. [1] http://specs.openstack.org/openstack/oslo-specs/specs/policy/feature-freeze… -- Daniel Bengtsson Software Engineer

3 2

[all] SQLAlchemy 2.x support in Bobcat
by Thomas Goirand 02 Feb '24

02 Feb '24

Hi, As you may know, and to my great frustration, I'm not the maintainer of SQLAlchemy in Debian, even though OpenStack is the biggest consumer of it. The current maintainer insists that he wants to upload SQLA 2.x in Unstable, potentially breaking all of OpenStack. At the present moment, if I understand correctly, we're not there yet, and Bobcat doesn't have such a support. It would be ok for me, *IF* there are patches available on master, that I could backport to Bobcat and maintain in the debian/patches folder of each project. However, the biggest current annoyance, is that I have no idea where we are at. Are we close to such a support? Is there a list of patches to apply on top of Bobcat that is maintained somewhere? Please enlighten me... :) Cheers, Thomas Goirand (zigo)

5 10

RE: [cinder] Inactive 3rd party CIs
by Roquesalane, Jean-Pierre 01 Feb '24

01 Feb '24

Thanks Takashi for driving this. As far as Dell is concerned, those CIs should be marked as unsupported as they are now EOL. * DellEMC SC CI * DellEMC VNX CI * DellEMC XtremIO CI I'll have the CI team to take a look at the Dell PowerMax CI which is supposed to be active. JP Jean-Pierre Roquesalane SW System Sr Principal Engineer - OpenStack Champion Dell Technologies | Security and Ecosystem Software Mobile +33 6 21 86 79 04<tel:1-613-314-8106> Email : jeanpierre.roquesalane(a)dell.com<mailto:jeanpierre.roquesalane@dell.com> [cid:image001.png@01DA545A.5A50B740] Dell SAS, Si?ge Social 1 rond point Benjamin Franklin 34000 Montpellier. Capital 1,946,545.26 Euros, 351 528 229 RCS Montpellier -APE 4651Z -TVA Intracommunautaire FR 20 351 528 229. SIRET 351 528 229 00088 Vat Number : FR 20351528229 (France) / IT00001709997 (Italy) / ESN0012622G (Spain) Internal Use - Confidential

3 7

OpenStack Service.exe killing the svchost.exe process on Windows Server
by evandro.semedo＠skymail.com.br 01 Feb '24

01 Feb '24

Hi guys, I have a Cloudbase Panel and some windows hosts are shutting down in sometimes randomly, i see in windows dumps the OpenStack Service.exe killing the svchost.exe process on Windows Server. There is a bug or some Known issue? In dump i see the OpenStackService.exe process svchost.exe (ffffa38c`8f501a90 fffff802`819d4b35 : ffffe487`000004f0 ffffe487`7bf4c080 ffffe487`61e5b300 00000000`00000128 : nt!NtTerminateProcess+0xa9) Owning Process ffffe4875d4ab080 Image: OpenStackService.exe Attached Process ffffe48761e5b300 Image: svchost.exe Follow below the dump result: ###||### For analysis of this file, run !analyze -v 14: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* CRITICAL_PROCESS_DIED (ef) A critical system process died Arguments: Arg1: ffffe48761e5b300, Process object or thread object Arg2: 0000000000000000, If this is 0, a process died. If this is 1, a thread died. Arg3: 0000000000000000 Arg4: 0000000000000000 Debugging Details: ------------------ KEY_VALUES_STRING: 1 Key : Analysis.CPU.Sec Value: 4 Key : Analysis.DebugAnalysisProvider.CPP Value: Create: 8007007e on WINOPS1 Key : Analysis.DebugData Value: CreateObject Key : Analysis.DebugModel Value: CreateObject Key : Analysis.Elapsed.Sec Value: 5 Key : Analysis.Memory.CommitPeak.Mb Value: 88 Key : Analysis.System Value: CreateObject BUGCHECK_CODE: ef BUGCHECK_P1: ffffe48761e5b300 BUGCHECK_P2: 0 BUGCHECK_P3: 0 BUGCHECK_P4: 0 PROCESS_NAME: svchost.exe CRITICAL_PROCESS: svchost.exe ERROR_CODE: (NTSTATUS) 0x7bf4c080 - <Unable to get error code text> BLACKBOXBSD: 1 (!blackboxbsd) BLACKBOXPNP: 1 (!blackboxpnp) STACK_TEXT: ffffa38c`8f501938 fffff802`820927e8 : 00000000`000000ef ffffe487`61e5b300 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx ffffa38c`8f501940 fffff802`81fd4a0f : ffffe487`61e5b300 fffff802`818fe82d ffffe487`61e5b300 fffff802`818f2bac : nt!PspCatchCriticalBreak+0x148 ffffa38c`8f5019e0 fffff802`81ec836c : ffffe487`00000000 00000000`00000000 ffffe487`61e5b300 ffffe487`61e5b5d8 : nt!PspTerminateAllThreads+0x10dcab ffffa38c`8f501a50 fffff802`81e69e39 : ffffffff`ffffffff ffffa38c`8f501b80 ffffe487`5d4ab080 fffff802`81dd7e01 : nt!PspTerminateProcess+0xe0 ffffa38c`8f501a90 fffff802`819d4b35 : ffffe487`000004f0 ffffe487`7bf4c080 ffffe487`61e5b300 00000000`00000128 : nt!NtTerminateProcess+0xa9 ffffa38c`8f501b00 00007ffc`eb980174 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25 00000033`b7efad38 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtTerminateProcess+0x14 SYMBOL_NAME: ntdll!NtTerminateProcess+14 MODULE_NAME: ntdll IMAGE_NAME: ntdll.dll STACK_COMMAND: .thread ; .cxr ; kb BUCKET_ID_FUNC_OFFSET: 14 FAILURE_BUCKET_ID: 0xEF_svchost.exe_BUGCHECK_CRITICAL_PROCESS_7bf4c080_ntdll!NtTerminateProcess OS_VERSION: 10.0.17763.1 BUILDLAB_STR: rs5_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {8930391e-0eee-85dc-14a9-6e289649b678} Followup: MachineOwner --------- 14: kd> !thread [-p] [-t] [Address [Flags]] THREAD ffffe4877bf4c080 Cid 29f8.42a0 Teb: 00000033b7d92000 Win32Thread: 0000000000000000 RUNNING on processor e Not impersonating DeviceMap ffffd10732013240 Owning Process ffffe4875d4ab080 Image: OpenStackService.exe Attached Process ffffe48761e5b300 Image: svchost.exe Wait Start TickCount 9007284 Ticks: 0 Context Switch Count 73 IdealProcessor: 13 UserTime 00:00:00.031 KernelTime 00:00:00.187 Win32 Start Address 0x00007ff7e08b2534 Stack Init ffffa38c8f501c90 Current ffffa38c8f501360 Base ffffa38c8f502000 Limit ffffa38c8f4fc000 Call 0000000000000000 Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5 Child-SP RetAddr : Args to Child : Call Site ffffa38c`8f501938 fffff802`820927e8 : 00000000`000000ef ffffe487`61e5b300 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx ffffa38c`8f501940 fffff802`81fd4a0f : ffffe487`61e5b300 fffff802`818fe82d ffffe487`61e5b300 fffff802`818f2bac : nt!PspCatchCriticalBreak+0x148 ffffa38c`8f5019e0 fffff802`81ec836c : ffffe487`00000000 00000000`00000000 ffffe487`61e5b300 ffffe487`61e5b5d8 : nt!PspTerminateAllThreads+0x10dcab ffffa38c`8f501a50 fffff802`81e69e39 : ffffffff`ffffffff ffffa38c`8f501b80 ffffe487`5d4ab080 fffff802`81dd7e01 : nt!PspTerminateProcess+0xe0 ffffa38c`8f501a90 fffff802`819d4b35 : ffffe487`000004f0 ffffe487`7bf4c080 ffffe487`61e5b300 00000000`00000128 : nt!NtTerminateProcess+0xa9 ffffa38c`8f501b00 00007ffc`eb980174 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffffa38c`8f501b00) 00000033`b7efad38 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtTerminateProcess+0x14

1 0

Re: [kolla-ansible][magnum] question
by Oliver Weinmann 01 Feb '24

01 Feb '24

Hi Franck, glad that I was able to help. Sorry I don't know about this one. But a quick google revealed this: https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-configure-swap… Looks as if the FCOS image has this enabled somehow. I have updated my blogpost on CAPI in MAGNUM. It is finally working and its way faster to deploy Kubernetes. This will no longer use FCOS images but Ubuntu or FLATCAR. Maybe you want to give it a try: https://www.roksblog.de/openstack-magnum-cluster-api-driver/ Have a nice weekend. Cheers, Oliver Am 05.01.2024 um 17:07 schrieb Franck VEDEL: > Hi Oliver. > Thanks for you help !! > > I took the time to consult the help concerning > Magnum(https://docs.openstack.org/magnum/2023.1/user/) and this > article > (https://www.roksblog.de/deploy-kubernetes-clusters-in-openstack-within-minu…) > > > > I understood a lot of things, even though I'm not a Kubernetes expert. > Everything works as I wanted, except for one detail. > Do you know why we get this type of message (and quite a few minutes > to wait) when creating a node: > Capture d’écran 2024-01-05 à 15.43.04.png > > zram_generator…………. no configuration found. > > This is the last point that I cannot improve. Maybe there's nothing we > can do. > Thank you once again, that’s really very nice. > > > Franck VEDEL > > > > >> Le 3 janv. 2024 à 12:26, Oliver Weinmann <oliver.weinmann(a)me.com> a >> écrit : >> >> Hi Franck, >> >> Great. Glad it works. That is the k8s version and the url where >> magnum will pull the container from. The official docs are quite >> helpful. In the latest Openstack release bobcat there is already some >> support for CAPI. It is not 100% working out of the Box but it looks >> very promising. I have taken my blog post offline since I didn’t >> manage to get it working. But I will look into it again in the next >> couple of days. >> >> Cheers, >> Oliver >> >> Von meinem iPhone gesendet >> >>> Am 03.01.2024 um 12:21 schrieb Franck VEDEL >>> <franck.vedel(a)univ-grenoble-alpes.fr>: >>> >>> Hi Oliver, >>> and thanks a lot for your help. >>> I followed the instructions on the blog and indeed, with [trust] it >>> works. >>> I'm trying to understand everything. what are the parameters for: >>> >>> |--labels kube_tag=v1.21.11-rancher1,hyperkube_prefix=docker.io/rancher/| >>> >>> Thanks in advance >>> >>> Franck >>> >>> >>> >>>> Le 25 déc. 2023 à 19:26, Franck VEDEL >>>> <franck.vedel(a)univ-grenoble-alpes.fr> a écrit : >>>> >>>> Hi Oliver and thanks you for this help. >>>> >>>> I was wrong in my explications. >>>> I had seen this article (roksblog.de ) and I did what it said: >>>> I first tried: >>>> enable_cluster_user_trust = True in globals.yml >>>> It didn't work. >>>> >>>> I then made the modification in /etc/kolla/config/magnum.conf: >>>> cluster_user_trust = True >>>> >>>> Same problem. >>>> >>>> That's why I asked the question. Is this really the way to do it? >>>> If so, I will have to restart the containers (keystone?) >>>> >>>> Franck >>>> >>>> >>>> >>>>> Le 25 déc. 2023 à 18:40, Oliver Weinmann <oliver.weinmann(a)me.com> >>>>> a écrit : >>>>> >>>>> Hi Frank, >>>>> >>>>> According to the official kolla docs the option needs to be in >>>>> globals.yml >>>>> >>>>> Ensure that you understand the consequences before enabling this >>>>> option. In|globals.yml|: >>>>> >>>>> In case this also doesn’t work, you can try: >>>>> >>>>> yoga) [vagrant@seed ~]$ cat /etc/kolla/config/magnum.conf >>>>> [trust] >>>>> cluster_user_trust = True >>>>> >>>>> *www.roksblog.de >>>>> >>>>> Cheers, >>>>> Oliver >>>>> >>>>> Von meinem iPhone gesendet >>>>> >>>>>> Am 25.12.2023 um 18:10 schrieb Franck VEDEL >>>>>> <franck.vedel(a)univ-grenoble-alpes.fr>: >>>>>> >>>>>> enable_cluster_user_trust = True >>>> >>> >

2 2

Keystone LDAP backend: need to change user_id_attribute from CN to SAMAccountName
by Michel Jouvin 01 Feb '24

01 Feb '24

Hi, For historical (and bad) resons, we decided 10 years ago when we created our cloud that the Keystone LDAP backend will use the CN as the user_id_attribute rather than the usual SAMAccountName. Since then it has been a source of various problems with CN changes, accented characters in CN... We'd like to change it to SAMAccountName but there is clearly no easy/supported way of doing it and we are looking for some information on the best way to do it and the risks if somebody has some clues... It should impact ~30 users so not a huge number... What we have in mind is basically: - Change the backend attribute - Import new accounts - Assign the new accounts to the same projects as the ol accounts, with the same role One of the foreseen problemsis that old and new accounts will share the same user_name_attribute, based on SAMAccountName. It is not allowed by openstack if I'm right so for the scenario to work we need to change the user_name_attribute of old accounts to something different (we don't care that the user cannot use the account during the transition peroid as long as it doesn't impact active resources). Is it enough to update it in the database? We'd prefer to keep the old accounts in OpenStack until the end of the transition... Another minor issue is the reassignment of keypairs to the new account. It is poosble to ask the user to reload its public keys but we were wondering it there was a not too risky way of doing it for him/her by updating the DB (I guess there is no API for this). Thanks in advance if you have any thought/information to share. Best regards. Michel

3 5

sqlite vs NULL
by Pete Zaitcev 01 Feb '24

01 Feb '24

Greetings: In short: Should it be possible to select by key that is NULL in our DBs? This is needed for Cinder, review 657543[1]. Tests run on sqlite. Long explanation: The review tinkers with SQL Alchemy's query, so it may be doing it wrong. However, I looked at the queries and this seems to happen. A query for everything finds the NULL entry. The query looks like this: SELECT backups.created_at AS backups_created_at, (... very many AS ...) FROM backups LEFT OUTER JOIN backup_metadata AS backup_metadata_1 ON backup_metadata_1.backup_id = backups.id AND backup_metadata_1.deleted = false WHERE backups.deleted = false AND backups.host = %(host_1)s So, the entry is in the database. However, this one returns everything that matches the arguments, but not the one with key of NULL: SELECT backups.created_at AS backups_created_at, (... very many AS ...) FROM backups LEFT OUTER JOIN backup_metadata AS backup_metadata_1 ON backup_metadata_1.backup_id = backups.id AND backup_metadata_1.deleted = false WHERE backups.deleted = false AND backups.status IN (%(status_1)s, %(status_2)s, %(status_3)s, %(status_4)s, %(status_5)s, %(status_6)s, NULL) AND backups.host = %(host_1)s ORDER BY backups.created_at DESC, backups.id DESC The backup with a NULL status is in the DB, but I cannot get it with objects.BackupList.get_all(ctxt, filters={'status': (None,)}) One other thing: Is there an easy way to make negative query through SQLalchemy? My real task is to find all the backups that are not stable (complete and error), so that I can restart it. Thanks for any suggestions, -- Pete [1] https://review.opendev.org/c/openstack/cinder/+/657543

3 3

Reg Cinder volume is not deleted by using gui
by Rohit Sansiya 31 Jan '24

31 Jan '24

*Dear Sir, *Despite attempts to delete a Cinder volume using the graphical user interface (GUI) in the OpenStack environment, the volume remains undeleted. Additionally, attempts to detach the volume via the GUI are unsuccessful. However, it has been observed that these operations can be successfully performed using command-line interface (CLI) commands. Help me! 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