February 2021 - openstack-discuss

Openstack instances cannot access to Internet [linuxbridge]
by Jaime 11 Feb '21

11 Feb '21

I am having serious issues in the deployment of the Openstack scenario related to the Linux Bridge. This is the scenario: - Controller machine: - Management Interface `enp2s0`: 138.100.10.25. - Compute machine: - Management Interface `enp2s0`: 138.100.10.26. - Provider Interface `enp0s20f0u4`: 138.100.10.27. Openstack Train scenario has been successfully deployed in Centos 8, choosing networking option 2 (self-service network). To verify the functionality, an image has been uploaded, created an Openstack flavor and security group, and launched a couple of cirrOS instances for connection testing. We have created a provider network following [this tutorial](https://docs.openstack.org/newton/install-guide-rdo/launch-instan… and a selfservice network following [this one](https://docs.openstack.org/newton/install-guide-rdo/launch-instance-ne…. The network scenario is the next one: As can be seen in the network topology, an external network 138.100.10.0/21 (provider) and an internal network 192.168.1.1 (selfservice) have been created, connected through a router by the interfaces 138.100.10.198 and 192.168.1.1, both active. Our problem is that our Linux bridge is not working as expected: the Openstack cirrOS instances has no internet access. This is the controller `ip a` and `brctl show` command output: ``` [upm@modena ~]$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UP group default qlen 1000 link/ether 24:4b:fe:7c:78:b8 brd ff:ff:ff:ff:ff:ff 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:15:5b:02 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:15:5b:02 brd ff:ff:ff:ff:ff:ff 17: tapa467f377-b1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master brq84f65ccb-c9 state UP group default qlen 1000 link/ether d6:90:e8:fe:90:23 brd ff:ff:ff:ff:ff:ff link-netns qdhcp-84f65ccb-c945-437b-9013-9c71422bb10e 18: brq84f65ccb-c9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 24:4b:fe:7c:78:b8 brd ff:ff:ff:ff:ff:ff inet 138.100.10.25/21 brd 138.100.15.255 scope global brq84f65ccb-c9 valid_lft forever preferred_lft forever inet6 fe80::6c31:4cff:fe2d:7820/64 scope link valid_lft forever preferred_lft forever 19: tap7a390547-5b@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brqd811bcfa-94 state UP group default qlen 1000 link/ether 26:6d:a4:fc:73:51 brd ff:ff:ff:ff:ff:ff link-netns qdhcp-d811bcfa-945a-4633-9266-60ccafa28d86 20: vxlan-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether fa:cb:4e:e2:83:46 brd ff:ff:ff:ff:ff:ff 21: brqd811bcfa-94: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000 link/ether 12:a8:05:bf:98:98 brd ff:ff:ff:ff:ff:ff inet6 fe80::88c2:ecff:fe72:761f/64 scope link valid_lft forever preferred_lft forever 22: tap3eb4fbcf-41@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brqd811bcfa-94 state UP group default qlen 1000 link/ether 12:a8:05:bf:98:98 brd ff:ff:ff:ff:ff:ff link-netns qrouter-278c944f-7e75-4a93-affe-b9ff93f4c6a5 23: tapfd2dca1f-f7@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master brq84f65ccb-c9 state UP group default qlen 1000 link/ether 86:cc:64:22:4d:db brd ff:ff:ff:ff:ff:ff link-netns qrouter-278c944f-7e75-4a93-affe-b9ff93f4c6a5 [upm@modena ~]$ brctl show bridge name bridge id STP enabled interfaces brq84f65ccb-c9 8000.244bfe7c78b8 no enp2s0 tapa467f377-b1 tapfd2dca1f-f7 brqd811bcfa-94 8000.12a805bf9898 no tap3eb4fbcf-41 tap7a390547-5b vxlan-1 virbr0 8000.525400155b02 yes virbr0-nic ``` This is the compute `ip a` and `brctl show` command output: ```shell [upm@testarossa ~]$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 24:4b:fe:7c:79:a0 brd ff:ff:ff:ff:ff:ff inet 138.100.10.26/21 brd 138.100.15.255 scope global noprefixroute enp2s0 valid_lft forever preferred_lft forever inet6 fe80::c461:f832:d690:c0a7/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: enp0s20f0u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UP group default qlen 1000 link/ether 00:e0:4c:53:44:58 brd ff:ff:ff:ff:ff:ff inet6 fe80::ecff:62cc:d9e1:2e53/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:66:84:5a brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:66:84:5a brd ff:ff:ff:ff:ff:ff 6: brqd811bcfa-94: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000 link/ether 8e:94:21:5b:dc:f4 brd ff:ff:ff:ff:ff:ff inet 138.100.10.27/21 brd 138.100.15.255 scope global noprefixroute brqd811bcfa-94 valid_lft forever preferred_lft forever 7: brq84f65ccb-c9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:e0:4c:53:44:58 brd ff:ff:ff:ff:ff:ff inet 138.100.10.27/21 brd 138.100.15.255 scope global brq84f65ccb-c9 valid_lft forever preferred_lft forever 9: tap9d1c0de6-96: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:7d:14:63 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe7d:1463/64 scope link valid_lft forever preferred_lft forever 10: tapaf15e2f0-24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:91:6d:ef brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe91:6def/64 scope link valid_lft forever preferred_lft forever 11: vxlan-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether 8e:94:21:5b:dc:f4 brd ff:ff:ff:ff:ff:ff 13: tapef3e95d6-7c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:91:d1:1d brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe91:d11d/64 scope link valid_lft forever preferred_lft forever 14: tap1a5d77c0-d4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:4f:da:0f brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe4f:da0f/64 scope link valid_lft forever preferred_lft forever 15: tap792bf660-2f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:f1:df:5f brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fef1:df5f/64 scope link valid_lft forever preferred_lft forever 16: tapf42b8b2f-be: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:9e:46:bb brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe9e:46bb/64 scope link valid_lft forever preferred_lft forever [upm@testarossa ~]$ brctl show bridge name bridge id STP enabled interfaces brq84f65ccb-c9 8000.00e04c534458 no enp0s20f0u4 tap1a5d77c0-d4 tapaf15e2f0-24 tapf42b8b2f-be brqd811bcfa-94 8000.8e94215bdcf4 no tap792bf660-2f tap9d1c0de6-96 tapef3e95d6-7c vxlan-1 virbr0 8000.52540066845a yes virbr0-nic ``` (The output of `ovs-vsctl show` command is empty in both machines). **Are the Linux Bridges correctly created?** These are the Linux bridge configuration files: * Controller `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp2s0 # enp2s0 is the interface associated to 138.100.10.25 [vxlan] enable_vxlan = true local_ip = 138.100.10.25 # controller has only 1 IP l2_population = true ``` * Compute `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp0s20f0u4 # interface associated to 138.100.10.26 [vxlan] enable_vxlan = true local_ip = 138.100.10.27 l2_population = true ``` An **observation** to keep in mind is that compute management interface (`138.100.10.26`) is inaccessible from anywhere, which I think is not correct since this prevents us, for example, from accessing the instance console through the URL. I have made some conection tests and these are the results: * Cirros_a `ip a` command output: ``` $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000 link/ether fa:16:3e:91:d1:1d brd ff:ff:ff:ff:ff:ff inet 192.168.1.222/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe91:d11d/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether fa:16:3e:4f:da:0f brd ff:ff:ff:ff:ff:ff ``` * Cirros_b `ip a` command output: ``` $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000 link/ether fa:16:3e:f1:df:5f brd ff:ff:ff:ff:ff:ff inet 192.168.1.30/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fef1:df5f/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether fa:16:3e:9e:46:bb brd ff:ff:ff:ff:ff:ff ``` - There is **connection** between Cirros A and Cirros B (in both directions). - There is **connection** between Cirros A/B and self-service gateway (192.168.1.1) (in both directions). - There is **connection** between Cirros A/B and provider gateway (138.100.10.198) (in both directions). - There is **connection** between Cirros A/B and controller management interface (138.100.10.25) (in both directions). - There is **no connection** between Cirros A/B and compute management interface (138.100.10.26). This interface is not accessible. - There is **connection** between Cirros A/B and compute provider interface (138.100.10.27) (in both directions). I do not know if there is a problem on linux bridge configuration files, or maybe I need another network interface on controller machine.

1 0

Openstack instances cannot access to Internet [linuxbridge]
by Jaime 11 Feb '21

11 Feb '21

I am having serious issues in the deployment of the Openstack scenario related to the Linux Bridge. This is the scenario: - Controller machine: - Management Interface `enp2s0`: 138.100.10.25. - Compute machine: - Management Interface `enp2s0`: 138.100.10.26. - Provider Interface `enp0s20f0u4`: 138.100.10.27. Openstack Train scenario has been successfully deployed in Centos 8, choosing networking option 2 (self-service network). To verify the functionality, an image has been uploaded, created an Openstack flavor and security group, and launched a couple of cirrOS instances for connection testing. We have created a provider network following [this tutorial](https://docs.openstack.org/newton/install-guide-rdo/launch-instan… and a selfservice network following [this one](https://docs.openstack.org/newton/install-guide-rdo/launch-instance-ne…. The network scenario is the next one: As can be seen in the network topology, an external network 138.100.10.0/21 (provider) and an internal network 192.168.1.1 (selfservice) have been created, connected through a router by the interfaces 138.100.10.198 and 192.168.1.1, both active. Our problem is that our Linux bridge is not working as expected: the Openstack cirrOS instances has no internet access. This is the controller `ip a` and `brctl show` command output: This is the compute `ip a` and `brctl show` command output: (The output of `ovs-vsctl show` command is empty in both machines). **Are the Linux Bridges correctly created?** These are the Linux bridge configuration files: * Controller `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp2s0 # enp2s0 is the interface associated to 138.100.10.25 [vxlan] enable_vxlan = true local_ip = 138.100.10.25 # controller has only 1 IP l2_population = true ``` * Compute `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp0s20f0u4 # interface associated to 138.100.10.26 [vxlan] enable_vxlan = true local_ip = 138.100.10.27 l2_population = true ``` An **observation** to keep in mind is that compute management interface (`138.100.10.26`) is inaccessible from anywhere, which I think is not correct since this prevents us, for example, from accessing the instance console through the URL. I have made some conection tests and these are the results: * Cirros_a `ip a` command output: * Cirros_b `ip a` command output: - There is **connection** between Cirros A and Cirros B (in both directions). - There is **connection** between Cirros A/B and self-service gateway (192.168.1.1) (in both directions). - There is **connection** between Cirros A/B and provider gateway (138.100.10.198) (in both directions). - There is **connection** between Cirros A/B and controller management interface (138.100.10.25) (in both directions). - There is **no connection** between Cirros A/B and compute management interface (138.100.10.26). This interface is not accessible. - There is **connection** between Cirros A/B and compute provider interface (138.100.10.27) (in both directions). I do not know if there is a problem on linux bridge configuration files, or maybe I need another network interface on controller machine.

1 0

[stein][neutron][vlan provider network] How to configure br-ex on virtual interface
by roshan anvekar 11 Feb '21

11 Feb '21

Hello, Below is my scenario. I am trying to use a single physical bonded interface ( example: bond1) both for external TLS access traffic and for provider network too ( These are 2 different vlan networks with separate vlan ids) . Bond0 is used as api_interface for management traffic. Bond2 is used for storage traffic. For this I created 2 virtual interfaces on this bond1 and used it accordingly while deploying through kolla-ansible. Before deployment the gateways for both vlan networks were accessible. Post deployment I see that qdhcp-id router is created on one of the controllers. Post creation of this DHCP agent, the gateway is inaccessible. Also the vms created are not getting IPs through DHCP agent so failing to be accessible. I had configured br-ex on virtual interface of provider vlan network and not on physical interface directly. Please let me know if I am going wrong in my network configurations. Regards, Roshan

3 4

[ironic] [release] [kolla] RFC: stop doing Extended Maintenance for Bifrost
by Dmitry Tantsur 11 Feb '21

11 Feb '21

Hi all, Since Bifrost is an installation project that supports several distributions, maintaining its stable branches is a never ending nightmare. We have *nearly* fixed Ussuri (thank you Riccardo!) and just started looking into Train (thank you Iury and Mark), I'm sure we cannot keep EM branches in a decent shape. Personally I feel that Bifrost is more geared towards consumers staying close to master, but my gut feeling may not necessarily match the reality. Based on the above, I'm proposing: 1) EOL all old branches from Ocata to Stein on Bifrost. 2) No longer create EM branches, EOL immediately after a branch leaves the regular maintenance. Opinions? Dmitry P.S. Adding kolla because of a potential impact. -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

3 4

[cinder] wallaby R-9 mid-cycle summary available
by Brian Rosmaita 11 Feb '21

11 Feb '21

In case you missed the exciting cinder R-9 virtual mid-cycle session (held yesterday or earlier today depending on where you are) I've posted a summary: https://wiki.openstack.org/wiki/CinderWallabyMidCycleSummary It will eventually include a link to the recording (in case you want to see what you missed or if you want to re-live the excitement). cheers, brian

1 0

bootstrap errors in OSA installation in CentOS 8.3
by Amey Abhyankar 11 Feb '21

11 Feb '21

Hello, I am trying to configure deployment host by referring following guide =https://docs.openstack.org/project-deploy-guide/openstack-ansible/victoria/deploymenthost.html # dnf install https://repos.fedorapeople.org/repos/openstack/openstack-victoria/rdo-relea… # dnf install git chrony openssh-server python3-devel sudo # dnf group install "Development Tools" # git clone -b 22.0.0.0rc1 https://opendev.org/openstack/openstack-ansible /opt/openstack-ansible # scripts/bootstrap-ansible.sh [ after executing this command, I am getting errors. Attaching sample error] ------------------------------------------------- hs will be added later\\n --pathspec-from-file <file>\\n read pathspec from file\\n --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\\n'\"], [\"Role {'name': 'os_ironic', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_ironic', 'version': '67733c8f0cb13c467eb10f256a93d878c56d4743', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_ironic'} failed after 2 retries\\n\"], [\"Role {'name': 'os_cinder', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_cinder', 'version': '00a38c6584c09168faad135f10d265ad9c86efba', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_cinder'} failed after 2 retries\\n\"], [\"Role {'name': 'lxc_hosts', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-lxc_hosts', 'version': 'b3bff3289ac2e9510be81f562f6d35500ac47723', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/lxc_hosts'} failed after 2 retries\\n\"], [\"Role {'name': 'rsyslog_client', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-rsyslog_client', 'version': 'd616af7883bd6e7a208be3a4f56d129bc2aa92ca', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/rsyslog_client'} failed after 2 retries\\n\"], [\"Role {'name': 'openstack_openrc', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-openstack_openrc', 'version': '242772e99978fe9cd3c50b5b40d5637833f38beb', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/openstack_openrc'} failed after 2 retries\\n\"], [\"Role {'name': 'os_ceilometer', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_ceilometer', 'version': '6df1fb0fc5610c2f317b5085188b0a60346e7111', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_ceilometer'} failed after 2 retries\\n\"], [\"Failed to reset /etc/ansible/roles/os_keystone\\nCmd('git') failed due to: exit code(129)\\n cmdline: git reset --force --hard f1625b38a820dd51cffa66141053a836211695dc\\n stderr: 'error: unknown option `force'\\nusage: git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>]\\n or: git reset [-q] [<tree-ish>] [--] <pathspec>...\\n or: git reset [-q] [--pathspec-from-file [--pathspec-file-nul]] [<tree-ish>]\\n or: git reset --patch [<tree-ish>] [--] [<pathspec>...]\\n\\n -q, --quiet be quiet, only report errors\\n --mixed reset HEAD and index\\n --soft reset only HEAD\\n --hard reset HEAD, index and working tree\\n --merge reset HEAD, index and working tree\\n --keep reset HEAD but keep local changes\\n --recurse-submodules[=<reset>]\\n control recursive updating of submodules\\n -p, --patch select hunks interactively\\n -N, --intent-to-add record only the fact that removed paths will be added later\\n --pathspec-from-file <file>\\n read pathspec from file\\n --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\\n'\"], [\"Role {'name': 'openstack_hosts', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-openstack_hosts', 'version': '8ab8503a15ad5cfe504777647922be301ddac911', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/openstack_hosts'} failed after 2 retries\\n\"], [\"Role {'name': 'os_sahara', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_sahara', 'version': '0f9e76292461a5532f6d43927b71ab9fff692dd5', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_sahara'} failed after 2 retries\\n\"], [\"Role {'name': 'os_tempest', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_tempest', 'version': '49004fb05fa491275848a07020a36d4264ab6d49', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_tempest'} failed after 2 retries\\n\"], [\"Role {'name': 'ceph-ansible', 'scm': 'git', 'src': 'https://github.com/ceph/ceph-ansible', 'version': '7d088320df1c4a6ed458866c61616a21fddccfe8', 'trackbranch': 'stable-5.0', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/ceph-ansible'} failed after 2 retries\\n\"], [\"Role {'name': 'galera_server', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-galera_server', 'version': '0b853b1da7802f6fac8da309c88886186f6a15a6', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/galera_server'} failed after 2 retries\\n\"], [\"Role {'name': 'os_nova', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_nova', 'version': '43b1b62f22b47e3148adcc4cd2396a4e29522e9b', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_nova'} failed after 2 retries\\n\"], [\"Role {'name': 'os_keystone', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_keystone', 'version': 'f1625b38a820dd51cffa66141053a836211695dc', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_keystone'} failed after 2 retries\\n\"]]\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1} PLAY RECAP ****************************************************************************************************************************************************************************************** localhost : ok=4 changed=0 unreachable=0 failed=1 skipped=8 rescued=0 ignored=0 ++ exit_fail 405 0 ++ set +x Last metadata expiration check: 2:12:54 ago on Wed 10 Feb 2021 01:34:28 PM IST. Package iproute-5.3.0-5.el8.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! Failed to get DNSSEC supported state: Unit dbus-org.freedesktop.resolve1.service not found. which: no lxc-ls in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) which: no lxc-checkconfig in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) which: no networkctl in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) [WARNING]: Skipping callback plugin '/dev/null', unable to load which: no btrfs in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin :/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) which: no btrfs in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin :/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) which: no zfs in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/ usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) ++ info_block 'Error Info - 405' 0 ++ echo ---------------------------------------------------------------------- ---------------------------------------------------------------------- ++ print_info 'Error Info - 405' 0 ++ PROC_NAME='- [ Error Info - 405 0 ] -' ++ printf '\n%s%s\n' '- [ Error Info - 405 0 ] -' ------------------------------ -------------- - [ Error Info - 405 0 ] --------------------------------------------- ++ echo ---------------------------------------------------------------------- ---------------------------------------------------------------------- ++ exit_state 1 ++ set +x ---------------------------------------------------------------------- - [ Run Time = 163 seconds || 2 minutes ] ---------------------------- ---------------------------------------------------------------------- ---------------------------------------------------------------------- - [ Status: Failure ] ------------------------------------------------ ---------------------------------------------------------------------- Pls suggest how to fix these issues thanks. Regards, Amey.

2 4

[baremetal-sig][ironic] Tue Feb 9, 2021, 2pm UTC: Deploy Steps in Ironic
by Arne Wiebalck 11 Feb '21

11 Feb '21

Dear all, The Bare Metal SIG will meet tomorrow Tue Feb 9, 2021 at 2pm UTC on zoom. This time there will be a 10 minute "topic-of-the-day" presentation by Dmitry Tantsur (dtansur) on: 'An Introduction to Deploy Steps in Ironic' If you've never found the time to understand what deploy steps are and how they are useful, this is your chance to hear it from one of the experts! You can find all the details for this meeting on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, don't miss out! Cheers, Arne

2 1

[charms] OpenStack Charms 21.01 release is now available
by Peter Matulis 11 Feb '21

11 Feb '21

The 21.01 release of the OpenStack Charms is now available. This release brings several new features to the existing OpenStack Charms deployments for Queens, Rocky, Stein, Train, Ussuri, Victoria and many stable combinations of Ubuntu + OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2101.html == Highlights == * Cinder-Ceph - Image mirroring The cinder-ceph charm now supports image replication to a second Ceph cluster. * Ironic charms Three new tech-preview charms are now available for the deployment of OpenStack Ironic. Ironic provisions bare metal machines, as opposed to virtual machines. * Glance multi-backend usage When multiple storage backends are used with Glance, the glance charm now supports the CLI Glance client option (--store) that enables an operator to specify, at image upload time, which backend will be used to store the image. * Documentation updates Ongoing improvements to the OpenStack Charms Deployment Guide, the OpenStack Charm Guide, and the charm READMEs. * Trusty series deprecation The ‘trusty’ series is no longer actively tested and is now EOL in terms of bug fixes for the OpenStack charms. == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on Freenode. == Thank you == Lots of thanks to the below 33 contributors who squashed 52 bugs, enabled new features, and improved the documentation! Alex Kavanagh Alvaro Uria Andrea Ieri Arif Ali Aurelien Lourot Billy Olsen Corey Bryant David Ames Dmitrii Shcherbakov Dongdong Tao Edward Hope-Morley Eric Desrochers Felipe Reyes Frode Nordahl Gabriel Samfira Garrett Thompson Giuseppe Petralia Hemanth Nakkina Ioanna Alifieraki Ionut Balutoiu Jarred Wilson Liam Young Linda Guo Marius Oprin Martin Fiala Martin Kalcok Peter Matulis Peter Sabaini Ponnuvel Palaniyappan Robert Gildein Rodrigo Barbieri Trent Lloyd Xav Paice -- OpenStack Charms Team

1 0

[release] Proposing Előd Illés (elod) for Release Management Core
by Herve Beraud 10 Feb '21

10 Feb '21

Hi, Előd has been working on Release management for quite some time now and in that time has shown tremendous growth in his understanding of our processes and on how deliverables work on Openstack. I think he would make a good addition to the core team. Existing team members, please respond with +1/-1. If there are no objections we'll add him to the ACL soon. :-) Thanks. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

5 5

[QA] Migrate from testr to stestr
by Martin Kopec 10 Feb '21

10 Feb '21

Hi everyone, testr unit test runner (testrepository package [1]) hasn't been updated for years, therefore during Shanghai PTG [2] we came up with an initiative to migrate from testr to stestr (testr's successor) [3] unit test runner. Here is an etherpad which tracks the effort [4]. However as there is still quite a number of the projects which haven't migrated, we would like to kindly ask you for your help. If you are a maintainer of a project which is mentioned in the etherpad [4] and it's not crossed out yet, please migrate to stestr. [1] https://pypi.org/project/testrepository/ [2] https://etherpad.opendev.org/p/shanghai-ptg-qa [3] https://pypi.org/project/stestr/ [4] https://etherpad.opendev.org/p/enkM4eeDHObSloTjPGAu Have a nice day, -- Martin Kopec Software Quality Engineer Red Hat EMEA <https://www.redhat.com> <https://red.ht/sig>

6 5