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

placement service issue (placement-status upgrade check failure)
by Deepak Mohanty 12 Jul '21

12 Jul '21

I need your help with installation of placement service on Ubuntu 20.04. I have followed the steps in: https://docs.openstack.org/placement/wallaby/install/install-ubuntu.html I am facing the following issue when I try to verify the installation: $ placement-status upgrade check Error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/oslo_upgradecheck/upgradecheck.py", line 196, in run return conf.command.action_fn() File "/usr/lib/python3/dist-packages/oslo_upgradecheck/upgradecheck.py", line 104, in check result = func_name(self, **kwargs) File "/usr/lib/python3/dist-packages/oslo_upgradecheck/common_checks.py", line 41, in check_policy_json policy_path = conf.find_file(conf.oslo_policy.policy_file) File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2543, in find_file raise NotInitializedError() oslo_config.cfg.NotInitializedError: call expression on parser has not been invoked I did a bit of debugging and found that the policy file is: policy.json. I could not find any policy.json on my machine. I created an empty policy.json at: /etc/placement/policy.json (user and group = placement). That too did not work. I have followed the steps in the install guide twice, deleting the placement database and other resources and recreating them. I continue to see the same issue. Thank you for your time.

5 6

[ patrole ] Understanding RBAC Permission Exceptions
by darumaseye 12 Jul '21

12 Jul '21

Hello, I am a researcher studying security of the Openstack's Policies. I'm very interested in the Patrole project and I would like to ask you some questions. In the documentation it is stated that Patrole compares two different types of results: - an expected one ( derived from oslo.policy ) - an actual one ( derived from an actual request to the API ). Given that, Patrole's tests can return 3 different values: 1) "Success" if actual result and expected result are both True or both False; 2) "RbacOverPermissionException" if actual result is True but expected result is False; 3) "RbacUnderPermissionException" in the other case. I can't understand in which cases the tests can return a value different from "Success". As far as I know, an API call should always be validated internally by oslo.policy's rules, before being allowed. So, in order for an API call to be accepted, oslo.policy's rules must allow that API call. It seems to me that the "expected" result ( derived from oslo.policy ) is always included in the actual result. Hoping that everything I said is correct, I would like to ask you: What issue is allowing such a strange behavior in Openstack APIs ? Why the expected results can be different from the actual ones? Are there publicly available examples showing "Failure" values? In general, are there any publicly available test cases that i can study to understand this? I Would like to thank you very much in advance; Best Regards, Jacopo

3 3

Cinder error while creating Volumes in Openstack
by Adivya Singh 12 Jul '21

12 Jul '21

Hello Team, i am seeing the below error, while creating volumes in cinder log, Any solution or fix for these error, as of now i am not able to create volumes, neither i am unable to delete, it just sits in hung state DISTRIB_RELEASE="18.1.9" DISTRIB_CODENAME="Rocky" DISTRIB_DESCRIPTION="OpenStack-Ansible" Regards Adivya Singh

2 1

OpenInfra Live - July 15 at 9am CT
by Ashlee Ferguson 12 Jul '21

12 Jul '21

Hi everyone, This week’s OpenInfra Live episode is brought to you by the Open Infrastructure Foundation. One of the reasons workloads moved to virtualization and clouds was to avoid having underutilized resources. But as demand for resources goes up and down, the cloud itself can now have a lot of spare capacity. How do OpenStack-based large scale clouds manage their spare capacity? Join this live discussion between operators of private and public clouds with InMotion Hosting, CERN, NECTAR research cloud, Verizon Media, City Network and Open Telekom Cloud. Episode: How OpenStack Large Clouds Manage their Spare Capacity Date and time: July 15 at 9am CT (1400 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=G7oN2XdI__k <https://www.youtube.com/watch?v=G7oN2XdI__k> LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6818945419729604608 <https://www.linkedin.com/feed/update/urn:li:ugcPost:6818945419729604608> Facebook: https://www.facebook.com/104139126308032/posts/4134653546589883/ <https://www.facebook.com/104139126308032/posts/4134653546589883/> WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Belmiro Moreira, CERN Brendan Conlan, Verizon Media Chris Bermudez, InMotion Hosting Erik Johansson, CityNetwork Sam Morrison, NECTAR Viktor Molnar, T-Systems Have an idea for a future episode? Share it now at ideas.openinfra.live <https://openinfrafoundation.formstack.com/forms/openinfralive>. Thanks, Ashlee

1 0

[octavia] Meeting cancelled
by Gregory Thiemonge 12 Jul '21

12 Jul '21

Hi, I'm out of the office on July 14th, I won't be able to attend the weekly meeting. The meeting is cancelled. See you next week. Greg

1 0

[neutron] bug deputy report for week of 2021-07-05
by Bence Romsics 12 Jul '21

12 Jul '21

Hi Neutron Team, These are the new bugs of last week: High: * https://bugs.launchpad.net/neutron/+bug/1934930 [ovn] Multiple servers can try to create neutron_pg_drop at the same time fix proposed: https://review.opendev.org/c/openstack/neutron/+/799900 * https://bugs.launchpad.net/neutron/+bug/1934915 [OVN Octavia Provider] Investigate tempest failures tests disabled to unblock ovn-octavia-provider gate: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/799864 Medium: * https://bugs.launchpad.net/neutron/+bug/1934666 IPv6 not set on VMs when using DVR HA + SLAAC/SLAAC (or DHCPv6 stateless) * https://bugs.launchpad.net/neutron/+bug/1934912 Router update fails for ports with allowed_address_pairs containg IP range in CIDR notation fix proposed: https://review.opendev.org/c/openstack/neutron/+/800059 Low: * https://bugs.launchpad.net/neutron/+bug/1934957 [sriov] Unable to change the VF state for i350 interface unassigned RFE / Wishlist: * https://bugs.launchpad.net/neutron/+bug/1934948 [RFE] refactor of L3 resources update procedure * https://bugs.launchpad.net/neutron/+bug/1935764 RFE: Adding support for direct ports with qos in ovn * https://bugs.launchpad.net/neutron/+bug/1934670 neutron-tempest-plugin should migrate from paramiko Incomplete: * https://bugs.launchpad.net/neutron/+bug/1934135 nova cannot create instances, because it doesn't find the network Regards, Bence

1 0

[keystone][interop][refstack] Adding new capabilities to track in interop
by Martin Kopec 12 Jul '21

12 Jul '21

Hi everyone, we are adding new capabilities and tests for keystone service to interop, see: https://review.opendev.org/c/osf/interop/+/799163 If someone from keystone could review the patch, it would be great. Thanks, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[Image Encryption] No meeting today
by Josephine Seifert 12 Jul '21

12 Jul '21

Hi, there will not be a meeting today, as I am ill. The next meeting will be next Monday the 19th of July. greetings Luzi

1 0

[qa] Virtual PTG October 2021
by Martin Kopec 12 Jul '21

12 Jul '21

Hi everyone, as you have probably heard our next PTG will be held virtually in October. I've created a Doodle [1] to collect the best time slots for our team. Please fill it in by Tuesday July 20th (the deadline for team signup is July 21st). I've also created an etherpad [2] to collect ideas/topics for the PTG sessions. If you have anything to discuss, please don't hesitate to write it there. [1] https://doodle.com/poll/a8gakx4ca6zvtuem?utm_source=poll&utm_medium=link [2] https://etherpad.opendev.org/p/qa-yoga-ptg Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[kolla][wallaby][neutron][vpnaas]
by Franck VEDEL 12 Jul '21

12 Jul '21

Hello, and first excuse my English please… thanks a lot. I hope you will understand my problem. I have a problem with the following configuration: kolla-ansible, centos, wallaby. I need the vpnaas service. I create internal networks, configure these networks, the routers, and I create a vpnaas between two internal networks (2 cirros instances for example). To the left; net1: 192.168.10.0/24 Right, net2: 192.168.20.0/24 VM On the left: ping VM on the right (ex 192.168.20.30). The ping goes to the internet, it is handled by the default route on the router leaving net1. I do the same with Victoria: it works. I am testing a VPN between net1 and an internal network behind a real network, behind a watchguard. With Victoria, it works. With Wallaby, it doesn't work. Neutron-l3-agent logs says: Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl ») Is there a bug in wallaby? What could be the problem, the configuration and the hardware is the same, it works with victoria, not with wallaby. Thanks for your help. Franck

1 1