March 2021 - openstack-discuss - lists.openstack.org

[election][qa] PTL candidacy for Xena
by Martin Kopec 09 Mar '21

09 Mar '21

Hi everyone, I would like to nominate myself for the PTL role of the QA in the Xena cycle. This would be my first PTL service, however, I have been contributing to Tempest for several years and have been a core contributor for over a year now. I'm also a core in refstack projects (python-tempestconf, refstack and refstack-client). A few things I would like to focus on in the Xena cycle: * Get Tempest scenario manager effort [2] finished - we started actively working on this ~2 cycles ago and we have made significant progress. After it's done we will declare the interface stable which will help to decrease the code duplicity among tempest plugins which is directly related to the maintenance difficulty. * Keep decreasing the bug counts * Decrease the number of open patches. Although many projects suffer from not enough personal resources, we can't let the contributors go out of their steam by making their patches to wait in the queue for too long. * Complete priority items from the previous cycles [1] https://www.stackalytics.com/?user_id=mkopec [2] https://etherpad.opendev.org/p/tempest-scenario-manager Thanks for your consideration! -- Martin Kopec irc: kopecmartin

1 0

[tripleo][ci] stein and quay.io
by Wesley Hayutin 09 Mar '21

09 Mar '21

Greetings, FYI... At this time the accounts used to push containers in quay.io has been locked out. We are working with quay support to resolve the issue. It's not 100% clear if there is an issue w/ our account or more generally w/ quay [2] At this time we know that the stable/stein branch in tripleo is specifically configured to pull containers from quay and has an open issue [1]. Merging patches on stable/stein is likely blocked unless we move all those jobs to non-voting at this time. Is there any interest in moving the jobs to non-voting? Please respond if this issue is blocking you. Thanks all! [1] https://bugs.launchpad.net/tripleo/+bug/1915921 [2] https://status.quay.io/

1 0

[TripleO] Xena PTG - registration and reserved time slots
by Marios Andreou 09 Mar '21

09 Mar '21

Hello TripleO gentle early reminder that PTG is coming soon-ish... 12 April is not *that* far away ;) As requested by [1] I just booked some slots for us at https://ethercalc.net/oz7q0gds9zfi . I selected the same times we used for the Wallaby PTG - 1300-1700 UTC for Monday/Tuesday/Wednesday/Thursday. Obviously we are a massively distributed team so there is no good time that will suit everyone. However I think this serves well enough for the majority of our contributors? We may not use Thursday but it was pretty close last time with respect to the number of sessions requested so I booked it just in case. Please speak up if you disagree with the times and days I have booked. Finally *** REMEMBER TO REGISTER *** for the PTG at https://april2021-ptg.eventbrite.com regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020915.ht…

1 1

[election][cloudkitty] PTL candidacy for Xena
by Rafael Weingärtner 09 Mar '21

09 Mar '21

Hello guys, I would like to self-nominate for the role of PTL of CloudKitty for the Xena release cycle. I am the current PTL for the Wallaby cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain CloudKitty for their use cases and encourage the addition of new functionalities. Thank you for your support, -- Rafael Weingärtner

1 0

[OSSN-0088] Some of the Glance metadef APIs likely to leak resources
by Abhishek Kekane 09 Mar '21

09 Mar '21

Some of the Glance metadef APIs likely to leak resources -------------------------------------------------------- ### Summary ### Metadef APIs are vulnerable and potentially leaking information to unauthorized users and also there is currently no limit on creation of metadef namespaces, objects, properties, resources and tags. This can be abused by malicious users to fill the Glance database resulting in a Denial of Service (DoS) condition. ### Affected Services / Software ### Glance ### Discussion ### There is no restriction on creation of metadef namespaces, objects, properties, resources and tags as well as it could also leak the information to unauthorized users or to the users outside of the project. By taking advantage of this lack of restrictions around metadef APIs, a a single user could fill the Glance database by creating unlimited resources, resulting in a Denial Of Service (DoS) style attack. Glance does allow metadef APIs to be controlled by policy. However, the default policy setting for metadef APIs allows all users to create or read the metadef information. Because metadef resources are not properly isolated to the owner, any use of them with potentially sensitive names (such as internal infrastructure details, customer names, etc) could unintentionally expose that information to a malicious user. ### Recommended Actions ### Since these fundamental issues have been present since the API was introduced, the Glance project is recommending operators disable all metadef APIs by default in their deployments. Here is an example of disabling the metadef APIs in the deployments for current stable OpenStack releases either in policy.json or policy.yaml. ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "!", "get_metadef_namespace": "rule:metadef_default", "get_metadef_namespaces": "rule:metadef_default", "modify_metadef_namespace": "rule:metadef_default", "add_metadef_namespace": "rule:metadef_default", "get_metadef_object": "rule:metadef_default", "get_metadef_objects": "rule:metadef_default", "modify_metadef_object": "rule:metadef_default", "add_metadef_object": "rule:metadef_default", "list_metadef_resource_types": "rule:metadef_default", "get_metadef_resource_type": "rule:metadef_default", "add_metadef_resource_type_association": "rule:metadef_default", "get_metadef_property": "rule:metadef_default", "get_metadef_properties": "rule:metadef_default", "modify_metadef_property": "rule:metadef_default", "add_metadef_property": "rule:metadef_default", "get_metadef_tag": "rule:metadef_default", "get_metadef_tags": "rule:metadef_default", "modify_metadef_tag": "rule:metadef_default", "add_metadef_tag": "rule:metadef_default", "add_metadef_tags": "rule:metadef_default" ---- end example policy.json/policy.yaml snippet ---- To re-enable metadef policies to be allowed to be admin only, operator(s) can make a change in respective policy.json or policy.yaml as shown below; (assuming all metadef policies are configured to use rule:metadeta_default as shown in above example) ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "rule:admin", ---- begin example policy.json/policy.yaml snippet ---- Operators with users that depend on metadef APIs may choose to leave these accessible to all users. In that case, education of users about the potential for information leakage in the resource names is advisable so that vulnerable practices can be altered as mitigation. To re-enable metadef policies to all users, operator(s) can make a change in respective policy.json or policy.yaml as shown below; (assuming all metadef policies are configured to use rule:metadeta_default as shown in above example) ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "", ---- begin example policy.json/policy.yaml snippet ---- ### Contacts / References ### Author: Abhishek Kekane, Red Hat Author: Lance Bragstad, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0088 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1545702 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1916926 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1916922 Mailing List : [Security] openstack-security(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg Thanks & Best Regards, Abhishek Kekane

1 0

Cleanup database(s)
by Eugen Block 09 Mar '21

09 Mar '21

Hi *, I have a quick question, last year we migrated our OpenStack to a highly available environment through a reinstall of all nodes. The migration went quite well, we're working happily in the new cloud but the databases still contain deprecated data. For example, the nova-scheduler logs lines like these on a regular basis: /var/log/nova/nova-scheduler.log:2021-02-19 12:02:46.439 23540 WARNING nova.scheduler.host_manager [...] No compute service record found for host compute1 This is one of the old compute nodes that has been reinstalled and is now compute01. I tried to find the right spot to delete some lines in the DB but there are a couple of places so I wanted to check and ask you for some insights. The scheduler messages seem to originate in /usr/lib/python3.6/site-packages/nova/scheduler/host_manager.py ---snip--- for cell_uuid, computes in compute_nodes.items(): for compute in computes: service = services.get(compute.host) if not service: LOG.warning( "No compute service record found for host %(host)s", {'host': compute.host}) continue ---snip--- So I figured it could be this table in the nova DB: ---snip--- MariaDB [nova]> select host,deleted from compute_nodes; +-----------+---------+ | host | deleted | +-----------+---------+ | compute01 | 0 | | compute02 | 0 | | compute03 | 0 | | compute04 | 0 | | compute05 | 0 | | compute1 | 0 | | compute2 | 0 | | compute3 | 0 | | compute4 | 0 | +-----------+---------+ ---snip--- What would be the best approach here to clean up a little? I believe it would be safe to simply purge those lines containing the old compute node, but there might be a smoother way. Or maybe there are more places to purge old data from? I'd appreciate any ideas. Regards, Eugen

2 8

[election][blazar] PTL candidacy for Xena
by Pierre Riteau 09 Mar '21

09 Mar '21

Hi, I would like to self-nominate for the role of PTL of Blazar for the Xena release cycle. I have been PTL since the Stein cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain the Blazar software for their use cases and encourage the addition of new functionalities. Thank you for your support, Pierre Riteau (priteau)

1 0

[election][storlets] PTL Candidacy for Xena
by Takashi Kajinami 09 Mar '21

09 Mar '21

Hi All, I'd like to announce my candidacy to continue the PTL role for Storlets project in the Xena cycle. Because we currently don't have very active development in Storlets project, I'll propose we mainly focus on the following two items during the next cycle. - Improve stability of our code - Keep compatibility with the latest items - Latest Swift - Latest Ubuntu LTS In addition, I'll initiate some discussion about our future release and management model, considering decreasing resources for reviews and developments. Thank you for your consideration. Thank you, Takashi

1 0

[election][kolla] PTL candidacy for Xena
by Mark Goddard 09 Mar '21

09 Mar '21

Hi, I'd like to nominate myself to serve as the Kolla PTL for the Xena cycle. I have been PTL for the last 4 cycles, and would like the opportunity to continue to lead the team. Overall I think that the project is moving in the right direction. Some things that I think we should focus on in the next cycle are: * remove our dependency on Dockerhub in CI testing to avoid pull limits * improve the documentation * expand the core team Thanks for reading, Mark Goddard (mgoddard)

1 0

How to Handle RabbitMQ peak after restarting neutron-openvswitch-agent
by MaSch 09 Mar '21

09 Mar '21

Hello at all. After adding an new direct attached VLAN to our computeNodes and restarting neutron-openvswitch-agent, we detected a huge peak in RabbitMQ Messages. Mostly "neutron-vo-Port-1.1_fanout" these messages seem every node produced 5000+ Messages. Due to a bridge_mapping mismatch, the agent repeatedly restarted and produced more and more Messages. At the peak there were about 2Million messages in the queue. As we ran into Network issues caused by Messaging timeouts i would like to know if there is a procedure to handle this messages. Is it save to delete the queue as those messages? It seems they disappeared after a timeout period of about 30 Minutes. are currently using OpenStack Queens release. Thanks a lot in advance. Best regards MaSch

1 0