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

[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 04 Feb '21

04 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

[baremetal-sig][ironic] Tue Jan 12, 2021, 2pm UTC: 'Multi-Tenancy in Ironic: Of Owners and Lessees'
by Arne Wiebalck 02 Feb '21

02 Feb '21

Dear all, Happy new year! The Bare Metal SIG will continue its monthly meetings and start again on Tue Jan 12, 2021, at 2pm UTC. This time there will be a 10 minute "topic-of-the-day" presentation by Tzu-Mainn Chen (tzumainn) on 'Multi-Tenancy in Ironic: Of Owners and Lessees' So, if you would like to learn how this relatively recent addition to Ironic works, 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

3 5

Strange behaviour of OSC in keystone MFA context
by Taltavull Jean-Francois 02 Feb '21

02 Feb '21

Hello, I'm experiencing the following strange behavior of openstack CLI with os-auth-methods option (most parameters are defined in clouds.yaml): $ openstack token issue --os-auth-type v3multifactor --os-auth-methods password,totp The plugin p could not be found Note that "p" is the first letter of "password". It looks like the option parser handled "password,totp" as a string instead of as a list of strings. Version of openstack CLI is 5.4.0. Any idea ? Thanks ! Jean-François

5 7

[cinder] wallaby R-9 mid-cycle poll
by Brian Rosmaita 02 Feb '21

02 Feb '21

Hello Cinder team and anyone interested in Cinder, The second wallaby mid-cycle meeting will be held during week R-9 (the week of 8 February 2021). It will be 2 hours long. Please indicate your availability on the following poll: https://doodle.com/poll/9vqri7855cab858d Please respond before 21:00 UTC on Tuesday 2 February 2021. thanks, brian

1 1

[magnum][heat] Rolling system upgrades
by Krzysztof Klimonda 01 Feb '21

01 Feb '21

Hi, While testing magnum, a problem of upgrades came up - while work has been done to make kubernetes upgrades without interruption, operating system upgrades seem to be handled only partially. According to the documentation, two ways of upgrading system are available: - via specifying ostree_commit or ostree_remote labels in the cluster template used for upgrade - via specifying a new image in the cluster template used for upgrade The first one is specific to Fedora Atomic (and, while probably untested, seems to be mostly working with Fedora CoreOS) but it has some drawbacks. Firstly, due to base image staying the same we require this image for the life of the cluster, even if OS has already been upgraded. Secondly, using this method only upgrades existing instances and new instances (spawned via scaling cluster up) will not be upgraded. Thirdly, even if that is fixed I'm worried that at some point upgrading from old base image to some future ostree snapshot will fail (there is also cost associated with diff growing with each release). The second method, of specifying a new image in the cluster template used for upgrade, comes with an ugly warning about nodes not being drained properly before server rebuild (and it actually doesn't seem to be working anyway as the new image parameter is not being passed to the heat template on upgrade). This does however seem like a more valid approach in general. I'm not that familar with Heat, and the documentation of various OS::Heat::Software* resources seems inconclusive, but is there no way of executing some code before instance is rebuilt? If not, how are other projects and users handling this in general? -- Krzysztof Klimonda kklimonda(a)syntaxhighlighted.com

2 3

[Diversity] Diversity &Inclusion WG Meeting reminder Amy Marrich <amy@demarco.com> Mon, Jan 11, 7:49 AM to foundation, openstack-discuss, kata-dev, starlingx-discuss, airship-discuss, zuul-discuss The Diversity & Inclusion WG invites members of all OSF projects to our meeting today, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)
by Amy Marrich 31 Jan '21

31 Jan '21

The Diversity & Inclusion WG invites members of all OSF projects to our meeting tomorrow, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

[DHCP][Provider Network] Instances get IP from external DHCP server
by dangerzone ar 31 Jan '21

31 Jan '21

Hi, appreciate some advice on how instances in openstack get ip from external DHCP server. For example instance is attached to port eth1 (physical port) and this port is connected to home/office lan port and requests dhcp ip. How this can be achieved. ***User don't know the dhcp ip range/gw/dns that will be provided by the dhcp sever to that instance...instance just attach to eth1 and request ip.*** Similar like our pc/notebook request dhcp ip via wifi or lan port. How to establish this in openstack. Please advise and help me. Thank you

3 5

Advise Request
by Karera Tony 30 Jan '21

30 Jan '21

Dear Team, I deployed the Openstack Ussuri version and everything was working fine with the small cirros Image since its a test environment for now. I started facing an issue when I uploaded a bigger image (Ubuntu 16.04 Xenialand Ubuntu 18.04 Biomic), When I tried to create an instance using any of those images, I got the error below. Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", line 1942, in _prep_block_device wait_func=self._await_block_device_map_created) File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/block_device.py", line 874, in attach_block_devices _log_and_attach(device) File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/block_device.py", line 871, in _log_and_attach bdm.attach(*attach_args, **attach_kwargs) File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/block_device.py", line 771, in attach wait_func=wait_func, image_id=self.image_id) File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/block_device.py", line 381, in _create_volume availability_zone=av_zone, Can any one advise on how to proceed ? Regards Tony Karera

1 0

[neutron] Secure RBAC api performance regression
by Slawek Kaplonski 29 Jan '21

29 Jan '21

Hi, In Neutron we are merging more and more patches related to the secure rbac policies [1]. Recently we noticed that our neutron-rally-task job is failing very often [2]. I did some tests and here is what were my results: * on latest neutron, with about 12 patches related to secure rbac merged - list of 4k ports took about 1m 40s: $ time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 1m41,644s user 0m0,926s sys 0m0,087s * same test with all those patches reverted - and it took 8 seconds: $ sudo systemctl restart devstack@q-svc; sleep 5; time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 0m8,131s user 0m0,907s sys 0m0,120s After a bit of digging I found out that most of the slowdown came from calls of the method self._handle_deprecated_rule(default) in [3]. When I commented that one line I had results same like without secure-rbac patches: $ sudo systemctl restart devstack@q-svc; sleep 5; time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 0m7,875s user 0m0,931s sys 0m0,087s @Lance, can You maybe take a look at it and help me understand if we are doing something wrong with those new rules in Neutron? Or maybe there is a bug in oslo_policy? [1] https://review.opendev.org/q/topic:secure-rbac+project:openstack/neutron [2] https://bugs.launchpad.net/neutron/+bug/1913718 [3] https://github.com/openstack/oslo.policy/blob/e103baa002e54303b08630c436dfc… -- Slawek Kaplonski Principal Software Engineer Red Hat

2 1

[tc][all] Encouraging projects to apply for tag 'assert:supports-api-interoperability'
by Ghanshyam Mann 29 Jan '21

29 Jan '21

Hello Everyone, TC defined a tag for API interoperability (cover both stable and compatible APIs) called 'assert:supports-api-interoperability' which assert on API won’t break any users when they upgrade a cloud or start using their code on a new OpenStack cloud. Basically, Projects will not change (or remove) an API in a way that will break existing users of an API. We have updated the tag documentation to clarify its definition and requirements. If your projects follow the API interoperability guidelines[1] and some API versioning mechanism that does not need to be microversion then you should start thinking to apply for this tag. The complete requirement can be found here[2]. Currently, only nova has this tag but I am sure many projects are eligible for this, and TC encourage them to apply for this. [1] https://specs.openstack.org/openstack/api-wg/guidelines/api_interoperabilit… [2] https://governance.openstack.org/tc/reference/tags/assert_supports-api-inte… -gmann

2 3

[Release-job-failures] os-collect-config 11.0.2 and tripleo-ipsec 9.3.1
by Thierry Carrez 29 Jan '21

29 Jan '21

We had two release jobs failures around TripleO and stable/ussuri: > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/cb4de2810bd147e2bf1cd98d6a1160fa : SUCCESS in 46s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/fb61c0814f114a2ea0c7298378e10e5f : FAILURE in 3m 07s > - announce-release https://zuul.opendev.org/t/openstack/build/None : SKIPPED > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/None : SKIPPED and > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/fad34ae84b9d4a8c982ca4f75c01f0c9 : SUCCESS in 58s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/0edc8da3c58842ed85b826f56153cde3 : FAILURE in 3m 25s > - announce-release https://zuul.opendev.org/t/openstack/build/None : SKIPPED > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/None : SKIPPED In both cases those jobs are coming from post-processing of release tags being pushed as a result of merging https://review.opendev.org/c/openstack/releases/+/772047 The error is that os-collect-config 11.0.0 and tripleo-ipsec 9.3.0 both did not have a stable/ussuri branch cut around ussuri release time at https://review.opendev.org/c/openstack/releases/+/728537 (probably escaped our watch as they are cycle-trailing). os-collect-config 11.0.1 was released on master about 3 months ago, which worked because 12.0.0 (victoria) was not cut yet. But now that victoria is cut, 11.0.2 (and tripleo-ipsec 9.3.1) triggered an error. ----11.0.0------11.0.1-------12.0.0/11.0.2/13.0.0-------master \ -----stable/victoria ----9.3.0------10.0.0/11.0.0/9.3.1-----master \ ----- stable/victoria Given that os-collect-config 12.0.0/11.0.2/13.0.0 are the same commit and tripleo-ipsec 10.0.0/11.0.0/9.3.1 are the same commit, this might be solved by just cutting stable/ussuri on that same commit and reenqueuing the tag references in Zuul to trigger the jobs. I proposed https://review.opendev.org/c/openstack/releases/+/772995 to that effect. -- Thierry Carrez (ttx)

2 1

[rdo][ussuri][tripleo] use rsyslog by default for all OSP components and send them to undercloud
by Ruslanas Gžibovskis 29 Jan '21

29 Jan '21

Hi all, I would like to configure, during deployment, all OSP services save logs over rsyslog, not directly writing to files. I know OSP services support such. In most cases, services/modules write into files directly. Is there any TripleO option to set it all to logging over system logger? Also is there possibility, to send logs to centralised server, into undercloud, if to be precise? From there I want to send it to elastic, using rsyslog or send it to other log parser/analyser/storage. Have anyone met such articles/howtos/docs I could refer to tweak my config? -- Ruslanas Gžibovskis +370 6030 7030

2 2

Ussuri Trove trovestack problem
by Diaz, Santiago Miguel 28 Jan '21

28 Jan '21

Hi. Im new in Openstack. When I try to create Trove guest image with the next command ./trovestack build-image mariadb ubuntu xenial true ubuntu exit 1 obtain. Reading the logs I found: 2021-01-28 13:30:13.217 | [error] The following package is needed by the script, but not installed: 2021-01-28 13:30:13.218 | apt-transport-https 2021-01-28 13:30:13.218 | Please install and rerun the script. I resolved it changing then next file: /trove/integration/scripts/files/elements/ubuntu-guest/pre-install.d/04-baseline-tools - apt-get --allow-unauthenticated install -y language-pack-en python-software-properties software-properties-common + apt-get --allow-unauthenticated install -y language-pack-en python-software-properties software-properties-common apt-transport-https I hope it helps AVISO LEGAL: El presente correo electrónico y la información contenida en el mismo, es información privada y confidencial, está dirigida únicamente a su destinatario y no puede ser revelada a terceros, ni utilizada inapropiadamente en interés del destinatario. Excepto que se haya establecido expresamente de otra forma, éste correo electrónico y la mencionada información privada y confidencial no constituye una oferta, ni una promesa, ni una propuesta y no será interpretado como aceptación, ni como una tratativa pre-contractual, acuerdo parcial, contrato preliminar y/o pre-contrato, ni como un compromiso vinculante y/o declaración de voluntad oficial de TELECOM ARGENTINA S.A. Si Usted no es el destinatario original de éste mensaje y por ese medio pudo acceder a dicha información, por favor, elimine el mensaje. La distribución o copia de este mensaje esta estrictamente prohibida. La transmisión de e-mails no garantiza que el correo electrónico sea seguro o libre de error. Por consiguiente, no manifestamos que esta información sea completa o precisa. Toda información está sujeta a alterarse sin previo aviso. This email and the information contained herein are proprietary and confidential, and intended for the recipient only and cannot be disclosed to third parties or used inappropriately in the interest of the recipient. Except it has been expressly stated otherwise, the email and said private and confidential information are not an offer or promise, or a proposal and will not be construed as acceptance or as a pre-contractual negotiation, partial agreement, preliminary contract and / or pre-contract or binding commitment and/or an official statement of intent of TELECOM ARGENTINA S.A. If you are not the intended recipient of this message and thereby gained access to such information, please remove the message. Distribution or copying of this message is strictly prohibited. Transmission of e-mails does not guarantee that e-mail is safe or free from error. Therefore, we do not represent that this information is complete or accurate. All information is subject to change without notice.

2 1

[kolla][mariadb] failed to start a cluster
by Tony Liu 28 Jan '21

28 Jan '21

Hi, When running kolla-ansible to deploy 3 controller nodes (Ussuri), mariadb on node-1 started fine, but when start mariadb on node-2 and node-3 to join node-1, node-1 became nodor/desync and node-2 and node-3 complained "Member 2.0 (os-control-2) requested state transfer from '*any*', but it is impossible to select State Transfer donor: Resource temporarily unavailable". Ansible failed at "RUNNING HANDLER [mariadb : Wait for MariaDB service port liveness]" when timeout. What could be wrong here? Thanks! Tony

1 0

[tripleo] next irc meeting Tuesday Feb 02 @ 1400 UTC in #tripleo
by Marios Andreou 28 Jan '21

28 Jan '21

Reminder that the next TripleO irc meeting is: ** Tuesday 02 February at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include recently completed things, ongoing review requests, blocking issues, or anything else tripleo you'd like to share. Our last meeting was on Jan 19 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-01-19-14.… Hope you can make it on Tuesday, thanks, marios

1 0

2020 Open Infrastructure Foundation Annual Report
by Kendall Nelson 28 Jan '21

28 Jan '21

Hello Everyone :) Despite being a very different year than most, the Open Infrastructure community, which has over 110,000 community members, made it a productive and successful year. One of the biggest milestones that happened in the global community last year was that OpenStack, one of the top three most active open source projects with 15 million cores in production, marked its 10th anniversary in 2020. The Open Infrastructure Foundation would like to extend a huge thanks to the global community for all of the work that went into 2020 and is continuing in 2021 to help people build and operate open infrastructure. Check out the OpenStack community’s achievements in 2020 from the OpenInfra Foundation Annual Report[1] and join us <https://openinfra.dev/join/> to build the next decade of open infrastructure! -Kendall Nelson (diablo_rojo) [1] https://www.openstack.org/annual-reports/2020-openstack-foundation-annual-r…

1 0

Integration tests failing on ppc64le master branch
by aditi Dukle 28 Jan '21

28 Jan '21

2 1

[all] Proposed Xena cycle schedule
by Herve Beraud 28 Jan '21

28 Jan '21

Hey everyone, The Wallaby cycle is going by fast, and it's already time to start planning some of the early things for the Xena release. One of the first steps for that is actually deciding on the release schedule. Typically we have done this based on when the next Summit event was planned to take place. Due to several reasons, we don't have a date yet for the second 2021 event. The current thinking is it will likely take place in October (nothing is set, just an educated guess, so please don't use that for any other planning). So for the sake of figuring out the release schedule, we are proposing two schedules, one targeting a release date in mid of september, one targeting a release date in early October. Hopefully this will then align well with event plans. I have two proposed release schedule up for review here: - https://review.opendev.org/c/openstack/releases/+/772367 (23w) - https://review.opendev.org/c/openstack/releases/+/772357 (25w) Please feel free to comment on the patch if you see any major issues that we may have not considered. 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-----

1 1

[neutron] Drivers meeting agenda - 29.01.2021
by Slawek Kaplonski 28 Jan '21

28 Jan '21

Hi, Agenda for tomorrow's drivers meeting is available at [1]. We have 2 things to discuss: * 1 RFE - [RFE] [QoS] add qos rule type packet per second (pps) [2] * 1 On demand topic - Do we want to apply for tag 'assert:supports-api-interoperability' - see [3] for details. See You tomorrow on the meeting. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda [2] https://bugs.launchpad.net/neutron/+bug/1912460 [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019505… -- Slawek Kaplonski Principal Software Engineer Red Hat

2 2

Re: [Release-job-failures] Release of openstack/monasca-tempest-plugin for ref refs/tags/2.2.0 failed
by Herve Beraud 28 Jan '21

28 Jan '21

Hello monasca team, FYI a release failure happened on monasca-tempest-plugin within the job publish-monasca-tempest-plugin-docker-image. This build was triggered by https://review.opendev.org/c/openstack/releases/+/768551 (the Wallaby part). A new incompatibility in requirements was found by pip's new resolver: > pykafka 2.8.0 has requirement kazoo==2.5.0, but you'll have kazoo 2.8.0 which is incompatible. (c.f https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa… ) I didn't find a trace of these requirements on your repo so I think they are pulled/resolved from/for underlying libraries. After that the job fails to push the "latest" docker tag because the tag is not found, I think it's a side effect of the previous error. (c.f https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa… ) Let us know if we can help you, The Release Team. Le lun. 18 janv. 2021 à 23:31, <zuul(a)openstack.org> a écrit : > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/8dd9a4fce3bc4ae2a32134b7d7fec5b5 > : SUCCESS in 52s > - release-openstack-python > https://zuul.opendev.org/t/openstack/build/ff7c8136563444df9c565f07f618c559 > : SUCCESS in 3m 44s > - announce-release > https://zuul.opendev.org/t/openstack/build/78731c6e0948490d82e1e2d14eb67857 > : SUCCESS in 3m 42s > - propose-update-constraints > https://zuul.opendev.org/t/openstack/build/3eab7a3209a84a33b8d7b69e41e185cb > : SUCCESS in 2m 49s > - publish-monasca-tempest-plugin-docker-image > https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa > : POST_FAILURE in 8m 19s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- 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-----

4 5