February 2024 - openstack-discuss

[storlets] Transition wallaby, xena and yoga to EOL
by Takashi Kajinami 05 Feb '24

05 Feb '24

Hello, As you know, stable/yoga already reached its end of maintenance phase and is now being transitioned to the unmaintained branch. Because we've not seen any attempt to backport changes to it and even older branches, I'd propose retiring yoga and older branches (wallaby and xena) instead of keeping inactive branches. Please let me know if you have any concern. -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 1

[fwaas][devstack] help configuring dashboard
by garcetto 05 Feb '24

05 Feb '24

good morning, is there some tutorial on how to configure fwaas web dashboard on devstack? thank you.

2 1

[nova] Help with support to SGX
by Winicius Allan 05 Feb '24

05 Feb '24

Hello o/ Anyone already work with Nova to provide VMs with SGX support?

6 7

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

02 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