- openstack-discuss - lists.openstack.org

[neutron] Drivers meeting - Friday 22.4.2022 - cancelled
by Lajos Katona 22 Apr '22

22 Apr '22

Hi Neutron Drivers! Due to the lack of agenda, let's cancel today's drivers meeting (sorry for the late mail...). See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

OpenStack Yoga for Ubuntu 22.04 LTS and Ubuntu 20.04 LTS
by Corey Bryant 22 Apr '22

22 Apr '22

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack Yoga on Ubuntu 22.04 LTS (Jammy Jellyfish) and Ubuntu 20.04 LTS (Focal Fossa) via the Ubuntu Cloud Archive. Details of the Yoga release can be found at: https://www.openstack.org/software/yoga To get access to the Ubuntu Yoga packages: == Ubuntu 22.04 LTS == OpenStack Yoga is available by default on Ubuntu 22.04. == Ubuntu 20.04 LTS == The Ubuntu Cloud Archive for OpenStack Yoga can be enabled on Ubuntu 20.04 by running the following command: sudo add-apt-repository cloud-archive:yoga The Ubuntu Cloud Archive for Yoga includes updates for: aodh, barbican, ceilometer, ceph (17.1.0), cinder, designate, designate-dashboard, dpdk (21.11), glance, gnocchi, heat, heat-dashboard, horizon, ironic, ironic-ui, keystone, libvirt (8.0.0), magnum, magnum-ui, manila, manila-ui, masakari, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-baremetal, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-sfc, neutron, neutron-dynamic-routing, neutron-fwaas, neutron-vpnaas, nova, octavia, octavia-dashboard, openstack-trove, openvswitch (2.17.0), ovn (22.03.0), ovn-octavia-provider, placement, sahara, sahara-dashboard, senlin, swift, trove-dashboard, vmware-nsx, vitrage, watcher, watcher-dashboard, zaqar, and zaqar-ui. For a full list of packages and versions, please refer to: https://openstack-ci-reports.ubuntu.com/reports/cloud-archive/yoga_versions… == Reporting bugs == If you have any issues please report bugs using the ‘ubuntu-bug’ tool to ensure that bugs get logged in the right place in Launchpad: sudo ubuntu-bug nova-conductor Thank you to everyone who contributed to OpenStack Yoga! Corey (on behalf of the Ubuntu OpenStack Engineering team)

1 0

[Xena][Gnocchi] gnocchi_statsd become unhealthy after some time
by wodel youchi 21 Apr '22

21 Apr '22

Hi, Recently we deployed Openstack Xena using Kollla-ansible, we noticed that gnocchi_statsd become unhealthy after a period of time, we restarted it several times, it shows a healthy state, but hours after it becomes unhealthy [root@controllera ~]# docker ps | grep gnocch fcc31e240322 192.168.1.16:4000/openstack.kolla/centos-source-gnocchi-statsd:xena "dumb-init --single-…" 45 hours ago Up 24 hours (unhealthy) gnocchi_statsd The log file don't show anything special, you can find all gnocchi logs attached. How can we figure out what causes this?

1 0

error openstack
by Firas Hlel 21 Apr '22

21 Apr '22

Hi all, I am working on a project Openstack in linux ubuntu 20.04. I want to create a cluster hadoop with one master-node and three worker-nodes and i have a problem with a cluster that doesn't work. Status ERROR: Creating cluster failed for the following reason(s): Failed to create trust Error ID: ef5e8b0a-8e6d-4878-bebb-f37f4fa50a88, Failed to create trust Error ID: 43157255-86af-4773-96c1-a07ca7ac66ed. links: https://docs.openstack.org/devstack/latest/ File local.conf : [[local|localrc]] ADMIN_PASSWORD=secret DATABASE_PASSWORD=secret RABBIT_PASSWORD=secret SERVICE_PASSWORD=$ADMIN_PASSWORD HOST_IP=10.0.2.15 LOGFILE=$DEST/logs/stack.sh.log SWIFT_REPLICAS=1SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5 SWIFT_DATA_DIR=$DEST/data enable_plugin sahara https://opendev.org/openstack/sahara enable_plugin sahara-dashboard https://opendev.org/openstack/sahara-dashboard enable_plugin heat https://opendev.org/openstack/heat Can you guys advise me about these errors. Is there anything to worry about?

1 0

[glance][devstack][tripleo][ansible][ceph_admin] Glance moving away from single store Configuration
by Abhishek Kekane 21 Apr '22

21 Apr '22

Hello Everyone, Glance has added support to configure multiple stores as a store backend in Stein cycle, and it is very stable now. So in upcoming cycles we are going to remove single store support and use multiple stores support only (PS. you can configure a single store using multiple stores configuration options). As a first step, we have started adding support in devstack [1][2][3] for configuring glance as multiple stores for each of the glance store backend. This cycle we are going to default multistore configuration in devstack so that our gate/check (CI) jobs should test using the same. Following cycles we will start removing single store support from glance code base. If you have any questions related to this work kindly revert back to this mail or you can join us in our weekly meeting, every Thursday at 1400 UTC #openstack-meeting IRC channel as well. [1] https://review.opendev.org/c/openstack/devstack/+/741654 [2] https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/741801/ [3] https://review.opendev.org/c/openstack/devstack/+/741802 Thank you, Abhishek Kekane

3 4

[dev][horizon] Integration of the ec2 feature
by lab reporting 21 Apr '22

21 Apr '22

Hello, We will add EC2 token management within the Horizon project. As a reminder, EC2 Credentials service allows the creation of access/secret credentials used for the ec2 interop layer of OpenStack to authorize S3 requests. It is part of the package keystone.contrib Do you think this development is of interest to the community ? Do you think this development can be built into the core? And if so, should we insert into the panel group dedicated to object storage or into the identity panel ? Thank you in advance for your answers. Best Regards, Tony

1 0

Question on monkey-patching paramiko for FIPS
by Ade Lee 21 Apr '22

21 Apr '22

Hi all, As many have already seen, a number of changes have been merged in OpenStack as part of the effort to allow OpenStack to run on FIPS enabled systems. This effort has been captured in a proposed community goal. [1]. One of the requirements for this effort is that md5sum() not be used in a security related context. In fact, python 3.9 has been modified to raise an exception of hashlib.md5sum() is called on a FIPS enabled system, unless it is explicitly annotated with a usedforsecurity=False attribute [2]. We added a wrapper for md5sum in oslo.config to take advantage of this attribute. [3,4,5] Where we have less control is in libraries used by Openstack - and in particular, paramiko. Paramiko fails on FIPS enabled systems because of a call to md5sum() in get_fingerprint(). A patch has been submitted to fix this problem. [6]. Unfortunately, it takes a very long time for paramiko to fix issues. In order for us to make progress on FIPS testing, a small monkey-patch for paramiko was checked into tempest. [7]. Because this change was made to a test tool, this patch was relatively uncontroversial. A similar change has been found to be needed for manila [8]. I would expect that a similar change will be needed in other components that use paramiko to SSH to other systems (eg. cinder, neutron?) I suspect that the only reason this has not been detected in FIPS testing more widely yet is because the components that use paramiko for SSH are being tested in third party tests that do not, as yet, test FIPS. At the request of the manila team, I am bringing this monkey-patch to the attention of the wider OpenStack community to get feedback on the pros and cons of applying this monkey-patch. A couple things to note: 1. This monkey patch is quite small in scope and only needed until paramiko fixes the issue. 2. paramiko is not FIPS compliant, and so we will ultimately need to fix paramiko or replace it with a different library on FIPS enabled systems. When we do this, we would remove the monkey patch. Thanks, Ade Lee [1] https://opendev.org/openstack/governance/src/branch/master/goals/proposed/f… [2] https://bugs.python.org/issue9216 [3] https://review.opendev.org/c/openstack/oslo.utils/+/750031 [4] Patches to various projects to use oslo.utils adapter for hashlib.md5 (as examples): glance: https://review.opendev.org/c/openstack/glance/+/756158 nova: https://review.opendev.org/c/openstack/nova/+/756434 nova: https://review.opendev.org/c/openstack/nova/+/777686 os-brick: https://review.opendev.org/c/openstack/os-brick/+/756151 oslo: https://review.opendev.org/c/openstack/oslo.versionedobjects/+/756153 tooz: https://review.opendev.org/c/openstack/tooz/+/756432 opensdk: https://review.opendev.org/c/openstack/openstacksdk/+/767411 octavia: https://review.opendev.org/c/openstack/octavia/+/798146 designate: https://review.opendev.org/c/openstack/designate/+/798157 glance_store: https://review.opendev.org/c/openstack/glance_store/+/756157 [5] Swift patch to handle hashlib.md5 https://review.opendev.org/c/openstack/swift/+/751966 [6] https://github.com/paramiko/paramiko/pull/1928 [7] https://review.opendev.org/c/openstack/tempest/+/822560 [8] https://review.opendev.org/c/openstack/manila/+/819375

3 2

Deployment system includes: Ussuri, Brocade X7-8
by Duc Loi 21 Apr '22

21 Apr '22

Hi Everyone, In the near future, we will deploy a system including Ussuri and Brocade X7-8 according to customer requirements. But Brocade has made a notice not to support versions after Train. Has anyone implemented a system similar? What are the challenges you face? What solutions can fix it? Thanks and Best Regards

1 0

[all][tc] Technical Committee next weekly meeting on April 21 at 1500 UTC
by Ghanshyam Mann 21 Apr '22

21 Apr '22

Hello Everyone, Technical Committee's next weekly meeting is scheduled for April 21 at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, April 20, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

OPS Meetup Registration
by Amy Marrich 21 Apr '22

21 Apr '22

Registration is now open for the OPS Meetup to be held Friday right after the Summit. https://www.eventbrite.com/e/openstack-ops-meetup-tickets-322813472787 And don't forget you can still add topics: https://etherpad.opendev.org/p/april2022-ptg-openstack-ops Thanks, Amy (spotz)

1 0

[cinder] Bug deputy report for week of 04-20-2022
by Sofia Enriquez 20 Apr '22

20 Apr '22

This is a bug report from 04-13-2022 to 04-20-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1969366 "Backend incorrectly reporting cacheable capability." Assigned to Gorka. - https://bugs.launchpad.net/cinder/+bug/1969408 "[RBD] Cinder fails to retype / migrate large volumes." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1967481 "[Storwize_SVC]Retype operation failure for GMCV due to update_clean_rate." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1968164 "Incorrectly shown volume size while using PowerFlex cinder driver." Fix proposed to master. Low - https://bugs.launchpad.net/cinder/+bug/1967686 "[DEFAULT] use_forwarded_for is a duplicate of the HTTPProxyToWSGI middleware." Assigned to Takashi Kajinami. - https://bugs.launchpad.net/cinder/+bug/1968048 "Pylint tox environment fails on Fedora 35." Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1968159 "[IBM Storwize] Retype failure for replication volume-type." Fix proposed to master. Invalid - https://bugs.launchpad.net/cinder/+bug/1969213 "When image properties contain "signature_verified" field，create volume from image wil fail." Unassigned. Cheers -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

ERROR CREATING CLUSTER
by Firas Dehech 20 Apr '22

20 Apr '22

Hi all, I am working on a project Openstack in linux ubuntu 20.04. I want to create a cluster hadoop with one master-node and three worker-nodes and i have a problem with a cluster that doesn't work. Status ERROR: Creating cluster failed for the following reason(s): Failed to create trust Error ID: ef5e8b0a-8e6d-4878-bebb-f37f4fa50a88, Failed to create trust Error ID: 43157255-86af-4773-96c1-a07ca7ac66ed. links: https://docs.openstack.org/devstack/latest/ File local.conf : [[local|localrc]] ADMIN_PASSWORD=secret DATABASE_PASSWORD=secret RABBIT_PASSWORD=secret SERVICE_PASSWORD=$ADMIN_PASSWORD HOST_IP=10.0.2.15 LOGFILE=$DEST/logs/stack.sh.log SWIFT_REPLICAS=1SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5 SWIFT_DATA_DIR=$DEST/data enable_plugin sahara https://opendev.org/openstack/sahara enable_plugin sahara-dashboard https://opendev.org/openstack/sahara-dashboard enable_plugin heat https://opendev.org/openstack/heat Can you guys advise me about these errors. Is there anything to worry about? Regards.

1 0

[security][security sig] Stepping down as chair
by Gage Hugo 20 Apr '22

20 Apr '22

Hey folks, I've been serving as the Security SIG chair for over 4 years now and throughout my entire time as chair I've had the wonderful experience of learning and working alongside several excellent individuals. It also has given me the great opportunity to have multiple discussions on the topic of security with the community as a whole which helped me grow my knowledge base and career. However, with my focus shifting away from pure OpenStack work and the rather long time that 4 years is, I believe it's time for someone with a fresh perspective to have the opportunity to step into the role and help guide the Security SIG into the future. I am stepping down from the role of Security SIG chair as of today, but I plan on sticking around in the SIG for as long as I can. I hope to continue contributing when I can and I will be around to help anyone who is interested in the role of chair. I'd like to give a big thank you to Jeremy Stanley (fungi) for all the help he provided throughout my time as chair and continues to do so to this day whenever I have a question and need help. He helped me step into the chair role and I am sure he will also help anyone who is interested in the role as well. Thanks again for the opportunity and I hope to see you all around! - Gage Hugo

1 0

[Kolla-ansible][Xena][Ceph-RGW] need help configuring Ceph RGW for Swift and S3 access
by wodel youchi 20 Apr '22

20 Apr '22

Hi, I am having trouble configuring Openstack to use Ceph RGW as the Object store backend for Swift and S3. My setup is an HCI, I have 3 controllers which are also my ceph mgrs, mons and rgws and 9 compte/storage servers (osds). Xena is deployed with Ceph Pacific. Ceph public network is a private network on vlan10 with 10.10.1.0/24 as a subnet. Here is a snippet from my globals.yml : > --- > kolla_base_distro: "centos" > kolla_install_type: "source" > openstack_release: "xena" > kolla_internal_vip_address: "10.10.3.1" > kolla_internal_fqdn: "dashint.cloud.example.com" > kolla_external_vip_address: "x.x.x.x" > kolla_external_fqdn: "dash.cloud.example.com " > docker_registry: 192.168.1.16:4000 > network_interface: "bond0" > kolla_external_vip_interface: "bond1" > api_interface: "bond1.30" > *storage_interface: "bond1.10" <---------------- VLAN10 (public ceph > network)* > tunnel_interface: "bond1.40" > dns_interface: "bond1" > octavia_network_interface: "bond1.301" > neutron_external_interface: "bond2" > neutron_plugin_agent: "openvswitch" > keepalived_virtual_router_id: "51" > kolla_enable_tls_internal: "yes" > kolla_enable_tls_external: "yes" > kolla_certificates_dir: "{{ node_config }}/certificates" > kolla_external_fqdn_cert: "{{ kolla_certificates_dir }}/haproxy.pem" > kolla_internal_fqdn_cert: "{{ kolla_certificates_dir > }}/haproxy-internal.pem" > kolla_admin_openrc_cacert: "{{ kolla_certificates_dir }}/ca.pem" > kolla_copy_ca_into_containers: "yes" > kolla_enable_tls_backend: "yes" > kolla_verify_tls_backend: "no" > kolla_tls_backend_cert: "{{ kolla_certificates_dir }}/backend-cert.pem" > kolla_tls_backend_key: "{{ kolla_certificates_dir }}/backend-key.pem" > enable_openstack_core: "yes" > enable_hacluster: "yes" > enable_haproxy: "yes" > enable_aodh: "yes" > enable_barbican: "yes" > enable_ceilometer: "yes" > enable_central_logging: "yes" > > *enable_ceph_rgw: "yes"enable_ceph_rgw_loadbalancer: "{{ enable_ceph_rgw | > bool }}"* > enable_cinder: "yes" > enable_cinder_backup: "yes" > enable_collectd: "yes" > enable_designate: "yes" > enable_elasticsearch_curator: "yes" > enable_freezer: "no" > enable_gnocchi: "yes" > enable_gnocchi_statsd: "yes" > enable_magnum: "yes" > enable_manila: "yes" > enable_manila_backend_cephfs_native: "yes" > enable_mariabackup: "yes" > enable_masakari: "yes" > enable_neutron_vpnaas: "yes" > enable_neutron_qos: "yes" > enable_neutron_agent_ha: "yes" > enable_neutron_provider_networks: "yes" > enable_neutron_segments: "yes" > enable_octavia: "yes" > enable_trove: "yes" > external_ceph_cephx_enabled: "yes" > ceph_glance_keyring: "ceph.client.glance.keyring" > ceph_glance_user: "glance" > ceph_glance_pool_name: "images" > ceph_cinder_keyring: "ceph.client.cinder.keyring" > ceph_cinder_user: "cinder" > ceph_cinder_pool_name: "volumes" > ceph_cinder_backup_keyring: "ceph.client.cinder-backup.keyring" > ceph_cinder_backup_user: "cinder-backup" > ceph_cinder_backup_pool_name: "backups" > ceph_nova_keyring: "{{ ceph_cinder_keyring }}" > ceph_nova_user: "cinder" > ceph_nova_pool_name: "vms" > ceph_gnocchi_keyring: "ceph.client.gnocchi.keyring" > ceph_gnocchi_user: "gnocchi" > ceph_gnocchi_pool_name: "metrics" > ceph_manila_keyring: "ceph.client.manila.keyring" > ceph_manila_user: "manila" > glance_backend_ceph: "yes" > glance_backend_file: "no" > gnocchi_backend_storage: "ceph" > cinder_backend_ceph: "yes" > cinder_backup_driver: "ceph" > cloudkitty_collector_backend: "gnocchi" > designate_ns_record: "cloud.example.com " > nova_backend_ceph: "yes" > nova_compute_virt_type: "kvm" > octavia_auto_configure: yes > octavia_amp_flavor: > name: "amphora" > is_public: no > vcpus: 1 > ram: 1024 > disk: 5 > octavia_amp_network: > name: lb-mgmt-net > provider_network_type: vlan > provider_segmentation_id: 301 > provider_physical_network: physnet1 > external: false > shared: false > subnet: > name: lb-mgmt-subnet > cidr: "10.7.0.0/16" > allocation_pool_start: "10.7.0.50" > allocation_pool_end: "10.7.255.200" > no_gateway_ip: yes > enable_dhcp: yes > mtu: 9000 > octavia_amp_network_cidr: 10.10.7.0/24 > octavia_amp_image_tag: "amphora" > octavia_certs_country: XZ > octavia_certs_state: Gotham > octavia_certs_organization: WAYNE > octavia_certs_organizational_unit: IT > horizon_keystone_multidomain: true > elasticsearch_curator_dry_run: "no" > enable_cluster_user_trust: true > > > > > > > > > > > > *ceph_rgw_hosts: - host: controllera ip: 10.10.1.5 > port: 8080 - host: controllerb ip: 10.10.1.9 > port: 8080 - host: controllerc ip: 10.10.1.13 > port: 8080ceph_rgw_swift_account_in_url: trueceph_rgw_swift_compatibility: > true* And Here is my ceph all.yml file > --- > dummy: > ceph_release_num: 16 > cluster: ceph > configure_firewall: False > *monitor_interface: bond1.10* > monitor_address_block: 10.10.1.0/24 > is_hci: true > hci_safety_factor: 0.2 > osd_memory_target: 4294967296 > *public_network: 10.10.1.0/24 <http://10.10.1.0/24>* > cluster_network: 10.10.2.0/24 > *radosgw_interface: "{{ monitor_interface }}"* > *radosgw_address_block: 10.10.1.0/24 <http://10.10.1.0/24>* > nfs_file_gw: true > nfs_obj_gw: true > ceph_docker_image: "ceph/daemon" > ceph_docker_image_tag: latest-pacific > ceph_docker_registry: 192.168.1.16:4000 > containerized_deployment: True > openstack_config: true > openstack_glance_pool: > name: "images" > pg_autoscale_mode: False > application: "rbd" > pg_num: 128 > pgp_num: 128 > target_size_ratio: 5.00 > rule_name: "SSD" > openstack_cinder_pool: > name: "volumes" > pg_autoscale_mode: False > application: "rbd" > pg_num: 1024 > pgp_num: 1024 > target_size_ratio: 42.80 > rule_name: "SSD" > openstack_nova_pool: > name: "vms" > pg_autoscale_mode: False > application: "rbd" > pg_num: 256 > pgp_num: 256 > target_size_ratio: 10.00 > rule_name: "SSD" > openstack_cinder_backup_pool: > name: "backups" > pg_autoscale_mode: False > application: "rbd" > pg_num: 512 > pgp_num: 512 > target_size_ratio: 18.00 > rule_name: "SSD" > openstack_gnocchi_pool: > name: "metrics" > pg_autoscale_mode: False > application: "rbd" > pg_num: 32 > pgp_num: 32 > target_size_ratio: 0.10 > rule_name: "SSD" > openstack_cephfs_data_pool: > name: "cephfs_data" > pg_autoscale_mode: False > application: "cephfs" > pg_num: 256 > pgp_num: 256 > target_size_ratio: 10.00 > rule_name: "SSD" > openstack_cephfs_metadata_pool: > name: "cephfs_metadata" > pg_autoscale_mode: False > application: "cephfs" > pg_num: 32 > pgp_num: 32 > target_size_ratio: 0.10 > rule_name: "SSD" > openstack_pools: > - "{{ openstack_glance_pool }}" > - "{{ openstack_cinder_pool }}" > - "{{ openstack_nova_pool }}" > - "{{ openstack_cinder_backup_pool }}" > - "{{ openstack_gnocchi_pool }}" > - "{{ openstack_cephfs_data_pool }}" > - "{{ openstack_cephfs_metadata_pool }}" > openstack_keys: > - { name: client.glance, caps: { mon: "profile rbd", osd: "profile rbd > pool={{ openstack_cinder_pool.name }}, profile rbd pool={{ > openstack_glance_pool.name }}"}, mode: "0600" } > - { name: client.cinder, caps: { mon: "profile rbd", osd: "profile rbd > pool={{ openstack_cinder_pool.name }}, profile rbd pool={{ > openstack_nova_pool.name }}, profile rbd pool={{ > openstack_glance_pool.name }}"}, mode: "0600" } > - { name: client.cinder-backup, caps: { mon: "profile rbd", osd: > "profile rbd pool={{ openstack_cinder_backup_pool.name }}"}, mode: "0600" > } > - { name: client.gnocchi, caps: { mon: "profile rbd", osd: "profile rbd > pool={{ openstack_gnocchi_pool.name }}"}, mode: "0600", } > - { name: client.openstack, caps: { mon: "profile rbd", osd: "profile > rbd pool={{ openstack_glance_pool.name }}, profile rbd pool={{ > openstack_nova_pool.name }}, profile rbd pool={{ > openstack_cinder_pool.name }}, profile rbd pool={{ > openstack_cinder_backup_pool.name }}"}, mode: "0600" } > dashboard_enabled: True > dashboard_protocol: https > dashboard_port: 8443 > dashboard_network: "192.168.1.0/24" > dashboard_admin_user: admin > dashboard_admin_user_ro: true > dashboard_admin_password: *********** > dashboard_crt: '/home/deployer/work/site-central/chaininv.crt' > dashboard_key: '/home/deployer/work/site-central/cloud_example.com.priv' > dashboard_grafana_api_no_ssl_verify: true > dashboard_rgw_api_user_id: admin > dashboard_rgw_api_no_ssl_verify: true > dashboard_frontend_vip: '192.168.1.5' > node_exporter_container_image: " > 192.168.1.16:4000/prom/node-exporter:v0.17.0" > grafana_admin_user: admin > grafana_admin_password: ********* > grafana_crt: '/home/deployer/work/site-central/chaininv.crt' > grafana_key: '/home/deployer/work/site-central/cloud_example.com.priv' > grafana_server_fqdn: 'grafanasrv.cloud.example.com' > grafana_container_image: "192.168.1.16:4000/grafana/grafana:6.7.4" > grafana_dashboard_version: pacific > prometheus_container_image: "192.168.1.16:4000/prom/prometheus:v2.7.2" > alertmanager_container_image: "192.168.1.16:4000/prom/alertmanager:v0.16.2 > " > And my rgws.yml > --- > dummy: > copy_admin_key: true > rgw_create_pools: > "{{ rgw_zone }}.rgw.buckets.data": > pg_num: 256 > pgp_num: 256 > size: 3 > type: replicated > pg_autoscale_mode: False > rule_id: 1 > "{{ rgw_zone }}.rgw.buckets.index": > pg_num: 64 > pgp_num: 64 > size: 3 > type: replicated > pg_autoscale_mode: False > rule_id: 1 > "{{ rgw_zone }}.rgw.meta": > pg_num: 32 > pgp_num: 32 > size: 3 > type: replicated > pg_autoscale_mode: False > rule_id: 1 > "{{ rgw_zone }}.rgw.log": > pg_num: 32 > pgp_num: 32 > size: 3 > type: replicated > pg_autoscale_mode: False > rule_id: 1 > "{{ rgw_zone }}.rgw.control": > pg_num: 32 > pgp_num: 32 > size: 3 > type: replicated > pg_autoscale_mode: False > rule_id: 1 > The ceph_rgw user was created by kolla (xenavenv) [deployer@rscdeployer ~]$ openstack user list | grep ceph | 3262aa7e03ab49c8a5710dfe3b16a136 | ceph_rgw This is my ceph.conf from one of my controllers : > [root@controllera ~]# cat /etc/ceph/ceph.conf > [client.rgw.controllera.rgw0] > host = controllera > rgw_keystone_url = https://dash.cloud.example.com:5000 > ##Authentication using username, password and tenant. Preferred. > rgw_keystone_verify_ssl = false > rgw_keystone_api_version = 3 > rgw_keystone_admin_user = ceph_rgw > rgw_keystone_admin_password = cos2Jcnpnw9BhGwvPm************************** > rgw_keystone_admin_domain = Default > rgw_keystone_admin_project = service > rgw_s3_auth_use_keystone = true > rgw_keystone_accepted_roles = admin > rgw_keystone_implicit_tenants = true > rgw_swift_account_in_url = true > keyring = /var/lib/ceph/radosgw/ceph-rgw.controllera.rgw0/keyring > log file = /var/log/ceph/ceph-rgw-controllera.rgw0.log > rgw frontends = beast endpoint=10.10.1.5:8080 > rgw thread pool size = 512 > #For Debug > debug ms = 1 > debug rgw = 20 > > > # Please do not change this file directly since it is managed by Ansible > and will be overwritten > [global] > cluster network = 10.10.2.0/24 > fsid = da094354-6ade-415a-a424-************ > mon host = [v2:10.10.1.5:3300,v1:10.10.1.5:6789],[v2:10.10.1.9:3300,v1: > 10.10.1.9:6789],[v2:10.10.1.13:3300,v1:10.10.1.13:6789] > mon initial members = controllera,controllerb,controllerc > osd pool default crush rule = 1 > *public network = 10.10.1.0/24 <http://10.10.1.0/24>* > Here are my swift endpoints (xenavenv) [deployer@rscdeployer ~]$ openstack endpoint list | grep swift | 4082b4acf8bc4e4c9efc6e2d0e293724 | RegionOne | swift | object-store | True | admin | https://dashint.cloud.example.com:6780/v1/AUTH_%(project_id)s | | b13a2f53e13e4650b4efdb8184eb0211 | RegionOne | swift | object-store | True | internal | https://dashint.cloud.example.com:6780/v1/AUTH_%(project_id)s | | f85b36ff9a2b49bc9eaadf1aafdee28c | RegionOne | swift | object-store | True | public | https://dash.cloud.example.com:6780/v1/AUTH_%(project_id)s | When I connect to Horizon -> Project -> Object Store -> Containers I get theses errors : - Unable to get the swift container listing - Unable to fetch the policy details. I cannot create a new container from the WebUI, the Storage policy parameter is empty. If I try to create a new container from the CLI, I get this : (xenavenv) [deployer@rscdeployer ~]$ source cephrgw-openrc.sh (xenavenv) [deployer@rscdeployer ~]$ openstack container create demo -v START with options: container create demo -v command: container create -> openstackclient.object.v1.container.CreateContainer (auth=True) Using auth plugin: password Not Found (HTTP 404) END return value: 1 This is the log from RGW service when I execute the above command : > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 CONTENT_LENGTH=0 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 HTTP_ACCEPT=*/* > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 HTTP_ACCEPT_ENCODING=gzip, > deflate > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 HTTP_HOST= > dashint.cloud.example.com:6780 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 > HTTP_USER_AGENT=openstacksdk/0.59.0 keystoneauth1/4.4.0 > python-requests/2.26.0 CPython/3.8.8 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 HTTP_VERSION=1.1 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 > HTTP_X_AUTH_TOKEN=gAAAAABiXUrjDFNzXx03mt1lbpUiCqNND1HACspSfg6h_TMxKYND5Hb9BO3FxH0a7CYoBXgRJywGszlK8cl-7zbUNRjHmxgIzmyh-CrWyGv793ZLOAmT_XShcrIKThjIIH3gTxYoX1TXwOKbsvMuZnI5EKKsol2y2MhcqPLeLGc28_AwoOr_b80 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 > HTTP_X_FORWARDED_FOR=10.10.3.16 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 HTTP_X_FORWARDED_PROTO=https > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 REMOTE_ADDR=10.10.1.13 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 REQUEST_METHOD=PUT > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 > REQUEST_URI=/v1/AUTH_971efa4cb18f42f7a405342072c39c9d/demo > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 > SCRIPT_URI=/v1/AUTH_971efa4cb18f42f7a405342072c39c9d/demo > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 SERVER_PORT=8080 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 1 ====== starting new request > req=0x7f23221aa620 ===== > 2022-04-18T12:26:27.995+0100 7f22e07a9700 2 req 728157015944164764 > 0.000000000s initializing for trans_id = > tx000000a1aeef2b40f759c-00625d4ae3-4b389-default > 2022-04-18T12:26:27.995+0100 7f22e07a9700 10 req 728157015944164764 > 0.000000000s rgw api priority: s3=8 s3website=7 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 10 req 728157015944164764 > 0.000000000s host=dashint.cloud.example.com > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 req 728157015944164764 > 0.000000000s subdomain= domain= in_hosted_domain=0 > in_hosted_domain_s3website=0 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 req 728157015944164764 > 0.000000000s final domain/bucket subdomain= domain= in_hosted_domain=0 > in_hosted_domain_s3website=0 s->info.domain= > s->info.request_uri=/v1/AUTH_971efa4cb18f42f7a405342072c39c9d/demo > 2022-04-18T12:26:27.995+0100 7f22e07a9700 20 req 728157015944164764 > 0.000000000s get_handler handler=22RGWHandler_REST_Obj_S3 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 10 req 728157015944164764 > 0.000000000s handler=22RGWHandler_REST_Obj_S3 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 2 req 728157015944164764 > 0.000000000s getting op 1 > 2022-04-18T12:26:27.995+0100 7f22e07a9700 1 -- 10.10.1.13:0/2715436964 > --> [v2:10.10.1.7:6801/4815,v1:10.10.1.7:6803/4815] -- > osd_op(unknown.0.0:1516 12.3 12:c14cb721:::script.prerequest.:head [call > version.read in=11b,getxattrs,stat] snapc 0=[] > ondisk+read+known_if_redirected e1182) v8 -- 0x56055eb2c400 con > 0x56055e53b000 > 2022-04-18T12:26:27.996+0100 7f230d002700 1 -- 10.10.1.13:0/2715436964 > <== osd.23 v2:10.10.1.7:6801/4815 22 ==== osd_op_reply(1516 > script.prerequest. [call,getxattrs,stat] v0'0 uv0 ondisk = -2 ((2) No such > file or directory)) v8 ==== 246+0+0 (crc 0 0 0) 0x56055ea18b40 con > 0x56055e53b000 > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 10 req 728157015944164764 > 0.001000002s s3:put_obj scheduling with throttler client=2 cost=1 > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 10 req 728157015944164764 > 0.001000002s s3:put_obj op=21RGWPutObj_ObjStore_S3 > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 2 req 728157015944164764 > 0.001000002s s3:put_obj verifying requester > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 20 req 728157015944164764 > 0.001000002s s3:put_obj rgw::auth::StrategyRegistry::s3_main_strategy_t: > trying rgw::auth::s3::AWSAuthStrategy > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 20 req 728157015944164764 > 0.001000002s s3:put_obj rgw::auth::s3::AWSAuthStrategy: trying > rgw::auth::s3::S3AnonymousEngine > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 20 req 728157015944164764 > 0.001000002s s3:put_obj rgw::auth::s3::S3AnonymousEngine granted access > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 20 req 728157015944164764 > 0.001000002s s3:put_obj rgw::auth::s3::AWSAuthStrategy granted access > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 2 req 728157015944164764 > 0.001000002s s3:put_obj normalizing buckets and tenants > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 10 req 728157015944164764 > 0.001000002s s->object=AUTH_971efa4cb18f42f7a405342072c39c9d/demo > s->bucket=v1 > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 2 req 728157015944164764 > 0.001000002s s3:put_obj init permissions > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 20 req 728157015944164764 > 0.001000002s s3:put_obj get_system_obj_state: rctx=0x7f23221a9000 > obj=default.rgw.meta:root:v1 state=0x56055ea8c520 s->prefetch_data=0 > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 10 req 728157015944164764 > 0.001000002s s3:put_obj cache get: name=default.rgw.meta+root+v1 : miss > 2022-04-18T12:26:27.996+0100 7f22ddfa4700 1 -- 10.10.1.13:0/2715436964 > --> [v2:10.10.1.3:6802/4933,v1:10.10.1.3:6806/4933] -- > osd_op(unknown.0.0:1517 11.b 11:d05f7b30:root::v1:head [call version.read > in=11b,getxattrs,stat] snapc 0=[] ondisk+read+known_if_redirected e1182) v8 > -- 0x56055eb2cc00 con 0x56055e585000 > 2022-04-18T12:26:27.997+0100 7f230c801700 1 -- 10.10.1.13:0/2715436964 > <== osd.3 v2:10.10.1.3:6802/4933 9 ==== osd_op_reply(1517 v1 > [call,getxattrs,stat] v0'0 uv0 ondisk = -2 ((2) No such file or directory)) > v8 ==== 230+0+0 (crc 0 0 0) 0x56055e39db00 con 0x56055e585000 > 2022-04-18T12:26:27.997+0100 7f22dd7a3700 10 req 728157015944164764 > 0.002000004s s3:put_obj cache put: name=default.rgw.meta+root+v1 > info.flags=0x0 > 2022-04-18T12:26:27.997+0100 7f22dd7a3700 10 req 728157015944164764 > 0.002000004s s3:put_obj adding default.rgw.meta+root+v1 to cache LRU end > 2022-04-18T12:26:27.997+0100 7f22dd7a3700 10 req 728157015944164764 > 0.002000004s s3:put_obj init_permissions on <NULL> failed, ret=-2002 > 2022-04-18T12:26:27.997+0100 7f22dd7a3700 1 req 728157015944164764 > 0.002000004s op->ERRORHANDLER: err_no=-2002 new_err_no=-2002 > 2022-04-18T12:26:27.997+0100 7f22dbfa0700 1 -- 10.10.1.13:0/2715436964 > --> [v2:10.10.1.8:6804/4817,v1:10.10.1.8:6805/4817] -- > osd_op(unknown.0.0:1518 12.1f 12:fb11263f:::script.postrequest.:head [call > version.read in=11b,getxattrs,stat] snapc 0=[] > ondisk+read+known_if_redirected e1182) v8 -- 0x56055eb2d000 con > 0x56055e94c800 > 2022-04-18T12:26:27.998+0100 7f230d002700 1 -- 10.10.1.13:0/2715436964 > <== osd.9 v2:10.10.1.8:6804/4817 10 ==== osd_op_reply(1518 > script.postrequest. [call,getxattrs,stat] v0'0 uv0 ondisk = -2 ((2) No such > file or directory)) v8 ==== 247+0+0 (crc 0 0 0) 0x56055ea18b40 con > 0x56055e94c800 > 2022-04-18T12:26:27.998+0100 7f22d8f9a700 2 req 728157015944164764 > 0.003000006s s3:put_obj op status=0 > 2022-04-18T12:26:27.998+0100 7f22d8f9a700 2 req 728157015944164764 > 0.003000006s s3:put_obj http status=404 > 2022-04-18T12:26:27.998+0100 7f22d8f9a700 1 ====== req done > req=0x7f23221aa620 op status=0 http_status=404 latency=0.003000006s ====== > 2022-04-18T12:26:27.998+0100 7f22d8f9a700 1 beast: 0x7f23221aa620: > 10.10.1.13 - anonymous [18/Apr/2022:12:26:27.995 +0100] "PUT > /v1/AUTH_971efa4cb18f42f7a405342072c39c9d/demo HTTP/1.1" 404 214 - > "openstacksdk/0.59.0 keystoneauth1/4.4.0 python-requests/2.26.0 > CPython/3.8.8" - latency=0.003000006s > Could you help please. Regards.

2 4

[Kolla][Kolla-Ansible] Unable to Deploy tacker victoria in centos 8 Stream
by Richa Gupta 19 Apr '22

19 Apr '22

We tried installing the tacker victoria release using Kolla Ansible all-in-one deployment on centos stream 8, by using the following links: https://docs.openstack.org/tacker/victoria/install/kolla.html and running prerequisites mentioned in the link below: https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html#instal… (We changed ussri to victoria at all necessary places. The globals.yml exactly matches with the one given in the OpenStack link) while running deployment we encounter the following error: RUNNING HANDLER [Waiting for rabbitmq to start] ********************************************************************************************************** fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["docker", "exec", "rabbitmq", "rabbitmqctl", "wait", "/var/lib/rabbitmq/mnesia/rabbitmq.pid"], "delta": "0:00:10.704454", "end": "2022-04-19 11:43:12.259809", "msg": "non-zero return code", "rc": 75, "start": "2022-04-19 11:43:01.555355", "stderr": "Error: operation wait on node rabbit@tacker-victoria timed out. Timeout value used: 10000", "stderr_lines": ["Error: operation wait on node rabbit@tacker-victoria timed out. Timeout value used: 10000"], "stdout": "Waiting for pid file '/var/lib/rabbitmq/mnesia/rabbitmq.pid' to appear", "stdout_lines": ["Waiting for pid file '/var/lib/rabbitmq/mnesia/rabbitmq.pid' to appear"]} RUNNING HANDLER [Restart remaining rabbitmq containers] ************************************************************************************************** NO MORE HOSTS LEFT *************************************************************************************************************************************** PLAY RECAP *********************************************************************************************************************************************** localhost : ok=77 changed=43 unreachable=0 failed=1 skipped=19 rescued=0 ignored=1 After this we run deploy again and encounter the following error: TASK [service-rabbitmq : nova | Ensure RabbitMQ users exist] *************************************************************************************************************************** FAILED - RETRYING: nova | Ensure RabbitMQ users exist (5 retries left). FAILED - RETRYING: nova | Ensure RabbitMQ users exist (4 retries left). FAILED - RETRYING: nova | Ensure RabbitMQ users exist (3 retries left). FAILED - RETRYING: nova | Ensure RabbitMQ users exist (2 retries left). FAILED - RETRYING: nova | Ensure RabbitMQ users exist (1 retries left). failed: [localhost -> localhost] (item=None) => {"attempts": 5, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false} fatal: [localhost -> {{ service_rabbitmq_delegate_host }}]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false} PLAY RECAP ***************************************************************************************************************************************************************************** localhost : ok=116 changed=42 unreachable=0 failed=1 skipped=40 rescued=0 ignored=0 Command failed ansible-playbook -i /usr/local/share/kolla-ansible/ansible/inventory/all-in-one -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e kolla_action=deploy /usr/local/share/kolla-ansible/ansible/site.yml [centos@tacker-victoria ~]$

1 0

[murano][octavia][sahara][zaqar][zun][oslo] Pending removal of 'oslo_db.sqlalchemy.test_base'
by Stephen Finucane 19 Apr '22

19 Apr '22

o/ This is a heads up to the maintainers of the aforementioned projects that the oslo team are planning to remove the 'oslo_db.sqlalchemy.test_base' module this cycle. This module has been deprecated since 2015 and we want to get rid of it to reduce load on the overburdened oslo maintainers. I have already fixed the issue in a couple of projects. These can be used as blueprints for fixing the remaining affected projects: * masakari (https://review.opendev.org/c/openstack/masakari/+/802761) * glance (https://review.opendev.org/c/openstack/glance/+/802762) * manila (https://review.opendev.org/c/openstack/manila/+/802763) I would love to fix the remaining projects but my limited time is currently focused elsewhere. The oslo.db change is available at [1]. We'd like this to be merged in the next month but we can push that out to later in the cycle if teams need more time. Just shout. Please let us know if you have any concerns or if the above changes are not sufficient as a guide for how to address these issues. Cheers, Stephen [1] https://review.opendev.org/c/openstack/oslo.db/+/798136

4 4

[neutron] CI meeting agenda for 19.04
by Slawek Kaplonski 19 Apr '22

19 Apr '22

Hi, Just quick reminder that today at 15:00 UTC we will have Neutron CI weekly meeting. It will be the video meeting this week: *https://meetpad.opendev.org/neutron-ci-meetings[1]* Agenda for the meeting is available on https://etherpad.opendev.org/p/neutron-ci-meetings#L10[2] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://meetpad.opendev.org/neutron-ci-meetings [2] https://etherpad.opendev.org/p/neutron-ci-meetings#L10

1 0

[neutron][nova] port binding fails for existing networks
by Eugen Block 19 Apr '22

19 Apr '22

Hi *, I have a kind of strange case which I'm trying to solve for hours, I could use some fresh ideas. It's a HA cloud (Victoria) deployed by Salt and the 2 control nodes are managed by pacemaker, the third controller will join soon. There are around 16 compute nodes at the moment. This two-node-control plane works well, except if there are unplanned outages. Since the last outage of one control node we struggle to revive neutron (I believe neutron is the issue here). I'll try to focus on the main issue here, let me know if more details are required. After the failed node was back online all openstack agents show as "up" (openstack compute service list, openstack network agent list). Running VMs don't seem to be impacted (as far as I can tell). But we can't create new instances in existing networks, and since we use Octavia we also can't (re)build any LBs at the moment. When I create a new test network the instance spawns successfully and is active within a few seconds. For existing networks we get the famous "port binding failed" from nova-compute.log. But I see the port being created, it just can't be attached to the instance. One more strange thing: I don't see any entries in the nova-scheduler.log or nova-conductor.log for the successfully built instance, except for the recently mentioned etcd3gw message from nova-conductor, but this didn't impact the instance creation yet. We have investigated this for hours, we have rebooted both control nodes multiple times in order to kill any remaining processes. The galera DB seems fine, rabbitmq also behaves normally (I think), we tried multiple times to put one node in standby to only have one node to look at which also didn't help. So basically we restarted everything multiple times on the control nodes and also nova-compute and openvswitch-agent on all compute nodes, the issue is still not resolved. Does anyone have further ideas to resolve this? I'd be happy to provide more details, just let me know what you need. Happy Easter! Eugen

3 5

OPS Meetup Meeting tomorrow
by Amy Marrich 19 Apr '22

19 Apr '22

Just a reminder that the OPS Meetup team will meet tomorrow morning at 13:00 UTC in the #openstack-operators room on OFTC. See you there!

1 0

[TripleO] Final TripleO repos release for stable/victoria - any requests?
by Marios Andreou 19 Apr '22

19 Apr '22

Hello The stable/victoria branch for all tripleo repos will transition to Extended Maintenance in 2 weeks [1]. To prevent delays I have prepared a final victoria release at [2]. That [2] will be updated after its depends-on merges (puppet metadata bump) to pickup the latest victoria commits at that point. If there are any patches you want included then please speak up and I'll wait for and include those commits before updating releases/+/836921 [2]. This is the last ever release to be made from stable/victoria. Once it goes to Extended Maintenance we can no longer release. I'll hold it for a few days.. Unless I hear otherwise I will update [2] on Monday and try to get it merged next week. thanks, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028013.ht… [2] https://review.opendev.org/c/openstack/releases/+/836921

2 3

[Neutron] Bug deputy report April 11 - April 18
by Jakub Libosvar 19 Apr '22

19 Apr '22

Hi all, I was the bug deputy for the previous week. There is one critical bug from Slawek with proposed revert. Here is the report: Critical -------- - Test tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_instance_port_admin_state is failing constantly since 7.04.2022 https://bugs.launchpad.net/neutron/+bug/1968896 Revert proposed: https://review.opendev.org/c/openstack/neutron/+/837685 Medium ------ - neutron-dhcp-agent memory leak on network sync failure https://bugs.launchpad.net/neutron/+bug/1969270 Needs an assignee - [L3-DVR]l3-agent arp table will not update https://bugs.launchpad.net/neutron/+bug/1968860 Needs an assignee - network DHCP agent ports status is DOWN in multi network creation simultaneously https://bugs.launchpad.net/neutron/+bug/1968859 Needs an assignee - Importing neutron.common.config module registers config options https://bugs.launchpad.net/neutron/+bug/1968606 Proposed fix: https://review.opendev.org/c/openstack/neutron/+/837392 Incomplete ---------- - unable to attach an interface to an external network https://bugs.launchpad.net/neutron/+bug/1968893 Looks like configuration issue, more logs are needed - too many l3 dvr agents got notifications after a server got deleted https://bugs.launchpad.net/neutron/+bug/1968837 I'm not sure I understand what the issue is Invalid ------- - ovn-controller don't update new flows https://bugs.launchpad.net/neutron/+bug/1969354 It looks like misconfigured environment, provided some tips

1 0

[ironic] Skipping today's upstream meeting
by Iury Gregory 18 Apr '22

18 Apr '22

Hi Ironicers, We will skip the weekly meeting this week, since we have Easter Holidays and other holidays in some countries =) ) -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[neutron] Mysql FK Errors
by Ammad Syed 18 Apr '22

18 Apr '22

Hi, I am using neutron 19.1 with OVN backend. I am receiving below mentioned errors in my percona xtradb cluster logs for neutron database. 2022-04-04T15:39:17.342175+05:00 187579 [ERROR] [MY-011825] [InnoDB] WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron_ml2`.`portsecuritybindings` 2022-04-05T14:18:19.801183+05:00 275503 [ERROR] [MY-011825] [InnoDB] WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron_ml2`.`ml2_port_binding_levels` Can you guys advice about these errors. Is there anything to worry about? or should I just ignore them ? Ammad

1 0

[Trove][Xena] Error building Trove image
by wodel youchi 17 Apr '22

17 Apr '22

Hi, When trying to build Trove I am getting this error message : 2022-04-10 08:55:25.497 | *+ install_deb_packages install iscsi-initiator-utils* 2022-04-10 08:55:25.497 | + DEBIAN_FRONTEND=noninteractive 2022-04-10 08:55:25.497 | + http_proxy= 2022-04-10 08:55:25.497 | + https_proxy= 2022-04-10 08:55:25.497 | + no_proxy= 2022-04-10 08:55:25.497 | + apt-get --option Dpkg::Options::=--force-confold --option Dpkg::Options::=--force-confdef --assume-yes install iscsi-initiator-utils 2022-04-10 08:55:25.541 | Reading package lists... 2022-04-10 08:55:25.788 | Building dependency tree... 2022-04-10 08:55:25.788 | Reading state information... 2022-04-10 08:55:25.825 | *E: Unable to locate package iscsi-initiator-utils* 2022-04-10 08:55:25.838 | ++ diskimage_builder/lib/img-functions:run_in_target:59 : check_break after-error run_in_target bash 2022-04-10 08:55:25.843 | ++ diskimage_builder/lib/common-functions:check_break:143 : echo '' 2022-04-10 08:55:25.844 | ++ diskimage_builder/lib/common-functions:check_break:143 : egrep -e '(,|^)after-error(,|$)' -q 2022-04-10 08:55:25.851 | + diskimage_builder/lib/img-functions:run_in_target:1 : trap_cleanup 2022-04-10 08:55:25.855 | + diskimage_builder/lib/img-functions:trap_cleanup:36 I am not an Ubuntu person but I think the package's name is open-iscsi. This is the command I used to build the image : ./trovestack build-image ubuntu bionic true ubuntu /home/stack/trove-xena-guest-ubuntu-bionic-dev.qcow2 My OS is a Centos 8 Stream. you can find the whole log of the operation attached. Thanks in advance. Regards.

2 1

Re: [Trove][Xena] Error building Trove image
by Hirotaka Wakabayashi 16 Apr '22

16 Apr '22

Hi Wodel, I think you need to fix DIB element files to build a guest image as CentOS Stream. Officially supported operating system in Trove is currently Ubuntu[1]. I am preparing Installation instructions Fedora/CentOS Stream users[2] but that is not completed. You may not really need to build a guest image as CentOS Stream if you are a mysql or postgresql user, because Trove supports Docker Since Victoria. This means database service can runs as docker container inside the Trove instance. You can define the datastore image by using the "docker_image" config option[4]. --- [1]: https://docs.openstack.org/trove/latest/admin/building_guest_images.html [2]: https://storyboard.openstack.org/#!/story/2009918 [3]: https://opendev.org/openstack/trove/src/branch/master/integration/scripts/f… [4]: https://docs.openstack.org/trove/latest/admin/run_trove_in_production.html#… Regards,Hirotaka On Wednesday, April 13, 2022, 10:04:53 PM GMT+9, <openstack-discuss-request(a)lists.openstack.org> wrote: Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. [Trove][Xena] Error building Trove image (wodel youchi) ---------------------------------------------------------------------- Message: 1 Date: Wed, 13 Apr 2022 00:16:59 +0100 From: wodel youchi <wodel.youchi(a)gmail.com> To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: [Trove][Xena] Error building Trove image Message-ID: <CAJV_UBCZVOKmjvwdDJW0w17g39L8MVHuZNOQJ7yH2DZNFnqZbA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, When trying to build Trove I am getting this error message : 2022-04-10 08:55:25.497 | *+ install_deb_packages install iscsi-initiator-utils* 2022-04-10 08:55:25.497 | + DEBIAN_FRONTEND=noninteractive 2022-04-10 08:55:25.497 | + http_proxy= 2022-04-10 08:55:25.497 | + https_proxy= 2022-04-10 08:55:25.497 | + no_proxy= 2022-04-10 08:55:25.497 | + apt-get --option Dpkg::Options::=--force-confold --option Dpkg::Options::=--force-confdef --assume-yes install iscsi-initiator-utils 2022-04-10 08:55:25.541 | Reading package lists... 2022-04-10 08:55:25.788 | Building dependency tree... 2022-04-10 08:55:25.788 | Reading state information... 2022-04-10 08:55:25.825 | *E: Unable to locate package iscsi-initiator-utils* 2022-04-10 08:55:25.838 | ++ diskimage_builder/lib/img-functions:run_in_target:59 : check_break after-error run_in_target bash 2022-04-10 08:55:25.843 | ++ diskimage_builder/lib/common-functions:check_break:143 : echo '' 2022-04-10 08:55:25.844 | ++ diskimage_builder/lib/common-functions:check_break:143 : egrep -e '(,|^)after-error(,|$)' -q 2022-04-10 08:55:25.851 | + diskimage_builder/lib/img-functions:run_in_target:1 : trap_cleanup 2022-04-10 08:55:25.855 | + diskimage_builder/lib/img-functions:trap_cleanup:36 I am not an Ubuntu person but I think the package's name is open-iscsi. This is the command I used to build the image : ./trovestack build-image ubuntu bionic true ubuntu /home/stack/trove-xena-guest-ubuntu-bionic-dev.qcow2 My OS is a Centos 8 Stream. you can find the whole log of the operation attached. Thanks in advance. Regards.

1 0

[Kolla-ansible][Glance] Glance HA deployment with shared file backend
by Rodrigo Lima 16 Apr '22

16 Apr '22

Hi Guys, hope all is well! According with the kolla-ansible documentation, " By default when using file backend only one glance-api container can be running." So my questions is quite simple: Can I deploy multiple glance_api containers in HA mode (like if I used ceph or swift backend) if I use a shared filesystem (eg. NFS) in all glance nodes? If I can do so, what I need to change in deployment files/scripts/yaml?

2 1

[all][tc] What's happening in Technical Committee: summary April 15th, 21: Reading: 10 min
by Ghanshyam Mann 16 Apr '22

16 Apr '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We cancelled this week's meeting. * Next TC weekly meeting will be on April 21st Thursday 15:00 UTC, feel free to add the topic on the agenda[1] by April 20th. 2. What we completed this week: ========================= * Added goal readiness checklist[2] * Retired openstack-health[3] * Retired tempest-lib[4] * Add Ganesha based Ceph NFS Charm[5] * PTG summary sent to ML[6] 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * With the Zed cycle kickoff[7], I have started the Zed cycle TC tracker by listing all the items we discussed in PTG but we will add more during the cycle also if something important comes up[8] Open Reviews ----------------- * Seven open reviews for ongoing activities[9]. Drop the lower constraints maintenance ------------------------------------------------ This has been going on for many months, if I remember correctly it was first brought up in Dec 2021. During those discussions, we figured out that maintaining and testing the lower constraints has many challenges. TC discussed all those challenges in Zed PTG and agreed to drop lower-constraints.txt file and its testing but keep them in requirements.txt with our best effort. I proposed the TC resolution on this[10], feel free to feedback there if there is any strong objection in this direction. Also sent it on ML[11] Consistent and Secure Default RBAC -------------------------------------------- I summarized the RBAC PTG discussion[12], we did not finish the discussion over the open question and decided to continue it in RBAC meetings later. I will schedule the next meeting soon. If you have any other questions than the current one, please add them to the etherpad[13] Removing the TC tag framework ---------------------------------- In TC tag framework, every TC member used to assign a few projects to check their health, needs from TC etc. It was meant to improve the interaction between TC and PTLs and contact points for any projects when TC needs it. But it did not go that way and even many of us do not know if that still exists or not. With TC weekly meetings and PTG interaction sessions, we anyways are more contacted with leaders and discussed it in PTG and agreed to remove this framework. I have proposed the removal[14] 2021 User Survey TC Question Analysis ----------------------------------------------- Jay has summarized the TC's user survey in PTG and it is up in gerrit for review[15]. Feel free to check and provide feedback. Zed cycle Leaderless projects ---------------------------------- Zaqar PTL assigned is merged[16], with that only Adjutant project is leaderless/maintainer-less. We will check Adjutant's situation again on ML and hope Braden will be ready with their company side permission[17]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[18]. Project updates ------------------- * Add the cinder-three-par charm to Openstack charms[19] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[20]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [21] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/835102 [3] https://review.opendev.org/c/openstack/governance/+/836706 [4] https://review.opendev.org/c/openstack/governance/+/836704 [5] https://review.opendev.org/c/openstack/governance/+/835429 [6] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028104.ht… [7] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028206.ht… [8] https://etherpad.opendev.org/p/tc-zed-tracker [9] https://review.opendev.org/q/projects:openstack/governance+status:open [10] https://review.opendev.org/c/openstack/governance/+/838004 [11] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028199.ht… [12] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028103.ht… [13] https://etherpad.opendev.org/p/rbac-zed-ptg [14] https://review.opendev.org/c/openstack/governance/+/837891 [15] https://review.opendev.org/c/openstack/governance/+/836888 [16] https://review.opendev.org/c/openstack/governance/+/831123 [17] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.ht… [18] https://etherpad.opendev.org/p/zuul-config-error-openstack [19] https://review.opendev.org/c/openstack/governance/+/837781 [20] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [21] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[all][tc] Technical Committee Zed cycle Kick-Off
by Ghanshyam Mann 16 Apr '22

16 Apr '22

Hello Everyone, In PTG, we decided to continue the TC per-cycle-tracker which help us to finish the things within the timeframe of one cycle. During PTG week (TC+leader interaction and TC-related sessions), we had a lot of productive discussions[1] and collected many working items for TC. The Technical Committee's main goal is to drive more technical work to solve the OpenStack existing technical challenges. This is the main feedback from the community to TC working and I am happy to have that feedback, as well as TC, started working on it in a more productive way. Of course, we will continue doing the governance part too which does not take much bandwidth of TC members and we will also try to minimize such process-related tasks as per the current situation and needs of the community. In the Zed cycle also, we will continue to focus on the Technical works. I have created the Zed cycle TC tracker and we will be targeting 7 Technical items + 4 process/governance-focused items. Also, we will be open to taking more items if anything important comes up in between the cycle. - https://etherpad.opendev.org/p/tc-zed-tracker With that, let's continue to work together and have another successful cycle. Feel free to reach out to TC at any time (does not need to wait for the weekly meeting) for your queries or help. Also, you can find all the cycle wise trackers on this wiki page[2] [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028104.ht… [2] https://wiki.openstack.org/wiki/Technical_Committee_Tracker -gmann

1 0

[TripleO][Ceph] Zed PTG Summary
by Francesco Pantano 15 Apr '22

15 Apr '22

Hello everyone, Here are a few highlights on the TripleO Ceph integration status and the plans for the next cycle. *1. Deployed ceph as a separate step* TripleO now provides a different stage (with a new cli set of commands) to bootstrap the Ceph cluster before reaching the overcloud deployment phase. This is the new default approach since Wallaby, and the short term plan is to work on the upstream CI consolidation to make sure we run this stage on the existing TripleO standalone scenarios, extending the coverage to both phases (before the overcloud deployment, when the Ceph cluster is created, and during the overcloud deployment, when the cluster is finalized according to the enabled services). It's worth mentioning that great progress in this direction has been made, and the collaboration with the tripleo-ci is one of the key points here, as they're helping on the automation aspect to test upstream pending bits with daily jobs. The next step will be working together on the automation of the promotion mechanism, which is supposed to make this process less error-prone. *2. Decouple Ceph Upgrades* Nautilus to Pacific is still managed by ceph-ansible but the stage of upgrading the cluster has been moved before the overcloud upgrade, resulting in a different maintenance window. Once the cluster is moved to Pacific, cephadm is enabled, and from this moment onwards, the upgrade process, as well as minor updates, will be managed by cephadm and can be seen as a day2 operation. The operator can now perform these kinds of tasks without any interaction with TripleO, which is still used to pull the new containers (unless another registry reachable from the overcloud is used), but the scope has been limited. *3. Ganesha transitioning to Ceph orchestrator and Ingress migration* This has been the main topic for this first ptg session: the feature it's tracked by two already approved upstream specs and the goal is to support a Ganesha service managed by cephadm instead of a tripleo-managed one. The TripleO conversation impacted many areas: *a.* the networkv2 flow has been improved and it's now possible to reserve more than 1 VIP per network, but it applies only to the ceph services; *b.* a new TripleO resource, the CephIngress daemon, has been added, and it's a key component (provided by Ceph) that is supposed to provide HA for the ceph-nfs managed daemon *c.* The tripleo cli is extended and the ceph-nfs daemon can be deployed during the bootstrap of the ceph cluster *d.* This feature depends on the manila driver development [1], which represents an effort to implement a driver that can interact with the Ceph orch cli (and the layer it provides for nfs) instead of using dbus. Further information about this conversation can be found here [1]. Part of this conversation (and really good input here actually) was about the migration plan for already existing environments where operators would like to move from a TripleO managed Ganesha to a highly available ceph-nfs managed by cephadm. The outcome here is: *1.* It's possible to move to the cephadm managed ingress daemon during the upgrade under certain constraints, but we should provide tools to finalize the migration because there's an impact not only on the server-side (and the manila service itself) but also on the clients where the shares are mounted; *2.* We might want to have options to keep the PCS managed VIP for Ganesha and avoid forcing people to migrate, and this flow should be consistent at tripleo heat templates level; For those who are interested, here's the etherpad [2] and the recording of the session [3]. Thanks, Francesco [1] https://etherpad.opendev.org/p/zorilla-ptg-manila-planning [2] https://etherpad.opendev.org/p/tripleo-zed-ceph [3] https://slagle.fedorapeople.org/tripleo-zed-ptg/tripleo-zed-ptg-ceph.mp4 -- Francesco Pantano GPG KEY: F41BD75C

1 0

[tacker] Zed PTG summary
by Yasufumi Ogawa 15 Apr '22

15 Apr '22

Hi, Thank you for joining the PTG. Here is a summary of Zed PTG of Tacker. We discussed 17 proposals through three days and agreed to whole topics. The details of proposals are on the PTG's etherpad [1]. - heat-translator maintenance - Ayumu Ueha proposed himself as a core of heat-translator from Tacker team and approved by the team. - Enhance security of APIs from Tacker for validating the certificate of a destination server. - Enhancement of Tacker-horizon Dashboard for enabling some Day2 operations (might include a part of Day0/1 operations), such as manual heal, modify VNF, change the configuration of VNFM, etc, and monitoring through GUI This blueprint proposes to extend the tacker-horizon dashboard with some new interfaces and functionalities. - Support VNF using Hardware Acceleration such as GPU, FPGA, ASIC. - Remove restrictions of using Helm Chart. - v1 API Refactoring in order to maintain and extend Tacker continuously, it's important to improve the maintainability of the v1 API. - CLI support for paging query results to improve usability of the cli tool. - We still need to discuss how we provide the pagination of the results. - Support multi artifact of ansible driver. It's already to be under reviewing. https://review.opendev.org/c/openstack/tacker/+/836107 - Enhance Multi tenant policy in LCM for enhancing of the multi-tenant policy in the VNF lifecycle management. It enables a non-admin role user to instantiate VNF, and defines tenancy isolation between admin and the non-admin role users. - Enhancement of CNF operations for k8s usecases. - https://blueprints.launchpad.net/tacker/+spec/database synchronization - https://blueprints.launchpad.net/tacker/+spec/enhance-cnf-lcm - https://blueprints.launchpad.net/tacker/+spec/enhancement-container-update - https://blueprints.launchpad.net/tacker/+spec/suport-openid-k8s-vim - https://blueprints.launchpad.net/tacker/+spec/support-instantiationlevel-cnf - Support of automatic operations - https://blueprints.launchpad.net/tacker/+spec/support-auto-lcm - https://blueprints.launchpad.net/tacker/+spec/support-autoheal-queue - Improve V2 code's UT Coverage and refactoring Tacker from caishuwen. - Enhance VNF Update functionality. - https://blueprints.launchpad.net/tacker/+spec/enhance-change-package - https://blueprints.launchpad.net/tacker/+spec/individual-vnfc-management - Support HA-cluster for high availability is an important requirement to apply Tacker to commercial systems. HA cluster such as ACT-SBY or N-ACT will be supported. - Enhance vnflcm API (hirofumi-noguchi) - https://blueprints.launchpad.net/tacker/+spec/enhance-placement - https://blueprints.launchpad.net/tacker/+spec/enhance-utils-extmanagedvl - https://blueprints.launchpad.net/tacker/+spec/multi-version-vnfd - https://blueprints.launchpad.net/tacker/+spec/sol004-package-management - https://blueprints.launchpad.net/tacker/+spec/support-subscription-cli - https://blueprints.launchpad.net/tacker/+spec/vim-management-reorganization - https://blueprints.launchpad.net/tacker/+spec/abolish-default-vim - Tacker's new requirements for commercial systems (hirofumi-noguchi) - https://blueprints.launchpad.net/tacker/+spec/enhance-system-management - https://blueprints.launchpad.net/tacker/+spec/command-conflict-handling - https://blueprints.launchpad.net/tacker/+spec/system-performance-management [1] https://etherpad.opendev.org/p/tacker-zed-ptg Thanks, Yasufumi

1 0

[largescale-sig] Large Scale SIG Forum session in Berlin?
by Thierry Carrez 15 Apr '22

15 Apr '22

Hi everyone, The CFP for Forum sessions is open until Wednesday next week at: https://cfp.openstack.org/app/berlin-2022/18/presentations Should we file a session for the Large Scale SIG? Could be a generic session ("Meet the Large Scale SIG") or a more precise topic. -- Thierry Carrez (ttx)

1 0

client authentication - ? gui okey but cli fails
by lejeczek 15 Apr '22

15 Apr '22

Hi guys. An end user here thus please tailor your advice according - meaning that I have no admin access. With GUI in a web browser I do log in but with CLI I get "usual": The request you have made requires authentication. (HTTP 401) (Request-ID:.... (rc file downloaded off the GUI) What can be the issue? many thanks, L.

2 1

[all][tc] Dropping the lower constraints maintenance
by Ghanshyam Mann 15 Apr '22

15 Apr '22

Hello Everyone, In zed cycle PTG, TC discussed the lower constraints maintenance again and after considering all the existing and current issues (discussed any times in the ML thread[1]), we agreed to drop the lower-constraints.txt file, x env, and its testing on master as well as on stable branches. But for reference to anyone using them (Debian as we know), we will keep them as it is in the requirements.txt file with our best effort to keep them up to date. I have proposed the TC resolution for this, if you have any feedback please add it on Gerrit patch: - https://review.opendev.org/c/openstack/governance/+/838004 [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019659.… http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390… http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.… -gmann

1 0

[cyborg][zun][masakari][freezer-api][heat][tacker][oslo] Pending removal of 'oslo_db.sqlalchemy.enginefacade.LegacyEngineFacade'
by Stephen Finucane 15 Apr '22

15 Apr '22

o/ This is a heads up to the maintainers of the aforementioned projects that the oslo team are planning to remove the 'oslo_db.sqlalchemy.enginefacade.LegacyEngineFacade' class and related 'get_legacy_facade' helpers this cycle. The legacy engine facade pattern has been deprecated since 2015 and we want to get rid of it to reduce load on the overburdened oslo maintainers. The prefered alternative is to rely on oslo.context RequestContext-based session management. The work required to migrate can be quite significant depending on how large your DB API is but it is pretty trivial. This issue has already been fixed in a couple of projects. These can be used as blueprints for fixing the remaining affected projects: * cinder (https://review.opendev.org/q/topic:remove-legacyfacade) * nova (https://review.opendev.org/q/topic:bp%252Fnew-oslodb-enginefacade) We expect this one to take affected projects a while to resolve, so we won't remove this module until near the end of the cycle. However, this thing really needs to be removed sooner rather than later. Please let us know if you have any concerns or if the above changes are not sufficient as a guide for how to address these issues. Cheers, Stephen

1 0

[neutron] Drivers meeting - Friday 15.4.2022 - cancelled
by Lajos Katona 15 Apr '22

15 Apr '22

Hi Neutron Drivers! We have Good Friday this week, so let's cancel the drivers meeting for this week. See you at the meeting next week. Lajos Katona (lajoskatona)

1 0

[all] Devstack jobs are failing due to a git security fix
by Michael Johnson 14 Apr '22

14 Apr '22

tldr: All devstack based jobs are going to fail with newer versions of git - don't bother rechecking git has released a security fix [1] that is starting to roll out in distributions (Ubuntu focal for example) that will cause pbr to be unable to access the package metadata for packages checked out locally due to the directory ownership used in devstack. We have opened a devstack bug to track this issue: https://bugs.launchpad.net/devstack/+bug/1968798 Please see the bug for the details and example error. Michael P.S. Thanks to clarkb, fungi, and ianw for helping track down the root cause! [1] https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9

7 11

[puppet] How to disable installation of mysql::server and only create databases?
by Christian Rohmann 14 Apr '22

14 Apr '22

Hey openstack-discuss, is there any intended way of using e.g cinder::db::mysql (which is using puppet-openstacklib) to create databases, but not also run / include mysql::server which apparently happens at https://github.com/openstack/puppet-openstacklib/blob/33fb90326fadd59759d4a… ? In short I already have a running database server and only want the databases to be created. Thanks, Christian

2 2

[manila] Zed PTG summary
by Carlos Silva 14 Apr '22

14 Apr '22

Hello, zorillas and interested stackers! Thank you for attending the PTG over the last week. We had a good audience and a lot of good discussions over the proposed topics. On the official etherpad [9] you will find the notes we took during the discussions, as well as links to additional etherpads or other references. The YouTube playlist [14] holds all the recordings we had over the week. Every video corresponds to one PTG day, and their description contains the exact time frame of the discussions. *== Xena cycle retrospective ==* * We agreed and were happy with the events we have been doing in the community (collaborative review sessions, bugsquashes and some other). They help us to understand the changes that are coming in every cycle, and also get to share knowledge with the contributors. For this cycle we will define different themes for our bugsquashes. Some dates are already defined. * We agreed on the importance of the reviews from different affiliations and we decided on a few practices to involve more community members in the review process. * We brought up the enhancements we need to do in the Manila UI, and mentioned some features that we are lacking for feature parity compared to the Manila core code. * We decided to host a hackathon in the beginning of the cycle, as we had a very positive output from the last one we had. This one can focus on the functional testing of the OSC for Manila, which we are lacking. * During the Z cycle we will host the first code walkthrough for Manila. (kudos for gouthamr for the idea). The intention of this event is to help the new contributors to better understand the code and allow them to ask questions, as well as explain the structure of our repositories and go over some key parts of Manila. * We discussed the difficulties we are facing with ethercalc and we got to a point where we saw there was no alternative way to replace it. More details about the retrospective available in [1]. *== Thin Provisioning and Oversubscription improvements ==* * haixin and gouthamr brought up this topic after a few discussions on how the oversubscription issue should be solved in Manila. * Storage pools that support thin provisioning are open to an "oversubscription". * We have a ratio for allowing oversubscriptions and it also influences the way the manila scheduler filters acts. We currently have issues with that calculation. * If the backends do not report their allocated_capacity_gb, it will be inaccurate. * We can have the share manager to have a more precise calculation. * Action Items: ** haixin will write a spec with more details on how this issue is going to be addressed. *== NetApp ONTAP - migration from ZAPI to REST API ==** nahimsouza and fabioaurelio talked about the NetApp ONTAP drivers that are currently using ZAPI for communication with NetApp hardware. * NetApp is now planning to deprecate ZAPI in favor of REST. This means that if they find issues within the ZAPI calls, NetApp won't fix them anymore. * The side effect of this is that NetApp wants to migrate their driver calls from ZAPI to rest, but it will impact pretty much all operations the driver performs. * These are going to be huge changes and they intend to backport it to the oldest maintained release. * They have lots of customers using the latest versions of ONTAP but those customers do not often upgrade their OpenStack deployments. * They are looking for approaches on how to backport these changes even further. *== Add support for automatic snapshot creation and removal ==** Kiran brought up the solution proposed with a spec [2], which intends to add an automatic snapshot creation policy and automatic snapshot deletion policy for a share, considering an interval defined by an administrator. * We've asked for possible alternatives such as automating the snapshots creation via manilaclient/REST API, and also raised a few questions that would help us to enforce the need of enhancing the API. * Action Items: ** Kiran will come back with updates on the discussion points. *== Manila UI updates ==** vkmc discussed the updates for Manila UI alongside the NDSU students. * They talked about the plans we have for the UI in this cycle, as well as bringing up the feature-parity issue we currently have. * We started by filing blueprints and identifying the scope of necessary changes to get feature parity. * A taiga board [3] was created to track the progress. * We also have a few blueprints [4] for that. *== Consistent and Secure RBAC changes ==** gouthamr, gmann and vhari brought up the plans for the Z cycle, which would be continuing the plans highlighted on [5] So for Z, the idea is to: * Harden Phase 1 by re-evaluating the use of "admin" at system scope, disallowing system scope users from creating/manipulating project resources * Continue working on tempest protection tests. Liron has a patch pending reviews that starts this work [6] * Test existing tempest API/scenario tests with the new RBAC defaults and adjust any credential use or API expectations by the end of the cycle * Start working on the phase 2 per the community goal in [5] Beyond Z: * A release - Phase 3: System Reader and System Member in the default RBAC * B release: Remove deprecated policies * == OpenStack Client updates for Manila ==** maaritamm presented the progress we had so far for the OSC integration. * We are quite close to feature parity. The idea is to reach feature parity in the Z cycle and add a deprecation warning to the native client shell in python-manilaclient. * We are lacking functional tests and we came up with a plan of organizing a hackathon to be hosted close to the z-3 milestone. * This hackathon will be focused on addressing the functional tests for the client and wrapping it up. * As enforced in the past cycle, maintainers implementing new functionalities to python-manilaclient must _only_ implement them for OSC. * New features in the python-manilaclient shell will actively be discouraged. * A more detailed version is available in [7]. *== Support for highly available NFS Ganesha in the CephFS driver ==** vkmc, fmount and gouthamr presented the the Ceph orchestrator tooling that now natively supports deploying nfs-ganesha gateway servers as "ceph-nfs" cluster daemons in active/active configurations. * The Ceph community has also added support for nfs APIs to create and manipulate exports on such ceph-nfs daemons. * We discussed the changes needed to support these in Manila and how users can migrate their workloads. To provide adequate control to deployers and end users, we agreed to introduce a new protocol helper layer that will live alongside the current DBUS API helper. * When the deployment supports new NFS clusters, deployers would be able to configure "alternate" server IPs in manila which can aid a slow transition for end users to migrate to newer "preferred" servers. * We're planning to automate this transition in Triple-O while also documenting this for developers of other deployment tools. *== Devstack-plugin-ceph changes ==* * vkmc and fmount presented the changes they are implementing in order to install/deploy the ceph cluster using cephadm. There is an open change for review [8]. We are also testing the Manila CephFS job in [9]. * Native CephFS scenario tests concerning ceph-fuse are failing sporadically with timeouts while mounting. * There are few issues with testing and there is more information about them in [9]. As next steps we have: * Testing with CentOS as the devstack host and Manila's client, so we have different approaches of testing and can ensure that ubuntu testing isn't compromising the VMs and causing the possible lack of resources we are experiencing. * Splitting CI changes into different test sets focusing on different services * Turning on cephadm based deployment in the multi-node job *== Topic #Bug updates ==** vhari has shown some bug analytics and the progress we have been making over the past cycles. * We have a bunch of bugs that are old and no one has been touching them in a while (at least 2 years). * Maintainers should check launchpad and evaluate those bugs we created and/or are assigned to us and see if they are still relevant. If they are, we should keep active on them, otherwise we can just let it fall into the auto-expiry policy. * Bugsquashes have been efficient for us, we should keep doing them. ** fabioaurelio suggested a bugsquash theme that would double up as a review jam. We'd be focusing on looking at the lingering changes that are closing bugs and getting closure for them. * When we don't have the time to do the bug triaging during the Manila meeting, we will do the triaging in #openstack-manila after. * We will be hosting our bugsquashes in Z-1 and the other one between Z-2 and 3. * Action items: ** carloss will update the change with manila specific milestones to reflect our scheduled events *== Metadata API status update ==** This is an effort that started some cycles ago. We intend to allow metadata on more user facing resources in Manila [10], and do that in a generic way. * Over the Yoga cycle that was accomplished for shares, and there is a change to also permit that for share snapshots. What's next: * Getting the share snapshots changes merged over the Z cycle (M-1) * Getting the new metadata mechanism also implemented for * Share Export Locations - Target: M3 (at least API + CLI) * Share Access Rules - Target: M3 (at least API + CLI) * Share Groups - Target: M3 (at least API + CLI) *== NetApp CI Zuul v3 Migration - Challenges and lessons learned ==** Building and maintaining a stable CI system has been a huge pain point to Manila's "third party" vendor storage developers for the past few releases. * NetApp contributors have talked about their Zuul v3 setup using Software Factory. They brought up some information on their Zuul v3 CI setup and talked about some difficulties they faced during the setup. * The recording is on Manila's YouTube channel [11]. There were questions asked and raised and the discussion documented in [9]. * Action items: * Through the release cycle, we hope to offer more venues for more knowledge sharing regarding third party CI maintenance. *== FIPS compliance ==** carloss ashrod98 and ade_lee talked the attendance through the challenges and testing for FIPS * We've been through the next steps and what has been done so far in Manila ** Few changes were proposed and merged ** Our CI job is working fine with CentOS 8 but we decided we should already have it on CentOS 9 * We needed to monkey patch paramiko for some drivers ** gouthamr is concerned that if this patching paramiko change is merged, this could break older branches in the future ** A discussion in openstack-discuss will be started to ensure if this is the best approach for this issue. * At the moment, we should stick with testing using CentOS but testing with Ubuntu is under way. * Compliance steps will start on Z release * ade_lee started an audit in OpenStack services to identify non FIPS compliant libraries * Goal should be completed on AA cycle * Action Items: ** Start a discussion on patching paramiko or switching to other lib ** Submit the jobs for python-manilaclient, manila-ui and manila-tempest-plugin *== Tech Debt ==*These are a few items we would like to get moving for Manila in the next cycles. They usually involve a community goal, a request for enhancement or recommendations from the community: * Migrating from privsep to rootwrap: In progress, few changes were merged over Y cycle and we intend to have even more progress over Z. * Dropping python-keystoneclient from python-manilaclient: this is also in progress and we got a few related changes merged. We will bring this up again in the upcoming manila meetings. * Cinder/Nova online extensions support with the generic driver: this hasn't started yet and we are looking for an owner. This is more of a request for enhancement that would benefit those using the generic driver. * 26 volumes limit in the generic driver: this is something that was called out in the generic driver documentation. We agreed to try an approach where we would update the manila image and check the output for it. * Publish the container driver image on tarballs.openstack.org (or quay.io): we had few changes to the container driver in the past cycles. One functionality was implemented on it (add/update security services in share networks that are used), and for that change to be tested, the container must have OpenLDAP installed. We have a way to publish new artifacts and we could benefit from reusing that. Action items: ** carloss will work on having the new image proposed ** Bring the keystoneclient change in the upcoming manila meetings. ** Update the manila image setting hw_scsi_model=virtio-scsi and investigate if the 26 volumes limit will be solved ** Work on finding people interested to contribute in the Cinder/Nova online extensions support with the generic driver *== Manila CSI updates ==** gman0, gouthamr and vkmc talked us through some of the updates in the Manila CSI since the last PTG [12]. * We don't currently test using RWO volumes with manila-csi in cloud-provider-openstack, so we could add an "external-attacher" sidecar to ensure RWO-ness * Doing backups with manila-csi and velero/restic * Action items: ** open an issue against the CPO repo and work on testing with RWO ** open a redmine tracker to call the limitation of giving huge names to snapshots in the docs *== Community Hour ==** gouthamr brought up some details about the release cadency adjustment [13] * Also, mentioned a few implications of this and how deprecations, testing and upgrades will work * Few details in the deprecation windows and how we should be working and targeting changes in the next few cycles. * A job was recently merged in Manila to test the upgrade from tick to tick releases * Action items: ** Update the tick release job to the Xena branch [1] https://etherpad.opendev.org/p/manila-yoga-retrospective [2] https://review.opendev.org/c/openstack/manila-specs/+/823165 [3] https://review.opendev.org/c/openstack/manila-specs/+/823165 [4] https://blueprints.launchpad.net/manila-ui/+spec/api-version-features [5] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [6] https://review.opendev.org/c/openstack/manila-tempest-plugin/+/805938 [7] https://etherpad.opendev.org/p/zorilla-ptg-manila-osc [8] https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/826484 [9] https://etherpad.opendev.org/p/zorilla-ptg-manila [10] https://specs.openstack.org/openstack/manila-specs/specs/yoga/metadata-for-… [11] https://www.youtube.com/watch?v=Pn1ZEnlHE7A [12] https://etherpad.opendev.org/p/zorilla-ptg-manila#L413 [13] https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad… [14] https://www.youtube.com/watch?v=AIqrLdprkaE&list=PLnpzT0InFrqCjifjP1OzFgnfi…

1 0

[blazar][requirements] setuptools and python_version in upper constraints
by Pierre Riteau 14 Apr '22

14 Apr '22

Hello, In the blazar project, we have been seeing a job timeout failure in openstack-tox-py39 affecting master and stable/yoga. tox starts the "lockutils-wrapper python setup.py testr --slowest --testr-args=" process which doesn't show progress until job timeout. It started happening sometime between 2022-03-10 16:01:39 (last success on master) and 2022-03-24 16:35:15 (first timeout occurrence) [1], with no change in blazar itself and few changes in requirements. I resumed debugging today and managed to reproduce it using Ubuntu 20.04 (it doesn't happen on macOS). Here is the traceback after interrupting it if anyone wants to take a look [2]. The python process is using 100% of the CPU until interrupted. I tracked down the regression to the upper constraint on setuptools. For example, stable/yoga has: setuptools===59.6.0;python_version=='3.6' setuptools===60.9.3;python_version=='3.8' It appears this is ignored in the py39 job so the job runs with the latest setuptools. Indeed, there were some releases between March 10 and March 24. I still have to figure out what changed in setuptools to cause this behaviour. Question for requirements maintainers: is this expected behaviour, or should upper constraints also include lines for python_version=='3.9' on yoga? Thanks, Pierre Riteau (priteau) [1] https://zuul.openstack.org/builds?job_name=openstack-tox-py39&project=opens… [2] https://paste.opendev.org/show/bZO7ELmTvfMUGJPdlQ4k/

5 5

[cinder][PTG] Summary of Zed PTG
by Rajat Dhasmana 14 Apr '22

14 Apr '22

Hi All, Here is a summary of Cinder Zed PTG[1] conducted from 05th April - 8th April, 2022 from 1300 to 1700 UTC each day. Please look at the topic summary and the action items if you were the author for any topic. [1] https://wiki.openstack.org/wiki/CinderZedPTGSummary Thanks and regards Rajat Dhasmana

1 0

R: [devstack] Not able to install devstack on ubuntu 20.04
by Molka Gharbaoui 14 Apr '22

14 Apr '22

Thank you Jeremy for your prompt reply! Changing the directories ownership definetly does not work for me. Other many errors are generated. I will follow the threads to check if hopefully a better solution is suggested. ________________________________ Da: Jeremy Stanley Inviato: Mercoledì, 13 Aprile, 2022 18:53 A: openstack-discuss(a)lists.openstack.org Oggetto: Re: [devstack] Not able to install devstack on ubuntu 20.04

1 0

[devstack] Not able to install devstack on ubuntu 20.04
by Molka Gharbaoui 14 Apr '22

14 Apr '22

Hi all, I am trying to install devstack by downloading the cose through the following link: git clone https://opendev.org/openstack/devstack and then executing ./stack command which I used to use several times without any error. However, today I am getting the following error (I only changed the VM): Obtaining file:///opt/stack/keystone Preparing metadata (setup.py) ... error error: subprocess-exited-with-error × python setup.py egg_info did not run successfully. │ exit code: 1 ╰─> [16 lines of output] Error parsing Traceback (most recent call last): File "/usr/local/lib/python3.8/dist-packages/pbr/core.py", line 111, in pbr attrs = util.cfg_to_args(path, dist.script_args) File "/usr/local/lib/python3.8/dist-packages/pbr/util.py", line 272, in cfg_to_args pbr.hooks.setup_hook(config) File "/usr/local/lib/python3.8/dist-packages/pbr/hooks/__init__.py", line 25, in setup_hook metadata_config.run() File "/usr/local/lib/python3.8/dist-packages/pbr/hooks/base.py", line 27, in run self.hook() File "/usr/local/lib/python3.8/dist-packages/pbr/hooks/metadata.py", line 25, in hook self.config['version'] = packaging.get_version( File "/usr/local/lib/python3.8/dist-packages/pbr/packaging.py", line 872, in get_version raise Exception("Versioning for this project requires either an sdist" Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name keystone was given, but was not able to be found. error in setup command: Error parsing /opt/stack/keystone/setup.cfg: Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name keystone was given, but was not able to be found. [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed × Encountered error while generating package metadata. ╰─> See above for output. note: This is an issue with the package mentioned above, not pip. hint: See above for details. +inc/python:pip_install:1 exit_trap +./stack.sh:exit_trap:523 local r=1 ++./stack.sh:exit_trap:524 jobs -p +./stack.sh:exit_trap:524 jobs= +./stack.sh:exit_trap:527 [[ -n '' ]] +./stack.sh:exit_trap:533 '[' -f '' ']' +./stack.sh:exit_trap:538 kill_spinner +./stack.sh:kill_spinner:433 '[' '!' -z '' ']' +./stack.sh:exit_trap:540 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:541 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:543 type -p generate-subunit +./stack.sh:exit_trap:544 generate-subunit 1649867885 63 fail +./stack.sh:exit_trap:546 [[ -z /opt/stack/logs ]] +./stack.sh:exit_trap:549 /usr/bin/python3.8 /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs World dumping... see /opt/stack/logs/worlddump-2022-04-13-163909.txt for details +./stack.sh:exit_trap:558 exit 1 Changing the owner of the directories using the following commands allows to go further in the installation process: sudo chown -R root:root /opt/stack/horizon/ sudo chown -R root:root /opt/stack/nova/ sudo chown -R root:root /opt/stack/cinder/ etc. However, then I am getting other errors related to permissions issues so I guess changing the directories ownership is not the solution. Could you please help me in resolving this. Thank you in advance!

2 1

[neutron][ovn] Need VM accessible on Internet, and able to access DC resources
by Chris DiLorenzo 14 Apr '22

14 Apr '22

To Internet To Data Center Resources (10.x) - -/ - -/ / -/ / -/ / -/ -/ -/ / -/ / Public Provider Network / Private Provider Network / +------------------------+ +-------------------------+ | | | | | | | | | Router #1 |--------------| Router #2 | | SNAT Enabled | .2| SNAT Enabled | | | | | | | | | +------------------------+ +-------------------------+ | 192.168.1.1 | | | | | | | | | 192.168.1.10 (FIP: Public IP) +---------|-------------+ | | | | | | | VM | | | | | +-----------------------+ I am running Openstack Xena with OVN and distributed FIP enabled. We are trying to come up with a way to make a VM accessible from the Internet and still have it able to access internal Data Center services. Our thought is to setup a router between the tenant network and an internet accessible provider network. We'll assign a FIP to the VM. Then, we create an additional router that connects to the same tenant network but routes to a provider network that has access to everything inside the DC. We would then add a static route on Router #1 like 10.0.0.0/8 nexthop 192.168.1.2. I've tried setting this up in our lab, but it's not working. I can't ping to anything inside the DC. Should this work? Any best practice here we should look at? Thanks Chris

1 0

[cinder] Bug deputy report for week of 04-13-2022
by Sofia Enriquez 13 Apr '22

13 Apr '22

This is a bug report from 03-30-2022 to 04-13-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High - https://bugs.launchpad.net/os-brick/+bug/1967790 " Encryptor connect_volume not changing the symlink." Fix proposed to marter. Medium - https://bugs.launchpad.net/cinder/+bug/1968746 "cinder-manage db sync fails due to row size too large." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1968645 "Concurrent migration of vms with the same multiattach volume fails." Unassigned. Low - https://bugs.launchpad.net/cinder/+bug/1968170 "reimage_volume failure message action does not exist." Unassigned. Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

Error while creating attached to an external interface
by A Monster 13 Apr '22

13 Apr '22

I'm trying to launch an instance attached to an external network, but I get an all host exhausted error message, and the neutron log file show the following error : *ERROR neutron.plugins.ml2.managers [req-6979d5fd-8e6a-4802-a758-e4882b7ac5b6 397fa0267ae340e1b24a3a96ae302f32 05b9f31fca434f7a96b63a1d17e8b14c - default default] Failed to bind port d57ac8f5-7904-495f-a4b9-9b23df681634 on host compute1.localdomain for vnic_type normal using segments [{'id': '475c70c2-6a35-4721-a726-cbf8c0b7e778', 'network_type': 'flat', 'physical_network': 'physnet2', 'segmentation_id': None, 'network_id': 'a1c2cc8f-6a04-48ce-9d87-a351da1d3f3e'}]* But when I try to launch an instance using another external network, it works just fine.

1 0

[neutron] Zed PTG Summary
by Lajos Katona 13 Apr '22

13 Apr '22

Hi, I will try to summarize the Neutron PTG sessions during the last week. The etherpad which we used: https://etherpad.opendev.org/p/neutron-zed-ptg # Day 1 (Monday April 4.) ## Yoga retrospective (I just list here the topics, not every discussion under them): * Good things ** New active people around the team ** Revived project: neutron-fwaas ** video CI meetings every second week are very good IMO ** OVN backend is getting more and more attention and there are less gaps between OVN and OVS backends * Bad / Not so good: ** less and less active people ** to much depends on Red Hat - ~66% of reviews, ~62% of commits (in Neutron official projects) ** lack of maintainers for some stadium projects (neutron-vpnaas) and some backends/drivers (linuxbridge) * As action we previously decided to have a forum session during the Berlin Summit to discuss the lack of activity/maintainers for some backends and stadium projects hopefully with some operators also. ## Short update on bgp related blueprints https://etherpad.opendev.org/p/neutron-zed-ptg#L111 The development of these blueprints are stopped, we will revert the already merged code. # Day 2 (Tuesday April 5.) ## Have nova / os-vif delete the trunk bridges to avoid race conditions The creation of trunk bridges now done by os-vif, and the deletion is done by Neutron, to avoid the race condition we agreed to have both operations done by os-vif. ## skip-level upgrade (tick-tick) We discussed together how this affects Neutron, what is working currently and what is in front of us. We have periodic jobs for ovs and ovn backend. Actions: * Make ovn grenade upgrade jobs green ## When we say something is not supported? * Recently from the Neutron stadium neutron-vpnaas project was that lost all maintainers. Neutron core team keeps an eye on the gate of networking projects, and keep them green, but if there is nobody with specific knowledge for the given area we can't solve the bugs. * We have similar problems with "in-tree" drivers also, a good example is the linuxbridge driver. Agreement was to keep the current approach for stadium project, so send out mail to openstack-discuss, asking for help, and if nobody appears, make the project retired and delete the code but keep git history for it. For in-tree code (drivers, extensions....): * We keep existing jobs for linuxbridge driver for example, but when the tests start to fail we skip them and finally we stop the job also. To make it clear for operators we add warning logs highlighting that the given feature/driver is experimental, and introduce cfg option to enable such features explicitly. We plan to discuss these questions during the Berlin Summit with operators. ## Prefix delegation for Openstack Neutron aka: dibbler tool for dhcpv6 is concluded The original bug: https://bugs.launchpad.net/neutron/+bug/1916428 * The tool behind PD, Dibbler is no more maintained and the suggested tool ISC Kea has no DHCP client actually. * this feature is not tested in upstream CI Due to these we decided to mark prefix delegation as experimental feature. # Day 3 (Wednesday April 6.) ## neutron-dynamic-routing + OVN Redhat works on a BGP solution for OVN, that is ovn-bgp-agent, and currently it doesn't need the existing API in neutron-dynamic-routing. The current approach to make neutron-dynamic-routing work with OVN will be checked. ## Option for OVN to disable DHCP/DNS and use dhcp-agent instead Technically it is possible, a new RFE will be proposed and the drivers team will discuss the usecase behind it. ## CI status / zuul job config errors In the list of zuul cfg errors ( https://zuul.opendev.org/t/openstack/config-errors ) old Neutron stadium branches are listed. * Decision was to EOL these old branches where fixing is not possible. Another topic was from Slawek if we want to have neutron-tempest-plugin-api-ovs job, and the agreement was to merge OVS scenario and API jobs. ## inconsistencies in OVS firewall on an agent restart We will go for a cfg option to select between OVS flow installation in batches and per port, and operators can select which is best for their environment. ## Pain Points TC started a discussion to cover the collected operator pain points, last week we checked again the list for Neutron ( https://etherpad.opendev.org/p/pain-point-elimination#L268) * neutron (via python calls) and OVN (via C calls) can have different ideas about what the hostname is, particulary if a deployer (rightly or wrongly) sets their hostname to be an FQDN ** it was fixed: https://review.opendev.org/q/Iea2533f4c52935b4ecda9ec22fb619c131febfa1 * Useful error msg when network deletion fails due to existing resources on it ** done: https://review.opendev.org/c/openstack/neutron/+/821935 * Open vSwitch Agent excess logging at INFO level ** we check if we can change some to debug, Slawek create a DNM job with only info logs to discuss during one of the coming meetings. * OVN: Spoofing of DNS reponses seems very wrong behavior ** We agreed that for this we need an RFE (see above for disabling OVN DNS/DHCP) ## Edge topics Together with the Designate team we agreed that this is more a documentation problem based on our current understanding. Based on Redhat downstream bugs for edge deployments we try to cover these in this cycle. # Day 4 (Thursday April 7.) We have no sassions. # Day 5 (Friday April 8.) ## Nova - Neutron xproject ### How to require ml2 plugins to implement multiple port bindings The problem is that there are old drivers (hyperv perhaps and others) that do not implement it and this cause a lot of extra code path in Nova. Sean suggested a Forum topic for Berlin to discuss it with operators also. ### Is heal_instance_info_cache_interval still needed? Let's create a job which sets heal_instance_info_cache_interval to 0, and decide the next steps based on the results. The happy moment with the team screenshot: https://photos.app.goo.gl/P6YuYgxzqEiv2gHt8 I hope next time we can meet in person :-) Thanks to everybody for the great discussions. Lajos Katona (lajoskatona)

1 0

[horizon] Cancelling Today's Weekly meeting
by vishal manchanda 13 Apr '22

13 Apr '22

Hello Team, I won't be able to chair today's horizon weekly meeting due to some travel. So if someone from team can host it on my behalf or we can skip this week meeting. Note: I will join office from thrusday so if anything urgent please reach out to horizon core team. Thanks & regards, Vishal Manchanda

1 0

[Trove][Xena] Errors when creating postgresql insances
by wodel youchi 13 Apr '22

13 Apr '22

Hi, I defined a postgresql data store with two versions 10 and 12. When creating db instances I am getting different errors : *For Postgresql 10, I am getting : * Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/taskmanager/models.py", line 436, in wait_for_instance time_out=timeout) File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/common/utils.py", line 223, in poll_until return wait_for_task(task) File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/common/utils.py", line 207, in wait_for_task return polling_task.wait() File "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/event.py", line 125, in wait result = hub.switch() File "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 313, in switch return self.greenlet.switch() File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_service/loopingcall.py", line 150, in _run_loop result = func(*self.args, **self.kw) File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/common/utils.py", line 194, in poll_and_check obj = retriever() File "/var/lib/kolla/venv/lib/python3.6/site-packages/trove/taskmanager/models.py", line 791, in _service_is_active raise TroveError(_("Service not active, status: %s") % status) trove.common.exception.TroveError: Service not active, status: failed to spawn ==> trove-conductor.log <== 2022-04-13 00:26:52.334 124 ERROR trove.conductor.manager [-] Guest exception on request req-b5bd49e8-e147-41b2-8292-2900bb4022a1: ['Traceback (most recent call last):\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/manager.py", line 218, in prepare\n ds_version=ds_version)\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/manager.py", line 234, in _prepare\n cluster_config, snapshot, ds_version=ds_version)\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/osprofiler/profiler.py", line 160, in wrapper\n result = f(*args, **kwargs)\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/manager.py", line 161, in do_prepare\n self.app.start_db(ds_version=ds_version, command=command)\n', ' File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 229, in start_db\n raise exception.TroveError("Failed to start database service")\n', *'trove.common.exception.TroveError: Failed to start database service\n']* *And for Postgresql 12, I am getting :* Server type: guest Traceback (most recent call last): File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/manager.py", line 845, in create_user self.adm.create_users(users) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 516, in create_users self.create_user(models.PostgreSQLUser.deserialize(user), None) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 549, in create_user [models.PostgreSQLSchema.deserialize(db) for db in user.databases]) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 558, in _grant_access [db.name for db in databases], File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 432, in grant_access database=database, File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 723, in psql return self.connection.execute(statement) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 763, in execute autocommit=True) File "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", line 776, in _execute_stmt cursor.execute(cmd, data_values) psycopg2.errors.InvalidCatalogName: database "dbweb01" does not exist And this error from > ==> trove-conductor.log <== > 2022-04-12 23:58:11.689 46 ERROR trove.conductor.manager [-] Guest > exception on request req-7c0e005a-2b02-4acf-bdc5-e9d7a964cd7e: > ['Traceback (most recent call last):\n', ' File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/manager.py", > line 808, in create_database\n return > self.adm.create_databases(databases)\n', ' File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 464, in create_databases\n > self.create_database(models.PostgreSQLSchema.deserialize(database))\n', ' > File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 477, in create_database\n collation=database.collate,\n', ' File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 723, in psql\n return self.connection.execute(statement)\n', ' > File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 763, in execute\n autocommit=True)\n', ' File > "/opt/guest-agent-venv/lib/python3.6/site-packages/trove/guestagent/datastore/postgres/service.py", > line 776, in _execute_stmt\n cursor.execute(cmd, data_values)\n', > 'psycopg2.errors.ActiveSqlTransaction: *CREATE DATABASE cannot run inside > a transaction block\n\n']* > Regards.

1 0

[openstack-helm] Dropping train support
by Gage Hugo 13 Apr '22

13 Apr '22

Hi all, One of the topics from the latest PTG discussions[0] was looking to drop support of the Train release from our charts due to a lack of interest in maintaining them and several issues with broken images due to dependencies. As a result of those discussions, we'd like to make dropping Train support a goal for this cycle. If anyone is still using Train and has a pressing issue where they cannot upgrade, please reach out and we can discuss a path forward. [0] https://etherpad.opendev.org/p/openstack-helm-zed-ptg Thanks

1 0

[openstack-helm] openstack-helm-addons and docs repository retirement
by Gage Hugo 13 Apr '22

13 Apr '22

Hey everyone, We recently had a PTG session and one of the topics that was discussed was the retirement of the openstack-helm-addons and openstack-helm-docs repositories. This topic has been mentioned now for several PTGs and from our discussion at the latest one, it was determined that due to the lack of updates to the repos as well as the charts themselves receiving no real maintenance, we would look to retire both these repositories this cycle. If anyone is still using the 3 charts that still exist in the repos and would like to maintain them, please let us know. Thanks!

1 0