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

[tripleo][ci] ussuri promoted, mirrors not synced yet..
by Wesley Hayutin 14 Jul '21

14 Jul '21

FYI.. Jobs running against ussuri or victoria-upgrade jobs may fail atm. The branch promoted and the mirrors are not yet synced up. Some details: http://paste.openstack.org/show/807451/

1 0

Re: [devstack][neutron][manila] Instances having trouble getting to external network with OVN
by Simon Dodsley 13 Jul '21

13 Jul '21

To follow on from this. This is a link to an example CI failure: http://openstack-logs.purestorage.com/84/789384/25/thirdparty-check/pure-de… Thanks Simon | *Simon Dodsley MBCS CITP* | Technical Director, New Stack | Global Cloud Architecture Organization | Pure Storage, Inc. | +1 (510) 516-2682 | simon(a)purestorage.com | www.purestorage.com *BOOK TIME WITH ME*: 30 minutes <https://purestorage.chilipiper.com/book/me/simon-dodsley?type=my-meeting> [image: http://www.purestorage.com/_media/header_logo.png?130529]

1 0

review.opendev.org server upgrade 18/19th July 2021
by Ian Wienand 13 Jul '21

13 Jul '21

Hello, Around 2021-07-18 23:00 UTC we plan to provision an upgrade to the review.opendev.org server which hosts our Gerrit instance. We are aware that some users may require firewall updates or similar to access the new server. The new addresses will be: 199.204.45.33 2604:e100:1:0:f816:3eff:fe52:22de We hope the downtime will be limited to a few hours as we migrate and index the data. User-visible changes be should minimal. Due to incompatible schemas between the old hosted database and new database instance we will not be transitioning the table that holds the information about what files you have reviewed (gerrit shows a light-grey "Reviewed" when you have viewed a file). Note this is *not* review comments or code, but just the per-user flag in the UI if you have viewed a file. You can reach admins via email at service-discuss(a)lists.opendev.org or in OFTC #opendev for any further questions or queries. Thank you, -i

1 1

[glance] Yoga PTG Planning
by Abhishek Kekane 13 Jul '21

13 Jul '21

Hello Everyone!!! As you are already aware that Yoga virtual PTG will be held between October 18th to 22nd [1]. Please use below etherpad to add the topics you would like to discuss during PTG. https://etherpad.opendev.org/p/yoga-ptg-glance-planning [1] https://www.eventbrite.com/e/project-teams-gathering-october-2021-tickets-1… Thanks & Best Regards, Abhishek Kekane

1 0

[cinder] yoga virtual PTG timeslots
by Brian Rosmaita 13 Jul '21

13 Jul '21

Hello Cinder team and anyone interested in Cinder development, It's time to determine when we will be meeting for the Yoga PTG, which takes place 18-22 October. We are asked to schedule within the following 3 blocks of 4 hours each: - 14:00-08:00 UTC - 13:00-17:00 UTC - 21:00-01:00 UTC with the following constraints: - no project should schedule more than 4 hours in a single day - no project should schedule more than 16 hours over the entire PTG Given the current cinder-core team's distribution across time zones, it looks to me like the best bet is to use (as we have for the past few Virtual PTGs) the 13:00-17:00 UTC time slot. So I propose that the cinder team meet 13:00-17:00 UTC on the four days Tuesday 19 October through Friday 22 October 2021. We'll schedule topics from 13:00-16:00 UTC, with 16:00-17:00 available for slack space for discussion overruns or happy hour. Take a look at this etherpad to see how the time slots fall across cinder contributor time zones: https://etherpad.opendev.org/p/yoga-ptg-cinder-timeslots If you have a topic you want to discuss at the PTG and the proposed timeslots do not work for you, please contact me immediately and let me know both (a) what you want to discuss, and (b) what timeslot you propose, and I'll try to work something out (which could include a post-PTG video meeting when we're not constrained by the PTG time blocks). By "immediately" I mean "before Monday 19 July at 12:00 UTC". cheers, brian

1 0

[nova][stable] Adding nova-core to nova stable branches
by Stephen Finucane 13 Jul '21

13 Jul '21

Happy Friday (again), Following on from my earlier email regarding os-vif stable branch permissions, I'd like to once again propose that we add nova-core to the list of teams with +2 rights on nova stable branches. Unlike the os-vif change, this has been discussed extensively in the past, most recently during the Victoria PTG [1] (search for "Can we add nova-core to nova-stable-maint") and therefore carries a little more baggage with it. Last time we discussed this, there were concerns from some existing stable cores that not all of nova-core were sufficiently well acquainted with stable branch policy and it was suggested that review velocity was sufficient. However, the stable team has remained pretty stable (heh) over the last couple of cycles and is staffed with developers with ample experience of both nova itself and the backport policies of nova and OpenStack as a whole. In addition, we continue to have a long tail of open stable reviews [2] from various people. The stable branches are increasingly important for users and organizations alike, and a faster, smoother backport policy encourages people to have an upstream-first mentality when it comes to maintaining a product built on these branches. The alternative is to handle these backports in a downstream-first or downstream- only manner, which results in duplication of effort and, over the long-term, potential difficulties keeping downstream and upstream in-sync. I think the time has long since passed where we should remove the artificial barrier that exists here. I expect all nova cores will have the maturity and sensibility to ask questions where uncertainty exists and only approve backports that they are confident and knowledgeable about. I do not expect existing stable cores will be sidelined either. Far from it, in fact. Existing stable cores will continue to be valuable both for their reviews and knowledge of the intricacies of stable policy. I proposed a waiting period of one week before making changes to os-vif permissions, but given the history around changes to nova stable core, I think we would benefit from some additional time to assuage any concerns that may still exist. I propose that we come to a decision by 09-Aug, or two weeks from now. If necessary, we can discuss this in real-time during the nova team meeting next Tuesday. Cheers, Stephen [1] https://etherpad.opendev.org/p/nova-victoria-ptg [2] https://review.opendev.org/q/project:openstack/nova+NOT+branch:master+is:op…

2 2

[cinder] festival of XS reviews 16 July 2021
by Brian Rosmaita 13 Jul '21

13 Jul '21

Hello Cinder community members, This is a reminder that the most recent edition of the Cinder Festival of XS Reviews will be held at the end of this week on Friday 16 July. who: Everyone! what: The Cinder Festival of XS Reviews when: Friday 16 July 2021 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews This recurring meeting can be placed on your calendar by using this handy ICS file: http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics See you there! brian

1 0

How to use masked_set_action?
by taoyunupt 13 Jul '21

13 Jul '21

Hi, I found some info from vswitch.xml，it says "Masked data can improve performance by allowing megaflows to match on fewer fields." I do not know What kinds of flow atcion will use 'masked_set_action'. Can you give some demo flows and situation？ Thanks, YUN

1 0

[oslo] next meeting (July 19) canceled - PTO
by Herve Beraud 13 Jul '21

13 Jul '21

Hello Osloers, I'll be on PTO during the next 2 weeks, from July 19 to August 2, so I won't be around to run our meetings. If someone else is a volunteer to lead the meeting then feel free to run it. Thanks for your understanding. See you soon. -- 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 0

[neutron] WSREP: referenced FK check fail: Lock wait index
by Michal Arbet 13 Jul '21

13 Jul '21

Hi, I have wallaby deployed via kolla-ansible and from time to time see this in mariadb log while i'm running tempest tests against wallaby: /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:09:17 838 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:10:02 841 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:10:13 836 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:10:37 841 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:13:29 813 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:13:37 854 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:16:45 845 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:25:41 838 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`portsecuritybindings` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:26:30 838 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:27:14 827 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:27:38 866 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:28:28 846 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:29:27 840 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` /var/log/kolla/mariadb/mariadb.log:2021-07-13 9:43:39 842 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` I found some info in openstack-discuss below : http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014928.html So, it seems it is mariadb issue, but it should be fixed in version which I am using root@controller0:/home/ubuntu# docker exec -itu root mariadb bash (mariadb)[root@controller0 /]# dpkg -l | grep mariadb ii libmariadb3:amd64 1:10.5.10-2 amd64 MariaDB database client library ii mariadb-backup 1:10.5.10-2 amd64 Backup tool for MariaDB server ii mariadb-client 1:10.5.10-2 all MariaDB database client (metapackage depending on the latest version) ii mariadb-client-10.5 1:10.5.10-2 amd64 MariaDB database client binaries ii mariadb-client-core-10.5 1:10.5.10-2 amd64 MariaDB database core client binaries ii mariadb-common 1:10.5.10-2 all MariaDB common configuration files ii mariadb-server 1:10.5.10-2 all MariaDB database server (metapackage depending on the latest version) ii mariadb-server-10.5 1:10.5.10-2 amd64 MariaDB database server binaries ii mariadb-server-core-10.5 1:10.5.10-2 amd64 MariaDB database core server files So, is it really mariadb issue or neutron ? No similar log from other services in mariadb log. Thanks, Michal Arbet (kevko) Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet(a)ultimum.io *https://ultimum.io <https://ultimum.io/>* LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>

1 0