January 2021 - openstack-discuss - lists.openstack.org

[largescale-sig] OpenStack DB Archiver
by Arnaud Morin 10 Feb '21

10 Feb '21

Hello large-scalers! TLDR: we opensource a tool to help reducing size of databases. See https://github.com/ovh/osarchiver/ Few months ago, we released a tool, name osarchiver, which we are using on our production environment (at OVH) to help reduce the size of our tables in mariadb (or mysql) In fact, some tables are well know to grow very quickly. We use it, for example, to clean the OpenStack mistral database from old tasks, actions and executions which are older than a year. Another use case could be to archive some data in another table (e.g. with _archived as suffix) if they are 6 months old, and delete this data after 1 year. The source code of this tool is available here: https://github.com/ovh/osarchiver/ We were wondering if some other users would be interested in using the tool, and maybe move it under the opendev governance? Feel free to contact us and/or answer this thread. Cheers, -- Arnaud, Pierre-Samuel and OVH team

12 18

[nova][placement] adding nova-core to placement-core in gerrit
by Balazs Gibizer 09 Feb '21

09 Feb '21

Hi, Placement got back under nova governance but so far we haven't consolidated the core teams yet. Stephen pointed out to me that given the ongoing RBAC works it would be beneficial if more nova cores, with API and RBAC experience, could approve such patches. So I'm proposing to add nova-core group to the placement-core group in gerrit. This means Ghanshyam, John, Lee, and Melanie would get core rights in the placement related repositories. @placement-core, @nova-core members: Please let me know if you have any objection to such change until end of this week. cheers, gibi

6 9

[ironic] On redfish-virtual-media vs idrac-redfish-virtual-media
by Dmitry Tantsur 09 Feb '21

09 Feb '21

Hi all, Now that we've gained some experience with using Redfish virtual media I'd like to reopen the discussion about $subj. For the context, the idrac-redfish-virtual-media boot interface appeared because Dell machines need an additional action [1] to boot from virtual media. The initial position on hardware interfaces was that anything requiring OEM actions must go into a vendor hardware interface. I would like to propose relaxing this (likely unwritten) rule. You see, this distinction causes a lot of confusion. Ironic supports Redfish, ironic supports iDRAC, iDRAC supports Redfish, ironic supports virtual media, Redfish supports virtual media, iDRAC supports virtual media. BUT! You cannot use redfish-virtual-media with iDRAC. Just today I had to explain the cause of it to a few people. It required diving into how exactly Redfish works and how exactly ironic uses it, which is something we want to protect our users from. We already have a precedent [2] of adding vendor-specific handling to a generic driver. I have proposed a patch [3] to block using redfish-virtual-media for Dell hardware, but I grew to dislike this approach. It does not have precedents in the ironic code base and it won't scale well if we have to handle vendor differences for vendors that don't have ironic drivers. Based on all this I suggest relaxing the rule to the following: if a feature supported by a generic hardware interface requires additional actions or has a minor deviation from the standard, allow handling it in the generic hardware interface. Meaning, redfish-virtual-media starts handling the Dell case by checking the System manufacturer (via the recently added detect_vendor call) and loading the OEM code if it matches "Dell". After this idrac-redfish-virtual-media will stay empty (for future enhancements and to make the patch backportable). Thoughts? Dmitry [1] https://opendev.org/openstack/ironic/src/commit/6ea73bdfbb53486cf9905d21024… [2] https://review.opendev.org/c/openstack/ironic/+/757198/ [3] https://review.opendev.org/c/openstack/ironic/+/771619 -- 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

5 7

bindep, pacman, and PyPI release
by Jakob Lykke Andersen 06 Feb '21

06 Feb '21

Dear developers, I'm trying to use bindep on Arch but hitting a problem with the output handling. It seems that 'pacman -Q' may output warning lines if you have a file with the same name as the package. E.g.,: $ mkdir cmake $ pacman -Q cmake error: package 'cmake' was not found warning: 'cmake' is a file, you might want to use -p/--file. The current detection assumes the "was not found" is the last part of the output. Applying the patch below seems to fix it. After applying this patch, or whichever change you deem reasonable to fix the issue, it would be great if you could make a new release on PyPI. Thanks, Jakob diff --git a/bindep/depends.py b/bindep/depends.py index bb9553f..cacc863 100644 --- a/bindep/depends.py +++ b/bindep/depends.py @@ -558,7 +558,8 @@ class Pacman(Platform): stderr=subprocess.STDOUT).decode(getpreferredencoding(False)) except subprocess.CalledProcessError as e: eoutput = e.output.decode(getpreferredencoding(False)) - if e.returncode == 1 and eoutput.strip().endswith('was not found'): + s = "error: package '{}' was not found".format(pkg_name) + if e.returncode == 1 and s in eoutput: return None raise # output looks like

2 2

[all][mentoring][outreachy][GSoC]Summer Interns/ Student Coders Anyone?
by Kendall Nelson 05 Feb '21

05 Feb '21

Hello :) So, if you've been involved in Outreachy, the Google Summer of Code[1] is pretty similar. It looks like the applications for projects open January 29, 2021 at 11:00 (Pacific Standard Time) if anyone wants to apply. I encourage you all to do so! It gets a lot of attention from university students so it's a great opportunity to get some new contributors and teach some more of the world about our community and open source! If you are interested in applying, let me know and I will do what I can to help you with the application to get it done on time (deadline not listed on the site yet, but they always come faster than we'd like)! -Kendall (diablo_rojo) [1] https://summerofcode.withgoogle.com/get-started/

1 1

[All][StoryBoard] Angular.js Alternatives
by Kendall Nelson 05 Feb '21

05 Feb '21

Hello Everyone! The StoryBoard team is looking at alternatives to Angular.js since its going end of life. After some research, we've boiled all the options down to two possibilities: Vue.js or React.js I am diving more deeply into researching those two options this week, but any opinions or feedback on your experiences with either of them would be helpful! Here is the etherpad with our research so far[3]. Feel free to add opinions there or in response to this thread! -Kendall Nelson (diablo_rojo) & The StoryBoard Team [1] https://vuejs.org/ [2] https://reactjs.org/ [3] https://etherpad.opendev.org/p/replace-angularjs-storyboard-research

10 15

[ops][largescale-sig] How many compute nodes in a single cluster ?
by Thierry Carrez 05 Feb '21

05 Feb '21

Hi everyone, As part of the Large Scale SIG[1] activities, I'd like to quickly poll our community on the following question: How many compute nodes do you feel comfortable fitting in a single-cluster deployment of OpenStack, before you need to scale it out to multiple regions/cells/.. ? Obviously this depends on a lot of deployment-dependent factors (type of activity, choice of networking...) so don't overthink it: a rough number is fine :) [1] https://wiki.openstack.org/wiki/Large_Scale_SIG Thanks in advance, -- Thierry Carrez (ttx)

7 12

[magnum] [neutron] [ovn] No inter-node pod-to-pod communication due to missing ACLs in OVN
by Krzysztof Klimonda 04 Feb '21

04 Feb '21

Hi, This email is a follow-up to a discussion I've openened on ovs-discuss ML[1] regarding lack of TCP/UDP connectivity between pods deployed on magnum-managed k8s cluster with calico CNI and IPIP tunneling disabled (calico_ipv4pool_ipip label set to a default value of Off). As a short introduction, during magnum testing in ussuri deployment with ml2/ovn neutron driver I've noticed lack of communication between pods deployed on different nodes as part of magnum deployment with calico configured to *not* encapsulate traffic in IPIP tunnel, but route it directly between nodes. In theory, magnum configures adds defined pod network to k8s nodes ports' allowed_address_pairs[2] and then security group is created allowing for ICMP and TCP/UDP traffic between ports belonging to that security group[3]. This doesn't work with ml2/ovn as TCP/UDP traffic between IP addresses in pod network is not matching ACLs defined in OVN. I can't verify this behaviour under ml2/ovs for the next couple of weeks, as I'm taking them off for holidays, but perhaps someone knows if that specific usecase (security group rules with remote groups used with allowed address pairs) is supposed to be working, or should magnum use pod network cidr to allow traffic between nodes instead. [1] https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050836.html [2] https://github.com/openstack/magnum/blob/c556b8964fab129f33e766b1c33908b2eb… [3] https://github.com/openstack/magnum/blob/c556b8964fab129f33e766b1c33908b2eb… -- Best Regards, - Chris

5 9

[all] Eventlet broken again with SSL, this time under Python 3.9
by Thomas Goirand 04 Feb '21

04 Feb '21

Hi, Swift proxy fails with Python 3.9 under Debian Unstable with Python 3.9: http://paste.openstack.org/show/802063/ (that's when doing a simple "openstack container list") I got the same problem with neutron-rpc-server: http://paste.openstack.org/show/802071/ (this happens when neutron-rpc-server tries to tell Nova that my new VM port is up) I didn't really look further, but I guess so many services are affected. This looks like general to OpenStack, and feels like yet-another-problem-with-eventlet, and looks very similar to this one: https://github.com/eventlet/eventlet/issues/677 even though that's here a Python 3.9 issue, not 3.7. I'd very much appreciate if some Eventlet specialist could look into this problem, because that's beyond my skills. Cheers, Thomas Goirand (zigo)

5 17

Backup drivers issue with the container parameter
by Gorka Eguileor 03 Feb '21

03 Feb '21

Hi all, In the next Cinder meeting I'll bring a Backup driver issue up for discussion, and this email hopefully provides the necessary context to have a fruitful discussion. The issue is around the `container` optional parameter in backup creation, and its user and administrator unfriendliness. The interpretation of the `container` parameter is driver dependent, and it's being treated as: - A bucket in Google Cloud Storage and the new S3 driver - A container in Swift - A pool in Ceph - A directory in NFS and Posix Currently the only way to prevent cloud users from selecting a different `container` is by restricting what the storage user configured in Cinder backup can do. For Ceph we can make the storage user unable to access any other existing pools, for Swift, GCS, and S3 we can remove permissions to create buckets/containers from the storage user. This achieves the administrator's objective of not allowing them to change the `container`, but cloud users will have a bad experience, because the API will accept the request but the backup will go into `error` state and they won't see any additional information. And this solution is an all or nothing approach, as we cannot allow just some cloud users select the container while preventing others from doing so. For example we may want some cloud users to be able to do backups on a specific RBD pool that is replicated to a remote location. I think we can solve all these issues if we: - Create a policy for accepting the `container` parameter on the API (defaulting to allow for backward compatibility). - Add a new configuration option `backup_container_regex` to control acceptable values for the `container` (defaults to `.*` for backward compatibility). This option would be used by the backup manager (not the drivers themselves) on backup creation, and would result in a user message if the provided container was not empty and failed the regex check. I think this summarizes the situation and my view on the matter. Feedback is welcome here or in the next Cinder meeting. Cheers, Gorka.

2 1