January 2024 - openstack-discuss - lists.openstack.org

[tc] Next Technical Committee Meeting Jan 16 2024, 1800 UTC
by Jay Faulkner 15 Jan '24

15 Jan '24

Hi all, The next weekly OpenStack Technical Committee meeting is tomorrow, Tuesday Jan 16 at 1800 UTC in #openstack-tc on OFTC. The proposed agenda is: Agenda - Roll call - Follow up on tracked action items - JayF - Email mailing list a summary of the discussion around Monasca, highlighting issues around trust and project activity along with a link to the meeting log. - slaweq - Reach out privately to volunteer to maintain Monasca about official vs unofficial options - gmann - Reach out privately to volunteer to maintain Senlin about next steps - Gate health check - Implementation of Unmaintained branch statuses - Inactive projects for Caracal - It is past C-2, these projects will not be in Caracal release. Would we like to take further action in Caracal? - Monasca - Senlin - Freezer - Solum - EC2 API - Sahara - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews Thanks, Jay Faulkner

1 0

[neutron] Bug deputy - week of Jan 8
by Sławek Kapłoński 15 Jan '24

15 Jan '24

Hi, It was pretty quiet week. Below is summary of the bugs opened this last week and its current status. ## High * https://bugs.launchpad.net/neutron/+bug/2048745 - [ovn] FIP not working when mixing vlan and geneve tenant networks - not assigned, many things to consider before we will start working on this improvement really * https://bugs.launchpad.net/neutron/+bug/2048785 - Trunk parent port (tpt port) vlan_mode is wrong in ovs - WIP fix already started by Bence: https://review.opendev.org/c/openstack/neutron/+/905125 * https://bugs.launchpad.net/neutron/+bug/2049265 - [OVN] The ``MaintenanceWorker`` shoudl register the "Private_Chassis" table in the SB connection - assigned to Terry Wilson, fixes already proposed https://review.opendev.org/q/I711996b7644e80bc195833e4429e4d745728f9cf ## Medium * https://bugs.launchpad.net/neutron/+bug/2048979 - [ml2][ovs] ports without local vlan tag are processed on openflow security group - fix proposed by LIU: https://review.opendev.org/c/openstack/neutron/+/905289 ## Others * https://bugs.launchpad.net/neutron/+bug/2048773 - neutron-meter-agent do not support ovn driver - unassigned, it isn't really completly new RFE IMO but probably approach to take to close this gap may be discussed e.g. in the drivers meeting, * https://bugs.launchpad.net/neutron/+bug/2049398 - [Tempest] neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net "Created Network is Not an External Network" Error - needs some more info to be triaged, I will take care of it -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[Image Encryptione] Cancelling tomorrows meeting
by Josephine Seifert 14 Jan '24

14 Jan '24

Hi, unfortunately I have to cancel tomorrows meeting. greetings, Luzi (Josephine)

1 0

[kolla]Boot one VM with two GPU(in same numa)by pci passthrough cannot have GPUDirect P2P capability
by dazhaoyu＠126.com 12 Jan '24

12 Jan '24

I have two GPU cards, all of them was connect with one same numa CPU socket as below link info: https://paste.opendev.org/show/b7Qi8qCnbLVxO2W0JdQw/ I can boot one nova instance successfully with the two GPU cards by PCI Passthrough way. but in the booted instances, use deviceQuery method would get the below message: Peer access from NVIDIA RTX 6000(GPU0) -> NVIDIA RTX 6000(GPU1): NO Peer access from NVIDIA RTX 6000(GPU1) -> NVIDIA RTX 6000(GPU0): NO The expected return should be as below： Peer access from NVIDIA RTX 6000(GPU0) -> NVIDIA RTX 6000(GPU1): YES Peer access from NVIDIA RTX 6000(GPU1) -> NVIDIA RTX 6000(GPU0): YES so that the memory can be shared between the two GPUs. I'm running Openstack Xena release in Intel Xeon Gold 5220R CPU

1 0

[release] Release countdown for week R-11, Jan 15-19
by Elõd Illés 12 Jan '24

12 Jan '24

Development Focus ----------------- We are now past the Caracal-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to the end of the release cycle, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (February 22nd, 2024). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (February 29th, 2024) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, February 29th, 2024. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (March 14th, 2024) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (March 28th, 2024) Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 22nd, 2024 (R-6 week) Client library freeze: February 29th, 2024 (R-5 week) Caracal-3 milestone: February 29th, 2024 (R-5 week) 2024.1 Caracal final release: April 3rd, 2024 2024.2 'D' virtual PTG ( https://openinfra.dev/ptg/ ): April 8th-12th, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[openstack][keystone] user who mapped from openid cannot create application credentials
by Nguyễn Hữu Khôi 12 Jan '24

12 Jan '24

Hello. I have a problem that I use openid for authentication to my cloud but my users cannot create application credentials. I must add them to a group via Horizon UI to use application credentials. Is there any way to do that without adding users to a group from Horizon? Thank you. Nguyen Huu Khoi

1 1

[kolla-ansible][magnum]Private CA in Fedora-CoreOS
by Franck VEDEL 12 Jan '24

12 Jan '24

Hello, I have two platforms: on the first (Yoga), which is connected with public names and addresses, certificates issued by trusted CAs, no problem, creating a cluster template and deploying a cluster based on Fedora-CoreOS-35 works perfectly. On the second, I have a private certification authority (and privates addresses) and when I create a template then deploy a cluster, obviously there is a problem (in each node of the cluster) with the certificate issued by an untrusted CA. For the cluster to be deployed, I need to connect to the nodes, copy my CA certificate to /etc/pki/ca-trust/source/anchors/ then run the "update-ca-trust" command. My question is: is it possible to deploy a cluster using this method but without having to do what I am obliged to do if the CA is not trusted? If the answer exists, I couldn't find it in the documentation, I apologize. Thanks in advance Franck

1 0

[masakari] is going to be deprecated?!
by garcetto 12 Jan '24

12 Jan '24

good morning, maybe my comprehension fault, but is masakari going to be abandoned?! ... https://docs.openstack.org/kolla-ansible/latest/reference/compute/masakari-… "Support for deploying Masakari has been deprecated in the 2023.2 (Bobcat) release due to failures in the CI and lack of contributors working on fixing this."

2 2

[octavia] [octavia-ingress-controller][k8s]
by Johnny Yang 12 Jan '24

12 Jan '24

Hi, We are following https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/oct… to create octavia ingress controller. we are in openstack yoga version, and octavia ingress control version as ( registry.k8s.io/provider-os/octavia-ingress-controller:v1.28.1) we are getting the following error from octavia ingress controller pod =========== ❯ k logs octavia-ingress-controller-0 -n kube-system 2024/01/10 17:47:16 Running command: Command env: (log-file=, also-stdout=false, redirect-stderr=true) Run from directory: Executable path: /bin/octavia-ingress-controller Args (comma-delimited): /bin/octavia-ingress-controller,--config=/etc/config/octavia-ingress-controller-config.yaml 2024/01/10 17:47:16 Now listening for interrupts INFO [2024-01-10T17:47:16Z] Using config file file=/etc/config/octavia-ingress-controller-config.yaml W0110 17:47:16.597288 12 client_config.go:618] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work. FATAL [2024-01-10T17:47:16Z] failed to initialize openstack client error="Get \"/\": unsupported protocol scheme \"\"" 2024/01/10 17:47:16 running command: exit status 1 ======= the following are our service account/configmap/deployment yaml files: ============== serviceaccount.yaml ----- kind: ServiceAccount apiVersion: v1 metadata: name: octavia-ingress-controller namespace: kube-system --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: octavia-ingress-controller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: octavia-ingress-controller namespace: kube-system --- config.yaml ---- kind: ConfigMap apiVersion: v1 metadata: name: octavia-ingress-controller-config namespace: kube-system data: config: | cluster-name: cedev17 openstack: auth_url: https://srelab501.wpc.az1.eng.pdx.wd:5000 project_domain_name: Default user_domain_name: Default project_name: cedev17.t501.eng.pdx.wd project_id: 94ba42c68e1346189b666f17e49e22f5 username: admin user-id: b0f2b611d99e444cbe1c1fa068940411 password: password region_name: RegionOne cacert: /etc/pki/tls/certs/ca-bundle.crt octavia: subnet-id: 37abc0d8-f5ab-4109-8864-622ab4b47b1f floating-network-id: 42d4ba58-ccd6-407b-a887-5727ee7fe275 manage-security-groups: false provider: amphora ----- --- kind: StatefulSet apiVersion: apps/v1 metadata: name: octavia-ingress-controller namespace: kube-system labels: k8s-app: octavia-ingress-controller spec: replicas: 1 selector: matchLabels: k8s-app: octavia-ingress-controller serviceName: octavia-ingress-controller template: metadata: labels: k8s-app: octavia-ingress-controller spec: serviceAccountName: octavia-ingress-controller tolerations: - effect: NoSchedule # Make sure the pod can be scheduled on master kubelet. operator: Exists - key: CriticalAddonsOnly # Mark the pod as a critical add-on for rescheduling. operator: Exists - effect: NoExecute operator: Exists imagePullSecrets: - name: regcred containers: - name: octavia-ingress-controller image: docker-dev-artifactory.workday.com/wpc5/dev/octavia-ingress-controller:v1.2… imagePullPolicy: IfNotPresent args: - /bin/octavia-ingress-controller - --config=/etc/config/octavia-ingress-controller-config.yaml volumeMounts: - mountPath: /etc/kubernetes name: kubernetes-config readOnly: true - name: ingress-config mountPath: /etc/config hostNetwork: true volumes: - name: kubernetes-config hostPath: path: /etc/kubernetes type: Directory - name: ingress-config configMap: name: octavia-ingress-controller-config items: - key: config path: octavia-ingress-controller-config.yaml ------ Thank you in advance for help! -Johnny

2 1

beginning with [masakari]
by Shubham Kumar Yadav 11 Jan '24

11 Jan '24

Hi, i have recently started working on Masakari (kubernetes in openstack) so i wanted some help with it please i was trying to test the masakari-instance-monitor & masakari-host-monitor but having trouble with it. i have created a pacemaker remote cluster (with pacemaker & corosync on controller nodes and pacemaker remote on compute node). *pcs statusCluster name: lab-clusterCluster Summary: * Stack: corosync * Current DC: lab-11053-26006-ceph-2 (version 2.1.2-ada5c3b36e2) - partition with quorum * Last updated: Thu Dec 14 08:41:41 2023 * Last change: Thu Dec 14 08:41:22 2023 by root via cibadmin on lab-11053-26006-ceph-1 * 6 nodes configured * 3 resource instances configuredNode List: * Online: [ lab-11053-26006-ceph-1 lab-11053-26006-ceph-2 lab-11053-26006-ceph-3 ] * RemoteOnline: [ lab-11053-26006-comp-1.cluster.local lab-11053-26006-comp-2.cluster.local lab-11053-26006-comp-3.cluster.local ]Full List of Resources: * lab-11053-26006-comp-1.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-1 * lab-11053-26006-comp-2.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-2 * lab-11053-26006-comp-3.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-3Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled* i have also created segment and added segment hosts(computes) in it. when i tried to test the masakari host monitor by manually powering off the compute node, masakari should move the vms from powered off computes to some running compute but after the compute is powered off vms still remains on the powered off compute. Am i missing some conf? is there any need to add some conf in nova and keystone too? *in masakari engine logs i seehost_failure.evacuate_all_instances = Trueinstance_failure.process_all_instances = Falsehost_failure.add_reserved_host_to_aggregate = Falsehost_failure.ha_enabled_instance_metadata_key = HA_Enabled log_opt_valueshost_failure.ignore_instances_in_error_state = Falsehost_failure.service_disable_reason = Masakari detected host failed.* *2 - question do i have to create some notification and vmoves?* openstack notification create <type> <hostname> <generated_time> <payload> if yes what is the use of notification & vmoves i ahve attached a file with the email which contains the componenets i created for masakari(segments &hosts in segments)

2 1