February 2023 - openstack-discuss

[mistral] lists and dict via CLI or dashboard not possible?
by Engelmann Florian 10 Feb '23

10 Feb '23

Hello, I spent 2 hours of testing the "example" workflow "create_instance" that was created by mistral-db-manage populate. Mistral 15.0.0 (including commit: 475c5cf34588fb88f2531883c957097ada5a5fb9 Fix sorting error when type is different) I tested with the CLI (python-mistralclient 4.5.0 as well as 3.7.0) and with the horizon mistral-dashboard (including this fix: mistraldashboard/workflows/forms.py @@ -56,7 +56,7 @@ class ExecuteForm(forms.SelfHandlingForm): def handle(self, request, data): try: - data['workflow_id'] = data.pop('workflow_name') + data['wf_identifier'] = data.pop('workflow_name') data['workflow_input'] = {} for param in self.workflow_parameters: value = data.pop(param) Now it looks like mistral and the mistral-dashboard are working. But: How to enter a list or a dict to any input field? The definition of "create_instance" looks like: --- version: '2.0' create_instance: type: direct description: | Creates VM and waits till VM OS is up and running. input: - name - image_id - flavor_id - ssh_username: null - ssh_password: null # Name of previously created keypair to inject into the instance. # Either ssh credentials or keypair must be provided. - key_name: null # Security_groups: A list of security group names - security_groups: null # An ordered list of nics to be added to this server, with information about connected networks, fixed IPs, port etc. # Example: nics: [{"net-id": "27aa8c1c-d6b8-4474-b7f7-6cdcf63ac856"}] - nics: null task-defaults: on-error: - delete_vm output: ip: <% $.vm_ip %> id: <% $.vm_id %> name: <% $.name %> status: <% $.status %> tasks: create_vm: description: Initial request to create a VM. action: nova.servers_create name=<% $.name %> image=<% $.image_id %> flavor=<% $.flavor_id %> input: key_name: <% $.key_name %> security_groups: <% $.security_groups %> nics: <% $.nics %> publish: vm_id: <% task(create_vm).result.id %> on-success: - search_for_ip ... But eg, "nics" (mandatory) expects a dict: https://docs.openstack.org/python-novaclient/rocky/reference/api/novaclient… nics – An ordered list of nics (dicts) to be added to this server, with information about connected networks, fixed IPs, port etc. Beginning in microversion 2.37 this field is required and also supports a single string value of ‘auto’ or ‘none’. The ‘auto’ value means the Compute service will automatically allocate a network for the project if one is not available. This is the same behavior as not passing anything for nics before microversion 2.37. The ‘none’ value tells the Compute service to not allocate any networking for the server. and "security_groups" a list: security_groups – A list of security group names I tried all possible notations... and gave up after 2 hours. Is it possible to use that workflow from the CLI and the mistral-dashboard? How? Could anybody please provide some examples for "nics" and "security_groups"? All the best, Florian

1 1

[magnum] Other Distro for k8s
by Nguyễn Hữu Khôi 10 Feb '23

10 Feb '23

Hello guys. I know that Magnum is using Fedora Coreos for k8s. Why don't we use a long-term distro such as Ubuntu for this project? I will be more stable. and this project seems obsolete with the old version for k8s. Nguyen Huu Khoi

3 6

[all][tc] Recap of Q1 OpenInfra Board Sync with OpenStack
by Jeremy Stanley 09 Feb '23

09 Feb '23

Interested members of the OpenStack community and OpenInfra Foundation board of directors met via conference call yesterday for an informal quarterly discussion. The call lasted one hour, and primary topics of discussion were an update on the replacement translation platform and the impact of contributor diversity on project sustainability. You can find brief notes here: https://etherpad.opendev.org/p/r.f3414b0bc2932c55376fbc1babde2192 We did not discuss a next time to meet, but since we've done the past three calls approximately three months apart, I propose we schedule 20:00 UTC on Wednesday, May 10. If there are no objections in the coming days, I'll distribute a placeholder calendar file for everyone's convenience. I've also created a new pad here for brainstorming topics for the upcoming discussion: https://etherpad.opendev.org/p/2023-05-board-openstack-sync -- Jeremy Stanley

1 0

Re: [TripleO] Last maintained release of TripleO is Wallaby
by Ümit Seren 09 Feb '23

09 Feb '23

What are the implications with regards to RDO and RHOSP which are based on TripleO ? Will they move to a different deployment method or will also development seize after Zed ? Best Ümit Seren From: James Slagle <james.slagle(a)gmail.com> Date: Wednesday, 8. February 2023 at 18:38 To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: [TripleO] Last maintained release of TripleO is Wallaby The team of TripleO developers, reviewers, and community have no plans to do another release of TripleO, or to continue maintaining the Zed release. This means the last maintained release of TripleO is Wallaby. The plan is to continue to maintain the train and wallaby branches of TripleO repositories under the openstack namespace. We plan to continue to run existing CI on those branches, although we anticipate reducing to a minimal set of jobs in the future. Going forward, the TripleO team expects to continue involvement in other OpenStack projects, and focus on different approaches to OpenStack deployment. The team is not aware of enough other community interest to continue to maintain the zed, master, and future branches of TripleO. Eventually, we will empty commit these branches with a pointer to Wallaby being the last release. If other interests do exist to maintain TripleO going forward, then those plans can adjust. TripleO does not plan on nominating a PTL in the current Bobcat election cycle. If a PTL-like contact is needed for train and wallaby maintenance, then someone will be nominated. I am also not sure how to reflect this project structure change within openstack/governance, and am looking for guidance on how to do so. This type of change did not seem to exactly fit within the concepts of inactive or retired projects. I can work on the patches for governance with some direction, if anyone can provide it. Thanks, and please let us know any questions or feedback about this plan. -- -- James Slagle --

8 8

Re Error by Snapshot (Wassilij Kaiser)
by Wassilij Kaiser 09 Feb '23

09 Feb '23

Hi Linux version 5.4.0-135-generic (buildd@lcy02-amd64-066) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 iscsi storage Device Stack Cluster F UUID Label /dev/sdb o2cb ED9F270C8CC64F72B889A1154BE76F64 cluster-storage /dev/mapper/instances o2cb ED9F270C8CC64F72B889A1154BE76F64 cluster-storage /dev/sde o2cb ED9F270C8CC64F72B889A1154BE76F64 cluster-storage /dev/sdd o2cb ED9F270C8CC64F72B889A1154BE76F64 cluster-storage /dev/sdc o2cb ED9F270C8CC64F72B889A1154BE76F64 cluster-storage ||/ Name Version Architecture Description +++-==============-=================-============-====================================== ii apparmor 2.13.3-7ubuntu5.1 amd64 user-space parser utility for AppArmor Compiled against library: libvirt 8.0.0 Using library: libvirt 8.0.0 Using API: QEMU 8.0.0 Running hypervisor: QEMU 4.2.1 Best regards Wassilij Kaiser

1 0

Error by Snapshot
by Wassilij Kaiser 09 Feb '23

09 Feb '23

Hi, I take a snapshot of Running Instances. The following error occurs inLibvirtd: invalid argument: disk vda does not have an active block job Feb 09 07:42:07 bc1bl08 libvirtd[3860778]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-12acd6a6-7e6b-405e-8760-7ccbac7d9d82) unexpected exit status 1: 2023-02-09 07:42:07.356+0000: 1763455: info : l> 2023-02-09 07:42:07.356+0000: 1763455: info : hostname: bc1bl08 2023-02-09 07:42:07.356+0000: 1763455: error : virDomainDiskDefMirrorParse:8800 : unsupported configuration: unknown mirror job type '' virt-aa-helper: error: could not parse XML virt-aa-helper: error: could not get VM definition Feb 09 07:42:07 bc1bl08 libvirtd[3860778]: internal error: cannot update AppArmor profile 'libvirt-12acd6a6-7e6b-405e-8760-7ccbac7d9d82' Feb 09 07:42:07 bc1bl08 libvirtd[3860778]: Unable to restore security label on /var/lib/nova/instances/snapshots/tmp13rvs6s5/2b0ec8c400634e5d937b5d6a9e0e26ef.delta # Ansible managed DISTRIB_ID="OSA" DISTRIB_RELEASE="25.2.0" DISTRIB_CODENAME="Yoga" DISTRIB_DESCRIPTION="OpenStack-Ansible" Did any of you have the same Error and how did you solve them? I think, For this reason, snapshots are not created. Wassilij Kaiser

2 2

[octavia] Octavia management IP fragment
by Nguyễn Hữu Khôi 09 Feb '23

09 Feb '23

Hello guys. I am using octavia but I see a problem with managing octavia instances, their name and their management ip are not useful to know which LB belongs to. I hope someone will give me some solutions. Nguyen Huu Khoi

2 2

Openstack TripleO Intergration with External Prometheus
by Lokendra Rathour 09 Feb '23

09 Feb '23

Hi team, TripleO Release: Wallaby Prometheus server version: 2.37.5 Node exporter version: 1.5.0 Grafana version: 8.5.20-1 *Query:* we need to integrate Prometheus with OpenStack TripleO, please help share any documents/links to validate this test case. -- ~ Lokendra skype: lokendrarathour

2 1

Zed OVN DPDK Support
by Lazuardi Nasution 09 Feb '23

09 Feb '23

Hi, Due to the depreciation of ovn/vif_type config, I'm still confused about how to implement OVN with DPDK in the proper way. In my experience, br-int datapath_type always returns to the "system" form "netdev" everytime VIF is plugged, even if it is from the first VM created on an empty compute node. My suspicion is related to the following debug log of nova-computer. 2023-02-09 04:34:42.395 1192435 DEBUG ovsdbapp.backend.ovs_idl.transaction [-] Running txn n=1 command(idx=0): AddBridgeCommand(name=br-int, may_exist=True, datapath_type=system) do_commit /usr/lib/python3/dist-packages/ovsdbapp/backend/ovs_idl/transaction.py:90 For information, following is the compute node OVS and Chassis configuration before any VIF is plugged. root@compute01:~# ovs-vsctl list Open_vSwitch _uuid : 799b3140-fe2e-48c6-9779-679152f2eb32 bridges : [6a3b363d-99c7-47b6-9c30-167fbf18cbd8, d2d5b32e-4089-493b-870a-aa056e311b92, ea68d505-bb91-4b15-a532-b942ea9c4e9f] cur_cfg : 440 datapath_types : [netdev, system] datapaths : {netdev=90cd281a-5890-4202-b7b2-ce2fe0bc538f, system=fa3dc7b5-929f-4cad-bdf0-36dbf9ddf78e} db_version : "8.3.0" dpdk_initialized : true dpdk_version : "DPDK 21.11.2" external_ids : {hostname=compute01, ovn-bridge-datapath-type=netdev, ovn-bridge-mappings="provider:br-provider", ovn-encap-ip="10.10.203.14", ovn-encap-type=geneve, ovn-nb="tcp:haproxy.internal:6641", ovn-openflow-probe-interval="60", ovn-remote="tcp:haproxy.internal:6642", ovn-remote-probe-interval="60000", rundir="/var/run/openvswitch", system-id="673c46a0-d9a1-40f8-a164-537693fabf95"} iface_types : [bareudp, dpdk, dpdkvhostuser, dpdkvhostuserclient, erspan, geneve, gre, gtpu, internal, ip6erspan, ip6gre, lisp, patch, stt, system, tap, vxlan] manager_options : [] next_cfg : 440 other_config : {dpdk-init="true", dpdk-socket-mem="1024,1024", pmd-cpu-mask="0x000200000002000200000002", vlan-limit="0"} ovs_version : "3.0.1" ssl : [] statistics : {} system_type : ubuntu system_version : "22.04" root@compute01:~# ovs-vsctl list Bridge _uuid : ea68d505-bb91-4b15-a532-b942ea9c4e9f auto_attach : [] controller : [] datapath_id : "000006d568ea154b" datapath_type : netdev datapath_version : "<built-in>" external_ids : {netplan="true", "netplan/global/set-fail-mode"=standalone, "netplan/mcast_snooping_enable"="false", "netplan/rstp_enable"="false"} fail_mode : standalone flood_vlans : [] flow_tables : {} ipfix : [] mcast_snooping_enable: false mirrors : [] name : br-tun netflow : [] other_config : {} ports : [167cf55f-d2be-48e2-b81c-fcaa0094125b, 2deee00a-86ca-4a4a-8466-682beb2da724, eba98d21-a6d8-4a17-9303-98eb760927ab] protocols : [] rstp_enable : false rstp_status : {} sflow : [] status : {} stp_enable : false _uuid : 6a3b363d-99c7-47b6-9c30-167fbf18cbd8 auto_attach : [] controller : [] datapath_id : "00005e94f53c221f" datapath_type : netdev datapath_version : "<built-in>" external_ids : {ct-zone-049ede3f-a6b8-4498-a278-aa50f69a9340="4", ct-zone-5ba9d829-5034-4f6e-9c50-84112d316eea="3", ct-zone-65177e75-c36c-44f8-b980-8d129bad6b05_dnat="7", ct-zone-65177e75-c36c-44f8-b980-8d129bad6b05_snat="8", ct-zone-7e87f5da-3510-42aa-85b3-b87e3ed53cbd_dnat="2", ct-zone-7e87f5da-3510-42aa-85b3-b87e3ed53cbd_snat="1", ct-zone-f12fcb10-d5f1-4b96-8787-bfc5b5dee282_dnat="6", ct-zone-f12fcb10-d5f1-4b96-8787-bfc5b5dee282_snat="5", netplan="true", "netplan/global/set-fail-mode"=standalone, "netplan/mcast_snooping_enable"="false", "netplan/rstp_enable"="false", ovn-nb-cfg="119", ovn-nb-cfg-ts="1675915566313", ovn-startup-ts="1675897357360"} fail_mode : secure flood_vlans : [] flow_tables : {} ipfix : [] mcast_snooping_enable: false mirrors : [] name : br-int netflow : [] other_config : {disable-in-band="true", hwaddr="5e:94:f5:3c:22:1f"} ports : [0e30606b-00ff-4202-83a7-57505987df79, 4bf11193-ac2f-4101-9eb9-102b5c5e8bf5, 5a20376a-6ec3-49b3-af74-4ecf04636fb2, 62ef10f0-0267-42f7-ac3a-49b8b9e6d816, 8d46690a-3ea8-420f-9bf3-d2aac5f22729, a6eb963a-c410-477c-b11c-4e02ecb17450, bbc9526a-836e-42d5-a2af-85f344eeba8a, cd7200a2-834e-4488-b8ed-3b61e881d6d0, d13d01ee-9fe8-4f21-ab12-831697870e34, d9fa4b5c-77ce-42af-8014-e1f21102f2c4, f6cb742a-2afa-4f00-87d5-8c07067573f3] protocols : [] rstp_enable : false rstp_status : {} sflow : [] status : {} stp_enable : false _uuid : d2d5b32e-4089-493b-870a-aa056e311b92 auto_attach : [] controller : [] datapath_id : "00002eb3d5d23b49" datapath_type : netdev datapath_version : "<built-in>" external_ids : {netplan="true", "netplan/global/set-fail-mode"=standalone, "netplan/mcast_snooping_enable"="false", "netplan/rstp_enable"="false"} fail_mode : standalone flood_vlans : [] flow_tables : {} ipfix : [] mcast_snooping_enable: false mirrors : [] name : br-provider netflow : [] other_config : {} ports : [43d1234c-7dfb-450f-90fb-80c67bac0a9b, 811af772-eac0-4985-8125-a65958bb8c20, 87123c6a-554f-4d51-90fe-14ed709a95a9] protocols : [] rstp_enable : false rstp_status : {} sflow : [] status : {} stp_enable : false root@controller03:~# ovn-sbctl list Chassis "673c46a0-d9a1-40f8-a164-537693fabf95" _uuid : d966cc0e-14cb-4779-b433-d681849f54cd encaps : [afc6b6bb-3698-42ec-a269-579fd4bfdf27] external_ids : {} hostname : compute01 name : "673c46a0-d9a1-40f8-a164-537693fabf95" nb_cfg : 0 other_config : {ct-no-masked-label="true", datapath-type=netdev, iface-types="bareudp,dpdk,dpdkvhostuser,dpdkvhostuserclient,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", mac-binding-timestamp="true", ovn-bridge-mappings="provider:br-provider", ovn-chassis-mac-mappings="", ovn-cms-options="", ovn-enable-lflow-cache="true", ovn-limit-lflow-cache="", ovn-memlimit-lflow-cache-kb="", ovn-monitor-all="false", ovn-trim-limit-lflow-cache="", ovn-trim-timeout-ms="", ovn-trim-wmark-perc-lflow-cache="", port-up-notif="true"} transport_zones : [] vtep_logical_switches: [] Any clue about this situation? Best regards.

1 0

[all][election][tc]Current election statistics/summary
by Tony Breeds 09 Feb '23

09 Feb '23

Hello all, We're just over halfway through the window for PTL and TC nominations and we're low on candidates. We have a single candidate, of 5, for the TC Yours Tony.

1 0