July 2021 - openstack-discuss - lists.openstack.org

[rpm-packaging] logging override in openstack packages
by Piotr Mossakowski 20 Jul '21

20 Jul '21

Hello, There is a logging override in almost all openstack packages, for example in nova: https://opendev.org/openstack/rpm-packaging/src/branch/stable/victoria/open… <https://opendev.org/openstack/rpm-packaging/src/branch/stable/victoria/open…> It lands in /etc/nova/nova.conf.d/010-nova.conf as stated in the spec: https://opendev.org/openstack/rpm-packaging/src/branch/stable/victoria/open… <https://opendev.org/openstack/rpm-packaging/src/branch/stable/victoria/open…> Let's assume following scenario: in kolla-ansible based deployment I want to disable logging globally using /etc/kolla/config/global.conf: [DEFAULT] log_dir = log_file = For kolla images built from RPMs, the file '/etc/nova/nova.conf.d/010-nova.conf' will override what I want to achieve by global.conf. We have a situation when kolla images log inside the container into '/var/log/nova' where there is no log rotation. There is no easy way to change that in kolla-ansible based deployments. Is there any specific reason why default logging has been hardcoded like that? Can we agree to change that situation to be able to override logging as expected? -- Pozdrawiam serdecznie / Best regards, *Piotr Mossakowski* Lead System Engineer, Product Development Services, Cloud Infra & Applications Email piotr.mossakowski(a)tietoevry.com <mailto:piotr.mossakowski@tietoevry.com>, +48795515407 <tel:%2B48795515407> Aleja Piastów 30, 71-064 Szczecin, Poland, www.tietoevry.com <http://www.tieto.com/>

3 3

[kolla][wallaby][manila] urgent: new BUG ???
by Ignazio Cassano 20 Jul '21

20 Jul '21

Hello, probably we discovered a new bug in kolla wallaby manila generic driver. Starting by victoria release, the manila share conf requires the section [glance] otherwise it cannot create the service instance. We modified the manila conf inserting the section [glance] like the following: [glance] auth_uri = http://10.102.119.194:5000 auth_url = http://10.102.119.194:35357 auth_type = password project_domain_id = default user_domain_id = default region_name = RegionOne endpoint_type = internalURL project_name = service username = glance password = password cafile = memcache_security_strategy = ENCRYPT memcache_secret_key = password memcached_servers = 10.102.119.195:11211,10.102.119.196:11211, 10.102.119.197:11211 And now it can create the service instance. Could anyone verify it, please ? Ignazio

3 3

PTG October 2021 Team Signup
by Ashlee Ferguson 19 Jul '21

19 Jul '21

Hi everyone, Last week, we announced the next PTG will held virtually from Monday, October 18 to Friday, October 22, 2021. We will have the same schedule set up available as last time with three windows of time spread across the day to cover all timezones with breaks in between. To signup your team, you must complete BOTH the survey[1] AND reserve time in the ethercalc[2] by end of day July 21. We ask that the PTL/SIG Chair/Team lead sign up for time to have their discussions with 3 rules/guidelines: 1. Cross project discussions (like SIGs or support project teams) should be scheduled towards the start of the week so that any discussions that might shape those of other teams happen first. 2. No team should sign up for more than 4 hours per UTC day to help keep participants actively engaged. 3. No team should sign up for more than 16 hours across all time slots to avoid burning out our contributors and to enable participation in multiple teams discussions. Again, you need to fill out BOTH the ethercalc AND the survey to complete your team's sign up. If you have any issues with signing up your team, due to conflict or otherwise, please let me know! While we are trying to empower you to make your own decisions as to when you meet and for how long (after all, you know your needs and teams timezones better than we do), we are here to help! Once your team is signed up, please register[3]! And remind your team to register! Registration is free, but it's important that you sign up to let us know you'll be attending because that's how you'll receive event details, passwords, and other relevant information about the PTG. Continue to visit openstack.org/ptg for updates. Ashlee [1] Team Survey: https://openinfrafoundation.formstack.com/forms/oct2021_vptg_survey [2] Ethercalc Signup: https://ethercalc.openstack.org/8tum5yl1bx43 [3] PTG Registration: https://openinfra-ptg.eventbrite.com

1 1

[neutron] bug deputy report for week of 2021-07-12
by Rodolfo Alonso Hernandez 19 Jul '21

19 Jul '21

Hello Neutrinos: I would like to highlight https://bugs.launchpad.net/neutron/+bug/1935959. This bug has been confirmed but not assigned yet. This is the classified list of bugs: Critical: - https://bugs.launchpad.net/neutron/+bug/1935983/. “[OVN] Regression when using ML2/OVN with Neutron DHCP agent”. Assigned. - (master): https://review.opendev.org/c/openstack/neutron/+/800679 - (stable branches): https://review.opendev.org/#/q/I1a14f217d0b6bca84cd074ef5aa4e07797fdf7e0 High: - Nothing this week... Medium: - https://bugs.launchpad.net/neutron/+bug/1935959. “[OVN]Unable to access port forwarding”. Not assigned. - https://bugs.launchpad.net/neutron/+bug/1935888. “When multiple neutron servers are restarted, the update from neutron MariaDB to ovn North database is triggered, and the neutron server generates contention lock, loses lock and reports an error”. Assigned: - https://review.opendev.org/c/openstack/neutron/+/800751 Low: - https://bugs.launchpad.net/neutron/+bug/1935842. “[OVN] Set inactivity_probe for NB/SB databases”. Assigned: - https://review.opendev.org/c/openstack/neutron/+/800521 - https://bugs.launchpad.net/neutron/+bug/1936667. “Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3”. Assigned: - https://review.opendev.org/c/openstack/neutron/+/801068 - https://bugs.launchpad.net/neutron/+bug/1936675. Do not coerce a subquery into a select, create a proper select condition. Assigned: - https://review.opendev.org/c/openstack/neutron/+/801076 Whishlist: - https://bugs.launchpad.net/neutron/+bug/1935847. “[RFE] Basic Authentication Support for Standalone Neutron”. Assigned. This RFE should be discussed in the Neutron Drivers meeting. - https://review.opendev.org/c/openstack/neutron/+/800410 - https://bugs.launchpad.net/neutron/+bug/1936408: [RFE] Neutron quota change should check available existing resources. Assigned. Regards.

1 0

VM Migration To New Hardware with OpenStack
by KK CHN 19 Jul '21

19 Jul '21

QUERY Section A: We are in the process of migrating VMs from a Vendor to OpenStack . The Vendor has hosted the VMs using RedHat Virtualization and HyperV around 100 VMs. Each VM size varies from 50 GB to 150 GB size. What is the best way to migrate these VMs to New Hardware infra Installed with OpenStack Ussuri. What need to be done at the existing live VMs with the Vendor and in what file format we have to ask the vendor to give the snapshot of VMs to be migrated ? I am new to the migration of VMs from a live production setup ( the present Vendor deployed VMs with all aplications running on the VM with HyperV and RedeHat KVM. ) We are also using KVM hypervisor. Kindly advise and direct me with all good practices followed to perform this migration from existing vendor to our own setup with OpenStack and KVM. Pls shed some light on this. QUERY SECTION B Another question below ffor a trail the existing vendor has given a demo VM, which is a Windows VM with an ERP application hosted on it . But the vendor handed over three files of single VM , Three qcow2 files. They handed over three qcow2 files for this VM as follows. 1. First file is OS image as qcow2 2. /boot as another qcow2 image 3. /lv-datat as another qcow2 image How to combine these files and we can create a Running VM from these files and put it on bare metal installed with KVM only. Is this possible ? How ? What need to take care while doing this operation?. your hints and direcitons highly appreciated. Thanks in Advance, Kris

3 2

openstack-nova-consoleauth/scheduler failed to start up
by Pete Zhang 19 Jul '21

19 Jul '21

We are installing openstack in a new DC and seeing openstack-nova-consoleauth/scheduler failed to start up. Checking log and found this. Host 10.160.4.5 is not allowed to connect to this MariaDB server. Three controller nodes are installed with MariaDB/Galera Cluster, none of them with this ip. -- <https://smart.salesforce.com/sig/peiyong.zhang//us_mb/default/link.html>

3 6

[kolla][wallaby] config drive vm fails live migration
by Ignazio Cassano 19 Jul '21

19 Jul '21

Hello All, I installed kolla wallaby with ubuntu source images. I have cinder installed, so live migration works but does not work with instances configured with config drive. Any help,please? Ignazio

1 1

[wallaby][neutron][ovn][vpnaas] Openstack VPNaaS with OVN Networking
by Malik Obaid 19 Jul '21

19 Jul '21

Hi, I am using Openstack Wallaby release on Ubuntu 20.04. I just want to know when openstack VPNaaS will be available with OVN networking. I would really appreciate any input in this regard. Thank you. Regards, Malik Obaid

1 0

[baremetal-sig][ironic] Tue July 13, 2021, 2pm UTC: Introduction to Bifrost
by Arne Wiebalck 19 Jul '21

19 Jul '21

Dear all, The Bare Metal SIG will meet tomorrow Tue July 13, 2021, at 2pm UTC on zoom. The meeting will feature a "topic-of-the-day" presentation by Julia Kreger (TheJulia): "Getting started with Ironic: Bifrost" Bifrost allows to install Ironic in standalone mode (without other OpenStack components) and is also often chosen as a starting point to get familiar Ironic. As usual, all details on https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, hope to see you there! Cheers, Arne

2 1

Fwd: [Kolla] [ Kolla-Ansible] Existing Workloads getting Impacted on Upgrade
by Anirudh Gupta 17 Jul '21

17 Jul '21

Hi Team, We have deployed the Openstack Victoria release using Multinode Kolla Ansible deployment. There are 2 nodes - one for compute and other for Controller+Network Following the below link, we also upgraded the setup from Victoria to wallaby https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html During the Upgrade process, we figured out that the VM which was spawned before Upgrade went to shut off during the middle of Upgrade process and post completion of the upgrade process, we had to manually start the VM again. Ideally we were expecting that the existing Workloads would remain unimpacted in this process. Can someone please suggest if our observation is correct or any steps that needs to be taken in order to avoid this? Regards Anirudh Gupta

4 4