- openstack-discuss - lists.openstack.org

[qa] Proposing Martin Kopec to Tempest core
by Ghanshyam Mann 06 Apr '20

06 Apr '20

Hello Everyone, Martin Kopec (IRC: kopecmartin) has been doing great contribution in Tempest since a long time. He has been doing bugs Triage also in Ussuri cycle and has good understanding of Tempest. I would like to propose him for Tempest Core. You can vote/feedback on this email. If no objection by the end of this week, I will add him to the list. -gmann

9 9

New OpenDev Communication Channels
by Clark Boylan 06 Apr '20

06 Apr '20

Hello All, Recently, we've transitioned to using #opendev on Freenode for our synchronous IRC communications. Since then we've spun up a new service-discuss(a)lists.opendev.org mailing list [1] where we'll plan changes to services, notify of meetings, answer questions about services and usage, and otherwise communicate about OpenDev. service-announce(a)lists.opendev.org [2] will remain for important announcements. If you're interested in the developer infrastructure we run please join us on these mailing lists. We encourage every developer to at least subscribe to the service-announce[2] list. It will be very low traffic, and used only for important announcements with wide impact. We are also going to start having our weekly team meeting in #opendev-meeting. The time will continue to be 19:00 UTC Tuesdays. See you there, Clark [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-discuss [2] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce

2 2

[all] OSF Community Meeting Presentation & Recordings
by Allison Price 06 Apr '20

06 Apr '20

Hi everyone, Thank you to those who attended any of the community meetings last week! If you missed one of the calls last week, below are links to the presentation [1], recording in English [2], and recording in Mandarin [3]. A lot of links were discussed and you can find those in the meeting section of the notes as well as the chat from the recordings. We are planning to do this format with project and community updates and OSF event updates quarterly. Stay tuned for the next meeting, and let me know if you have any questions in the meantime. In addition to the quarterly meetings, we would like to hear from the project communities on topics you would like to cover in community meetings or have covered. If you have an idea you would like to share, please drop it in this etherpad [4]. If you see a topic already shared that you would like to collaborate on, please share your name, email and IRC nick next to the topic. Cheers, Allison [1] https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY… <https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY…> [2] https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb… <https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb…> [3] https://zoom.us/rec/share/zudNaIrQ6mNLR9Lvr2Xxf5QQIL7geaa8hCcf_vsIxEwoHkn0b… <https://zoom.us/rec/share/zudNaIrQ6mNLR9Lvr2Xxf5QQIL7geaa8hCcf_vsIxEwoHkn0b…> [4] https://etherpad.openstack.org/p/OSF_Community_Meetings <https://etherpad.openstack.org/p/OSF_Community_Meetings> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[release][oslo] FFE request for Oslo
by Ben Nemec 06 Apr '20

06 Apr '20

Like, all of it. :-) Okay, _most_ of it. Specifically the projects in https://review.opendev.org/#/c/717816/ These all had changes in them which normally don't require release, like doc and test changes. However, if we don't release them before the stable branches are cut, the stable branches won't include any of those doc and test changes. This means the docs will be out of date, and tests may break completely (it would not be the first time). We could backport, but there are kind of a lot of patches involved so it would be much easier to just do some trivial releases now and not have to mess with it later. Apologies for dropping the ball on this since it should have been proposed last week, but I hope you will take pity on me and grant an FFE to undo my mistake. :-) Thanks. -Ben

2 1

[neutron] Bug deputy report for week of March 30th
by Brian Haley 06 Apr '20

06 Apr '20

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1869862 - neutron-tempest-plugin-designate-scenario failes frequently with imageservice doesn't have supported version - https://review.opendev.org/#/c/715835/ merged (devstack issue) * https://bugs.launchpad.net/neutron/+bug/1870110 - neutron-rally-task fails in rally_openstack.task.scenarios.neutron.trunk.CreateAndListTrunks - https://review.opendev.org/#/c/716562/ proposed - revert of https://review.opendev.org/#/c/477286/ * https://bugs.launchpad.net/neutron/+bug/1870302 - [VPNaaS]: test_migrations_sync failed with alembic 1.4.2 - gate failure for vpnaas - Dongcan Ye took ownership High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1869887 - L3 DVR ARP population gets incorrect MAC address in some cases - https://review.opendev.org/#/c/716302/ proposed * https://bugs.launchpad.net/neutron/+bug/1870313 - "send_ip_addr_adv_notif" can't use eventlet when called from "keepalived_state_change" - https://review.opendev.org/#/c/716944/ proposed * https://bugs.launchpad.net/neutron/+bug/1870352 - "ctypes.CDLL" C functions could release the GIL during the execution call - https://review.opendev.org/#/c/717017/ proposed * https://bugs.launchpad.net/neutron/+bug/1870569 - Unable to create network without default network_segment_range - Possible regression - https://review.opendev.org/#/c/717754/ proposed Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1870114 - Trunk subports aren't treated as dvr serviced ports - https://review.opendev.org/#/c/716642/ proposed * https://bugs.launchpad.net/neutron/+bug/1870228 - cloud-init metadata fallback broken - https://review.opendev.org/#/c/600421/ changed the bind address - asked if using the metadata "force" config option will help * https://bugs.launchpad.net/bugs/1870296 - [neutron-tempest-plugin]:fwaas Operation cannot be performed since associated firewall group is in PENDING UPDATE - https://review.opendev.org/716891 proposed * https://bugs.launchpad.net/neutron/+bug/1870400 - "ml2_vlan_allocations.vlan_id" value should be checked in the DB backend - https://review.opendev.org/#/c/717083/ proposed Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1869808 - reboot neutron-ovs-agent introduces a short interrupt of vlan traffic - asked if it could be reproduced on a later release Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1869877 - Segment doesn't exist network info - https://review.opendev.org/#/c/716275/ proposed (nova) - https://review.opendev.org/#/c/715156/ proposed (neutron) * https://bugs.launchpad.net/neutron/+bug/1870319 - [RFE] Network cascade deletion API call - Slawek already added rfe-triaged tag Invalid bugs ------------ * https://bugs.launchpad.net/neutron/+bug/1869768 - devstack failed when Q_AGENT=ovn - Could not reproduce, suspect invalid local.conf * https://bugs.launchpad.net/neutron/+bug/1870002 - The operating_status value of loadbalancer is abnormal - LBaaS bug, moved to storyboard Further triage required ----------------------- * None

1 0

[ironic] Next weekly meeting canceled (April 13th)
by Iury Gregory 06 Apr '20

06 Apr '20

Hello Ironicers, During our weekly meeting today, we decided to cancel the next weekly meeting (April 13th), since it's a holiday for most of the contributors. Best regards, -- *Att[]'sIury Gregory Melo Ferreira **Software Engineer at Red Hat Czech* *MSc in Computer Science at UFCG* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[openstack-ansible] Retirement of repo_build and pip_install roles
by Dmitriy Rabotyagov 06 Apr '20

06 Apr '20

4 3

[monasca][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello monasca team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - monasca-thresh - monasca-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----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

[manila][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello manila team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - manila-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----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

[magnum][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello magnum team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - magnum-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----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

[heat][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello heat team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - heat-agents Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----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

[cloudkitty][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello cloudkitty team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - cloudkitty Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----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

[barbican][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello barbican team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - barbican-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----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

[tc][zaqar]Wanna be the PTL of Zaqar project to help in V
by hao wang 04 Apr '20

04 Apr '20

Hi, all TC members I'm Wang Hao, be the Zaqar PTL since 2018. So sorry I missed the community vote for projects. But I still really want to be the Zaqar PTL in V to push this interesting project forward. Indeed, the contribution to Zaqar project has declined for a while. But there're still some projects that have dependencies on it like tripleo, heat, and manila, etc. and AFAIK, some Chinese cloud companies also use Zaqar as messaging service. If Zaqar is removed from core projects, it will have adverse impacts on those projects and companies. Also, we still have blueprints and list of works that should be implemented in V cycle. Finally, as a contributor in Zaqar since 2016, I really want to help this project going forward. Thank you!

2 1

[release] Release countdown for week R-5, April 6 - 10
by Sean McGinnis 03 Apr '20

03 Apr '20

Development Focus ----------------- We are getting close to the end of the Ussuri cycle! Next week on April 9 is the ussuri-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the Ussuri cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on April 9. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/ussuri branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/…) April 9 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be approved by the team PTL. Finally, feature freeze is also the deadline for submitting a first version of your cycle-highlights. Cycle highlights are the raw data hat helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Ussuri-3 milestone (feature freeze): April 9 (R-5 week) Cycle Highlights Due: April 9 (R-5 week) RC1 deadline: April 23 (R-3 week) Final RC deadline: May 7 (R-1 week) Final Ussuri release: May 13

1 0

[packaging] New package: ovn-octavia-provider
by Maciej Jozefczyk 03 Apr '20

03 Apr '20

Hello, During this cycle Neutron team merged networking-ovn code to Neutron [1]. As a consequence of it we needed to create a new project called: "OVN Octavia provider", which is a provider driver for Octavia. Before it the driver was placed in networking-ovn tree. Neutron cannot rely on Octavia-lib, so that is why this decision was made. The code move process to Neutron took some time and we released the OVN Octavia provider driver yesterday - under version 0.1.0. [2]. If you're working on distro packaging - please be aware that the driver is now delivered by a new package. RPM spec in RDO is ongoing: [3]. We are sorry for this late announcement. [1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge [2] https://review.opendev.org/#/c/710200/ [3] https://review.rdoproject.org/r/#/c/25972/ -- Best regards, Maciej Józefczyk

2 1

【octavia】Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem
by hao7.liu＠midea.com 02 Apr '20

02 Apr '20

OS version：CentOS7.6 openstack version：Train when i deployed my openstack with octavia，and create a lb，the worker report error logs： 2020-04-01 14:40:41.842 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'MASTER-octavia-create-amp-for-lb-subflow-octavia-generate-serverpem' (7abe1523-7802-48ad-a7c1-1d2f8f32f706) transitioned into state 'RUNNING' from state 'PENDING' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:41.865 164881 INFO octavia.controller.worker.v1.tasks.database_tasks [-] Created Amphora in DB with id 191958e3-2577-4a8a-a1ff-b8f048056b72 2020-04-01 14:40:41.869 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-create-amp-for-lb-subflow-octavia-create-amphora-indb' (667607d7-6357-4bac-a498-725c370a2b34) transitioned into state 'SUCCESS' from state 'RUNNING' with result '191958e3-2577-4a8a-a1ff-b8f048056b72' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:183 2020-04-01 14:40:41.874 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-create-amp-for-lb-subflow-octavia-generate-serverpem' (7f312151-6f92-4ae7-9826-0fccc315ba43) transitioned into state 'RUNNING' from state 'PENDING' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:41.927 164881 INFO octavia.certificates.generator.local [-] Signing a certificate request using OpenSSL locally. 2020-04-01 14:40:41.927 164881 INFO octavia.certificates.generator.local [-] Using CA Certificate from config. 2020-04-01 14:40:41.946 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-create-amp-for-lb-subflow-octavia-generate-serverpem' (7f312151-6f92-4ae7-9826-0fccc315ba43) transitioned into state 'FAILURE' from state 'RUNNING' 13 predecessors (most recent first): Atom 'BACKUP-octavia-create-amp-for-lb-subflow-octavia-create-amphora-indb' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {}, 'provides': u'191958e3-2577-4a8a-a1ff-b8f048056b72'} |__Flow 'BACKUP-octavia-create-amp-for-lb-subflow' |__Atom 'BACKUP-octavia-get-amphora-for-lb-subflow-octavia-mapload-balancer-to-amphora' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'flavor': {u'loadbalancer_topology': u'ACTIVE_STANDBY'}, 'loadbalancer_id': u'd7ca9fb7-eda3-4a17-a615-c6d7f31d32d8'}, 'provides': None} |__Flow 'BACKUP-octavia-get-amphora-for-lb-subflow' |__Flow 'BACKUP-octavia-plug-net-subflow' |__Flow 'octavia-create-loadbalancer-flow' |__Atom 'octavia.controller.worker.v1.tasks.network_tasks.GetSubnetFromVIP' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer': <octavia.common.data_models.LoadBalancer object at 0x7f93312afd90>}, 'provides': <octavia.network.data_models.Subnet object at 0x7f93312af550>} |__Atom 'octavia.controller.worker.v1.tasks.network_tasks.UpdateVIPSecurityGroup' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer': <octavia.common.data_models.LoadBalancer object at 0x7f93312afd90>}, 'provides': None} |__Atom 'octavia.controller.worker.v1.tasks.database_tasks.UpdateVIPAfterAllocation' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'vip': <octavia.common.data_models.Vip object at 0x7f9331b253d0>, 'loadbalancer_id': u'd7ca9fb7-eda3-4a17-a615-c6d7f31d32d8'}, 'provides': <octavia.common.data_models.LoadBalancer object at 0x7f93312afd90>} |__Atom 'octavia.controller.worker.v1.tasks.network_tasks.AllocateVIP' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer': <octavia.common.data_models.LoadBalancer object at 0x7f9332b66290>}, 'provides': <octavia.common.data_models.Vip object at 0x7f9331b253d0>} |__Atom 'reload-lb-before-allocate-vip' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer_id': u'd7ca9fb7-eda3-4a17-a615-c6d7f31d32d8'}, 'provides': <octavia.common.data_models.LoadBalancer object at 0x7f9332b66290>} |__Atom 'octavia.controller.worker.v1.tasks.lifecycle_tasks.LoadBalancerIDToErrorOnRevertTask' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer_id': u'd7ca9fb7-eda3-4a17-a615-c6d7f31d32d8'}, 'provides': None} |__Flow 'octavia-create-loadbalancer-flow': CertificateGenerationException: Could not sign the certificate request: Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem. 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker Traceback (most recent call last): 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker result = task.execute(**arguments) 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/octavia/controller/worker/v1/tasks/cert_task.py", line 47, in execute 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker validity=CONF.certificates.cert_validity_time) 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/octavia/certificates/generator/local.py", line 234, in generate_cert_key_pair 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker cert = cls.sign_cert(csr, validity, **kwargs) 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/octavia/certificates/generator/local.py", line 91, in sign_cert 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker cls._validate_cert(ca_cert, ca_key, ca_key_pass) 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/octavia/certificates/generator/local.py", line 53, in _validate_cert 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker .format(CONF.certificates.ca_certificate) 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker CertificateGenerationException: Could not sign the certificate request: Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem. 2020-04-01 14:40:41.946 164881 ERROR octavia.controller.worker.v1.controller_worker 2020-04-01 14:40:41.969 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-create-amp-for-lb-subflow-octavia-generate-serverpem' (7f312151-6f92-4ae7-9826-0fccc315ba43) transitioned into state 'REVERTING' from state 'FAILURE' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:41.972 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-create-amp-for-lb-subflow-octavia-generate-serverpem' (7f312151-6f92-4ae7-9826-0fccc315ba43) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:41.975 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-create-amp-for-lb-subflow-octavia-create-amphora-indb' (667607d7-6357-4bac-a498-725c370a2b34) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:41.975 164881 WARNING octavia.controller.worker.v1.tasks.database_tasks [-] Reverting create amphora in DB for amp id 191958e3-2577-4a8a-a1ff-b8f048056b72 2020-04-01 14:40:41.992 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-create-amp-for-lb-subflow-octavia-create-amphora-indb' (667607d7-6357-4bac-a498-725c370a2b34) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:41.995 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-get-amphora-for-lb-subflow-octavia-mapload-balancer-to-amphora' (97f157c5-8b35-476d-a3d9-586087ecf235) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:41.996 164881 WARNING octavia.controller.worker.v1.tasks.database_tasks [-] Reverting Amphora allocation for the load balancer d7ca9fb7-eda3-4a17-a615-c6d7f31d32d8 in the database. 2020-04-01 14:40:42.003 164881 INFO octavia.certificates.generator.local [-] Signing a certificate request using OpenSSL locally. 2020-04-01 14:40:42.003 164881 INFO octavia.certificates.generator.local [-] Using CA Certificate from config. 2020-04-01 14:40:42.005 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'BACKUP-octavia-get-amphora-for-lb-subflow-octavia-mapload-balancer-to-amphora' (97f157c5-8b35-476d-a3d9-586087ecf235) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:42.006 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'MASTER-octavia-create-amp-for-lb-subflow-octavia-generate-serverpem' (7abe1523-7802-48ad-a7c1-1d2f8f32f706) transitioned into state 'FAILURE' from state 'RUNNING': CertificateGenerationException: Could not sign the certificate request: Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem. 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker Traceback (most recent call last): 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker result = task.execute(**arguments) 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/octavia/controller/worker/v1/tasks/cert_task.py", line 47, in execute 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker validity=CONF.certificates.cert_validity_time) 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/octavia/certificates/generator/local.py", line 234, in generate_cert_key_pair 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker cert = cls.sign_cert(csr, validity, **kwargs) 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/octavia/certificates/generator/local.py", line 91, in sign_cert 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker cls._validate_cert(ca_cert, ca_key, ca_key_pass) 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python2.7/site-packages/octavia/certificates/generator/local.py", line 53, in _validate_cert 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker .format(CONF.certificates.ca_certificate) 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker CertificateGenerationException: Could not sign the certificate request: Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem. 2020-04-01 14:40:42.006 164881 ERROR octavia.controller.worker.v1.controller_worker 2020-04-01 14:40:42.013 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'MASTER-octavia-create-amp-for-lb-subflow-octavia-generate-serverpem' (7abe1523-7802-48ad-a7c1-1d2f8f32f706) transitioned into state 'REVERTING' from state 'FAILURE' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:42.014 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'MASTER-octavia-create-amp-for-lb-subflow-octavia-generate-serverpem' (7abe1523-7802-48ad-a7c1-1d2f8f32f706) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:42.017 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'MASTER-octavia-create-amp-for-lb-subflow-octavia-create-amphora-indb' (145e3ecd-816e-415e-90a4-b7b09ca09c60) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:42.018 164881 WARNING octavia.controller.worker.v1.tasks.database_tasks [-] Reverting create amphora in DB for amp id 1ecbc19a-2644-4f3a-a9fc-bf6ace1655e3 2020-04-01 14:40:42.034 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'MASTER-octavia-create-amp-for-lb-subflow-octavia-create-amphora-indb' (145e3ecd-816e-415e-90a4-b7b09ca09c60) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:42.038 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'MASTER-octavia-get-amphora-for-lb-subflow-octavia-mapload-balancer-to-amphora' (a17713f7-52df-4d3b-8cd2-5e592ce29a6a) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:42.038 164881 WARNING octavia.controller.worker.v1.tasks.database_tasks [-] Reverting Amphora allocation for the load balancer d7ca9fb7-eda3-4a17-a615-c6d7f31d32d8 in the database. 2020-04-01 14:40:42.047 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'MASTER-octavia-get-amphora-for-lb-subflow-octavia-mapload-balancer-to-amphora' (a17713f7-52df-4d3b-8cd2-5e592ce29a6a) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:42.052 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.network_tasks.GetSubnetFromVIP' (b6e38bf6-57d3-4b99-8226-486e16606d72) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:42.054 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.network_tasks.GetSubnetFromVIP' (b6e38bf6-57d3-4b99-8226-486e16606d72) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:42.059 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.network_tasks.UpdateVIPSecurityGroup' (47efda4a-4ab4-4618-ae0d-f0d145ca75b0) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:42.062 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.network_tasks.UpdateVIPSecurityGroup' (47efda4a-4ab4-4618-ae0d-f0d145ca75b0) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:42.066 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.database_tasks.UpdateVIPAfterAllocation' (e24fb53e-195e-401d-b300-a798503d1f97) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:42.068 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.database_tasks.UpdateVIPAfterAllocation' (e24fb53e-195e-401d-b300-a798503d1f97) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:42.073 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.network_tasks.AllocateVIP' (11bbd801-d889-4499-ab7d-768d81153939) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:42.073 164881 WARNING octavia.controller.worker.v1.tasks.network_tasks [-] Deallocating vip 172.20.250.184 2020-04-01 14:40:42.199 164881 INFO octavia.network.drivers.neutron.allowed_address_pairs [-] Removing security group b2430a12-2c07-4ca9-a381-3af79f702715 from port a52f2cfa-765b-4664-b4ad-c2a11dd870de 2020-04-01 14:40:43.189 164881 INFO octavia.network.drivers.neutron.allowed_address_pairs [-] Deleted security group b2430a12-2c07-4ca9-a381-3af79f702715 2020-04-01 14:40:43.994 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.network_tasks.AllocateVIP' (11bbd801-d889-4499-ab7d-768d81153939) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:43.999 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'reload-lb-before-allocate-vip' (01c2a7f3-9114-41f3-a2c0-42601b2b48f0) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:44.002 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'reload-lb-before-allocate-vip' (01c2a7f3-9114-41f3-a2c0-42601b2b48f0) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:44.007 164881 DEBUG octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.lifecycle_tasks.LoadBalancerIDToErrorOnRevertTask' (2339e5d5-e545-4f1d-9147-4f5a7b2f9ce9) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /usr/lib/python2.7/site-packages/taskflow/listeners/logging.py:194 2020-04-01 14:40:44.017 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'octavia.controller.worker.v1.tasks.lifecycle_tasks.LoadBalancerIDToErrorOnRevertTask' (2339e5d5-e545-4f1d-9147-4f5a7b2f9ce9) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2020-04-01 14:40:44.028 164881 WARNING octavia.controller.worker.v1.controller_worker [-] Flow 'octavia-create-loadbalancer-flow' (aab75b85-a8f1-486f-99e8-5c81e21aa3f3) transitioned into state 'REVERTED' from state 'RUNNING' 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server [-] Exception during message handling: WrappedFailure: WrappedFailure: [Failure: octavia.common.exceptions.CertificateGenerationException: Could not sign the certificate request: Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem., Failure: octavia.common.exceptions.CertificateGenerationException: Could not sign the certificate request: Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem.] 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 274, in dispatch 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/octavia/controller/queue/v1/endpoints.py", line 45, in create_load_balancer 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server self.worker.create_load_balancer(load_balancer_id, flavor) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 292, in wrapped_f 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server return self.call(f, *args, **kw) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 358, in call 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server do = self.iter(retry_state=retry_state) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 319, in iter 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server return fut.result() 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/concurrent/futures/_base.py", line 422, in result 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server return self.__get_result() 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 361, in call 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server result = fn(*args, **kwargs) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/octavia/controller/worker/v1/controller_worker.py", line 344, in create_load_balancer 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server create_lb_tf.run() 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 247, in run 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server for _state in self.run_iter(timeout=timeout): 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 340, in run_iter 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server failure.Failure.reraise_if_any(er_failures) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/taskflow/types/failure.py", line 341, in reraise_if_any 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server raise exc.WrappedFailure(failures) 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server WrappedFailure: WrappedFailure: [Failure: octavia.common.exceptions.CertificateGenerationException: Could not sign the certificate request: Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem., Failure: octavia.common.exceptions.CertificateGenerationException: Could not sign the certificate request: Failed to load CA Certificate /etc/octavia/certs/server_ca.cert.pem.] 2020-04-01 14:40:44.029 164881 ERROR oslo_messaging.rpc.server hao7.liu(a)midea.com

3 5

[neutron] Drivers meeting - agenda
by Slawek Kaplonski 02 Apr '20

02 Apr '20

Hi, I though that it may be useful for You if I will send earlier agenda for next drivers meeting to You. That You will have some time to go through RFEs which are planned to be discussed on our next meeting. For 3.04.2020 I have 3 RFEs to discuss: * https://bugs.launchpad.net/neutron/+bug/1592028 - [RFE] Support security-group-rule creation with address-groups * https://bugs.launchpad.net/neutron/+bug/1869129 - neutron accepts CIDR in security groups that are invalid in ovn - this was reported as issue in ovn but it seems that this may be potentially security issue which will require changes in API to fix, Already proposed patch https://review.opendev.org/#/c/716806/ * https://bugs.launchpad.net/neutron/+bug/1870319 - [RFE] Network cascade deletion API call See You tomorrow on drivers meeting. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[election][cloudkitty][ptl] Announcing my PTL candidacy for CloudKitty (Justin Ferrieu)
by Justin Ferrieu 02 Apr '20

02 Apr '20

Hi all, I would like to nominate myself to be the CloudKitty PTL for the Victoria cycle. The project is quite stable now and just needs an overall maintenance and to meet the community goals. I feel ready to do that. Thank you a lot. Best regards, ---- Justin Ferrieu Mail : justin.ferrieu(a)objectif-libre.com Consultant Cloud Objectif Libre URL : www.objectif-libre.com [1] Au service de votre Cloud Twitter : @objectiflibre Suivez les actualités OpenStack en français en vous abonnant à la Pause OpenStack http://olib.re/pause-openstack Links: ------ [1] http://www.objectif-libre.com

2 1

Fwd: OpenStack Foundation Community Meetings
by Allison Price 02 Apr '20

02 Apr '20

Hi everyone - In case you didn’t see the post on the Foundation mailing list, we have a community meeting tomorrow where we will be talking about updates to OSF events as well as project updates and how you can get involved in the 10th year of OpenStack campaign. One meeting will be in English and one in Mandarin. Bring your questions and see you then! Cheers, Allison > Begin forwarded message: > > From: Allison Price <allison(a)openstack.org> > Subject: OpenStack Foundation Community Meetings > Date: March 26, 2020 at 10:21:15 AM CDT > To: foundation(a)lists.openstack.org > > Hi everyone, > > Next week we are going to have two community meetings to discuss the OpenStack 10th anniversary planning, current community projects, and an update on OSF events. Please join if you would like to hear updates or if you have questions for the OpenStack Foundation team. > > Join us: > Thursday, April 2 at 10am CT / 1500 UTC <https://zoom.us/j/913456204> > Friday, April 3 in Mandarin at 10am China Standard Time <https://zoom.us/j/389363434> > > If you are unable to join one of the above times, I will share a recording to the mailing list after the meetings. > > Cheers, > Allison > > > Allison Price > OpenStack Foundation > allison(a)openstack.org <mailto:allison@openstack.org> > > > >

2 4

Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
by Ilya Etingof 02 Apr '20

02 Apr '20

> So I think we need to dig deeper in the strategy for Ironic, the > adoption obstacles we are trying to remove, and discuss the options. > Being set up as a separate top-level project is one option. But I feel > like changing governance (i.e. no longer be under the TC) has a lot less > impact to change the perception than, say, creating a separate ironic > product website that explains Ironic completely outside of the OpenStack > context (which we could do without changing governance). Ironic product web-site might be highly beneficial anyway. Looking at the functionally similar tool [1], those guys have an impressive web-presence. I can imagine prospective enterprise users would be gravitating toward MaaS just because of that. 1. https://maas.io

1 0

[kolla][uc] Kolla SIG
by Mark Goddard 02 Apr '20

02 Apr '20

Hi, I'd like to propose the creation of a Special Interest Group (SIG) [0] for Kolla. The main aim of the group would be to improve communication between operators and developers. The SIG would host regular virtual project onboarding, project update, and feedback sessions, ideally via video calls. This should remove the necessity of being physically present at Open Infra Summits for participation in the project. I like to think of this as the fifth open [1] (name TBD). I propose that in addition to the above sessions, the SIG should host more informal discussions, probably every 2-4 weeks with the aim of meeting other community members, discussing successes and failures, sharing knowledge, and generally getting to know each other a bit better. These could be via video call, IRC, or a mix. Finally - I propose that we build and maintain a list of Kolla users, including details of their environments and areas of interest and expertise. Of course this would be opt-in. This would help us to connect with subject matter experts and interested parties to help answer queries in IRC, or when making changes to a specific area. This is all up for discussion, and subject to sufficient interest. If you are interested, please add your name and email address to the Etherpad [2], along with any comments, thoughts or suggestions. [0] https://governance.openstack.org/sigs/ [1] https://www.openstack.org/four-opens/ [2] https://etherpad.openstack.org/p/kolla-sig Cheers, Mark

5 9

[all][dev][qa] cirros 0.5.1
by Radosław Piliszek 02 Apr '20

02 Apr '20

Hiya Folks, as you might have noticed, cinder 0.5.1 has been released. This build seems to be passing the current devstack gate. [1] Big thanks to hrw and smoser for letting cirros 0.5.1 happen (and cirros having bright future yet again). Also thanks to mordred for cleaning up SDK testing to pass. :-) I think it would be nice to merge this in Ussuri still, preferably before April. On the other hand, we all know that devstack gate is not super comprehensive and hence I would like to ask teams whose tests depend on interaction with guest OS to test their gates on this patch (or help me help you do that). I deliberately marked it W-1 to avoid merging too early. Let the discussion begin. :-) [1] https://review.opendev.org/711492 -yoctozepto

4 6

[tripleo] meeting notes from the last two weeks
by Wesley Hayutin 01 Apr '20

01 Apr '20

Greetings, I need to see why the openstack meeting bot is not in the #tripleo channel. A record was not automatically kept.. so here is the raw txt from the last two meetings.. I'll get the bot fixed asap. Meeting notes March 24 2020 [08:00:44] <weshay|ruck> #topic agenda [08:00:44] <weshay|ruck> * Review past action items [08:00:44] <weshay|ruck> * One off agenda items [08:00:44] <weshay|ruck> * Squad status [08:00:44] <weshay|ruck> * Bugs & Blueprints [08:00:44] <weshay|ruck> * Projects releases or stable backports [08:00:44] <weshay|ruck> * Specs [08:00:44] <weshay|ruck> * open discussion [08:00:44] <weshay|ruck> Anyone can use the #link, #action and #info commands, not just the moderatorǃ [08:00:44] <weshay|ruck> Hey folks! who's around? [08:00:57] <ekultails> o/ [08:00:59] <arxcruz|rover> o/ [08:01:03] <rlandy> o/ [08:01:11] <tkajinam> o/ [08:01:18] <rfolco> o/ [08:01:24] <pkopec> o/ [08:01:41] <owalsh> o/ [08:01:45] <jbadiapa> o/ [08:02:24] <ysandeep> ysandeep, o/ [08:02:27] <weshay|ruck> #topic review past action items [08:02:27] <weshay|ruck> http://eavesdrop.openstack.org/meetings/tripleo/2020/ [08:02:42] <weshay|ruck> anyone need to raise anything from a previous meeting? [08:03:07] <weshay|ruck> None. [08:03:07] <weshay|ruck> #topic one off agenda items [08:03:07] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-meeting-items [08:03:17] <Tengu> «o/ [08:03:18] <weshay|ruck> I added two items to the agenda.. [08:03:27] <weshay|ruck> please add something if you have it.. [08:03:53] * weshay|ruck notes that rdo-cloud the 3rd party ci platform is in a scheduled maint window today [08:04:03] <openstackgerrit> Emilien Macchi proposed openstack/tripleo-heat-templates master: Refactorize test_tht_ansible_syntax to welcome new roles/modules https://review.opendev.org/713669 [08:04:05] <weshay|ruck> the ctrl plane is moving to vexxhost [08:04:10] <openstackgerrit> Emilien Macchi proposed openstack/tripleo-heat-templates master: standalone/overcloud: enable the HA deployment by default https://review.opendev.org/359060 [08:04:16] <weshay|ruck> should be back by tomorrow [08:04:18] <openstackgerrit> Emilien Macchi proposed openstack/tripleo-heat-templates master: Deprecate Keepalived service https://review.opendev.org/657067 [08:04:28] <fultonj> o/ [08:04:33] <marios> hi [08:04:36] <weshay|ruck> any questions? [08:04:43] <weshay|ruck> EmilienM, stop working :) [08:04:45] <cloudnull> o/ [08:04:49] <leanderthal> o/ [08:04:50] <sshnaidm> o/ [08:04:53] <EmilienM> o/ [08:05:01] <weshay|ruck> leanderthal, you may want to get the testday on the agenda :) [08:05:12] <leanderthal> ooOOOooh good call [08:05:19] <weshay|ruck> ok.. the next topic is around bugs [08:05:34] <beagles> o/ [08:05:49] <weshay|ruck> we were up to 60 untriaged bugs last week.. a lot of folks do NOT have access to self triage and that's fine [08:06:09] <weshay|ruck> but if are a member of the tripleo org in launchpad.. we'd hope that you do follow the triage process [08:06:15] <sshnaidm> don't we run a meeting bot? [08:06:21] <weshay|ruck> So Question for the group... [08:06:23] <weshay|ruck> sshnaidm, yes [08:06:38] <weshay|ruck> but maybe it's down.. ? [08:06:40] <weshay|ruck> don't know [08:07:06] <weshay|ruck> Question... Any objects to closing any bugs in marked "New" ( untriaged ) older than 365 days? [08:07:11] <weshay|ruck> objection rather [08:07:17] <marios> weshay|ruck: sounds good to me [08:07:25] <beagles> k [08:07:31] <marios> weshay|ruck: but 'latest updated ' date right? [08:07:45] <weshay|ruck> ya.. I'll account for that... good point [08:07:47] <marios> weshay|ruck: not filed? maybe doesn't matter 365 is long enough that it either /or [08:07:50] <chandankumar> fultonj, fmount https://bugs.launchpad.net/tripleo/+bug/1868731 thanks for looking into that [08:07:51] <openstack> Launchpad bug 1868731 in tripleo "ceph_ansible_skip_tags is getting ignored during multinode overcloud deploy" [Critical,Triaged] [08:07:56] <beagles> (wrong window) but yeah, that sounds reasonable [08:08:02] * florianf (~flfuchs@2a02:8109:9280:1aa8:8bb0:31ca:8557:482c) has joined [08:08:09] <fultonj> chandankumar: thanks [08:08:15] <weshay|ruck> I'll send an email to the list to have folks reopen if they need it [08:08:30] <weshay|ruck> ok.. seeing no objections... we'll go ahead and clean it up :) [08:08:47] <weshay|ruck> #topic one off agenda items [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-meeting-items [08:08:47] <weshay|ruck> #topic Active Squad status [08:08:47] <weshay|ruck> ci [08:08:47] <weshay|ruck> #link https://hackmd.io/IhMCTNMBSF6xtqiEd9Z0Kw?both [08:08:47] <weshay|ruck> validations [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-validations-squad-status [08:08:47] <weshay|ruck> ceph-integration [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-integration-squad-status [08:08:47] <weshay|ruck> transformation [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-ansible-agenda [08:08:47] <weshay|ruck> mistral-to-ansible [08:08:47] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-mistral-to-ansible [08:09:00] <weshay|ruck> any reviews needed by the squads? [08:09:05] * TrevorV (~TrevorV(a)130-45-79-246.dyn.grandenetworks.net) has joined [08:09:17] <Tengu> validations: we have our package under TripleO governance! [08:09:25] <Tengu> it's been merged today. [08:09:50] <weshay|ruck> rdo governance :) [08:09:51] <cloudnull> weshay|ruck the following reviews would be great to get some eyes on - https://review.opendev.org/#/q/starredby:cloudnull+status:open,n,z [08:10:12] <weshay|ruck> thanks cloudnull [08:10:41] <weshay|ruck> fultonj, I mentioned this earlier.. but ansible 2.9 is being tested along side the latest ceph-ansible.. I don't have a ton of detail on that [08:11:02] * derekh (~derekh(a)93.107.228.126) has joined [08:11:15] <weshay|ruck> ok.. let's move on [08:11:19] <fultonj> weshay|ruck: ack [08:11:26] <weshay|ruck> #topic Moderately Active Squads [08:11:26] <weshay|ruck> Ironic-integration [08:11:26] <weshay|ruck> https://etherpad.openstack.org/p/tripleo-ironic-integration-squad-status [08:11:26] <weshay|ruck> upgrade [08:11:26] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-upgrade-squad-status [08:11:26] <weshay|ruck> edge [08:11:26] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-edge-squad-status [08:11:26] <weshay|ruck> networking [08:11:26] <weshay|ruck> #link https://etherpad.openstack.org/p/tripleo-networking-squad-status [08:11:47] <weshay|ruck> probably nothing new here [08:11:59] <weshay|ruck> #link https://launchpad.net/tripleo/+milestone/ussuri-3 [08:12:31] <weshay|ruck> 5 New, 28 Incomplete, 4 Invalid, 4 Won't Fix, 4 Confirmed, 385 Triaged, 120 In Progress, 2 Fix Committed, 151 Fix Released [08:12:50] <weshay|ruck> not bad on the bug counts.. I guess [08:13:00] <weshay|ruck> Storyboard bugs. [08:13:00] <weshay|ruck> #link https://storyboard.openstack.org/#!/project_group/76 [08:13:48] <cloudnull> weshay|ruck we've recently updated the mistral_to_ansible board - https://storyboard.openstack.org/#!/board/208 [08:14:17] <weshay|ruck> very nice.. [08:14:31] <weshay|ruck> k.. will include that in the future [08:14:53] <weshay|ruck> There are two blueprints not started for ussuri [08:14:54] <weshay|ruck> Medium tripleo-firewall-rule-reporting New Not started ussuri [08:14:54] <weshay|ruck> Medium remove-puppet Drafting Not started Emilien Macchi ussuri [08:15:02] * amoralej|lunch is now known as amoralej [08:15:20] <weshay|ruck> EmilienM, maybe we move that to the next release or future at this point... [08:15:30] <weshay|ruck> April 20th is m3 I think [08:15:52] <weshay|ruck> and dsneddon owns https://blueprints.launchpad.net/tripleo/+spec/tripleo-firewall-rule-report… [08:16:10] <weshay|ruck> #topic specs [08:16:10] <weshay|ruck> #link https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open [08:16:39] <weshay|ruck> reviews for luke please https://review.opendev.org/#/c/698828/ on [08:16:39] <weshay|ruck> Add spec for AWX integration. [08:16:55] <weshay|ruck> #topic open discussion [08:16:55] <weshay|ruck> Anything else that folks want to bring up to the meeting? [08:17:07] <EmilienM> weshay|ruck: i'll probably abandon it for now [08:17:12] <weshay|ruck> k.. thanks [08:17:27] <weshay|ruck> anyone else ? [08:17:30] <weshay|ruck> going once [08:17:36] <weshay|ruck> going twice [08:17:43] <marios> weshay|ruck: [08:17:46] <weshay|ruck> #endmeeting tripleo [08:17:49] <marios> do we wantto consider virtual ptg [08:17:53] <marios> weshay|ruck: ? [08:17:54] <weshay|ruck> I'll save the meeting notes [08:17:57] <marios> weshay|ruck: next time then [08:17:58] <marios> ... [08:17:58] <weshay|ruck> marios, that's still not clear [08:18:04] <weshay|ruck> but most likely [08:18:06] <cloudnull> +1 for virt ptg Meeting notes from March 30 2020 <weshay> #topic agenda [08:01:02] <weshay> * Review past action items [08:01:02] <weshay> * One off agenda items [08:01:02] <weshay> * Squad status [08:01:02] <weshay> * Bugs & Blueprints [08:01:02] <weshay> * Projects releases or stable backports [08:01:02] <weshay> * Specs [08:01:02] <weshay> * open discussion [08:01:02] <weshay> Anyone can use the #link, #action and #info commands, not just the moderatorǃ [08:01:02] <weshay> Hey folks! who's around? [08:01:08] <EmilienM> o/ [08:01:18] <ekultails> o/ [08:01:20] <Tengu> ybe [08:01:22] <fultonj> o/ [08:01:24] <rlandy> o/ [08:01:27] <weshay> EmilienM, aye.. I'll get into that [08:01:28] <Tengu> *maybe [08:02:28] <tkajinam> o/ [08:02:30] <ysandeep|rover> o/ [08:02:36] <mwhahaha> o/ [08:02:42] <chandankumar> \o/ [08:04:24] <marios> o/ [08:05:05] <beagles> o/ [08:05:05] <weshay> #topic review past action items [08:05:05] <weshay> http://eavesdrop.openstack.org/meetings/tripleo/2020/ [08:05:05] <weshay> None. [08:05:14] <weshay> #topic one off agenda items [08:05:14] <weshay> #link https://etherpad.openstack.org/p/tripleo-meeting-items [08:05:27] <weshay> ok.. virt ptg.. /me pastes from the agenda some info [08:05:38] <weshay> * Virtual PTG for TripleO [08:05:38] <weshay> * https://etherpad.openstack.org/p/tripleo-victoria-topics [08:05:38] <weshay> * http://lists.openstack.org/pipermail/foundation/2020-March/002854.html [08:05:38] <weshay> * https://www.openstack.org/events/opendev-ptg-2020/ [08:05:38] <weshay> * https://etherpad.openstack.org/p/Virtual_PTG_Planning?_ga=2.148734014.82059… [08:05:38] <weshay> [08:05:38] <weshay> * planning email sent out by foundation - dates for ptg virt event not yet know. [08:05:38] <weshay> * dates for planning [08:05:38] <weshay> - April 2nd at 12:00 UTC [08:05:38] <weshay> - April 6th at 17:00 UTC [08:05:38] <weshay> - April 7th at 2:00 UTC [08:05:38] <weshay> [08:05:53] <arxcruz> o/ [08:06:08] <weshay> I'm going to join the last two mtgs there on the 6th and 7th... [08:06:38] <weshay> once we get dates.. we'll be sending out a email to confirm who would like to attend.. just like previous in person ptg's [08:07:05] <weshay> any questions about the ptg in general before we get into tripleo specific ptg topics [08:07:17] <weshay> hello [08:07:23] <weshay> is it me your looking for? [08:07:23] <marios> weshay: hav we considered the details ... sessions will be in bluejeans? or irc? [08:07:26] <marios> weshay: timezones? [08:07:30] marios maciejjozefczyk Madkiss mandre marbindrakon matbu [08:07:38] <marios> weshay: ah i see you have time already there [08:07:43] <weshay> marios, I assume that will be addressed in these planning sessions [08:08:02] <weshay> note.. those dates are NOT the ptg.. they are PLANNING events FOR the ptg [08:08:05] <weshay> :) [08:08:06] <gfidente> o/ [08:08:07] <marios> weshay: k (the times you have there are for the planning) [08:08:07] <marios> ack [08:08:12] <weshay> aye [08:08:25] <weshay> there is a sign up sheet for the planning.. if you are interested [08:08:34] <weshay> OK.. thanks for responding [08:08:36] <weshay> marios++ [08:08:37] <marios> weshay: perhaps this can just be worked out amongst the folks interested in each session... and we don't need to mandate a way/time [08:08:57] <weshay> there is no mandate for ptg.. volunteers only :) [08:09:08] <weshay> so.. TLDR.. details pending on ptg [08:09:15] <weshay> now for tripleo [08:09:15] <weshay> https://etherpad.openstack.org/p/tripleo-victoria-topics [08:09:37] <weshay> as usual.. please add topics to this list, w/o topics we have no agenda [08:09:57] <weshay> I'll be adding a few myself :) [08:09:59] <marios> weshay: we could overview/presentation about the component pipeline & how it affect how we promote now [08:10:05] * markllama (~mark5163(a)72.32.180.178) has joined [08:10:07] marios maciejjozefczyk Madkiss mandre marbindrakon markllama matbu [08:10:13] <EmilienM> marios++ [08:10:44] <weshay> marios, yes.. usually there is an hour for CI at the ptg.. the new dlrn structure and component based ci is a good topic imho [08:11:02] <Tengu> +42 [08:11:42] <weshay> I would assume that new features.. validation, ansible collections, tripleo-operators should be added to the topic list [08:11:48] <weshay> tripleo-ansible etc [08:12:09] <weshay> any questions about tripleo + ptg? [08:12:27] <Tengu> I'll check with my folks about the validation part. [08:12:32] <weshay> +1 [08:12:39] <Tengu> maybe the container would be nice. [08:13:11] <weshay> EmilienM, you have anything to add? [08:13:36] <EmilienM> not now, indeed we need to come with more topics [08:13:44] <EmilienM> I'll try to gather some from the team [08:14:05] <weshay> ya.. I am looking for parity from previous ptg's.. minus the last one [08:14:32] <weshay> we did not have a lot of folks in china for the last ptg.. and I would expect a backlog of topics [08:14:45] <weshay> so we'll be covering that here for a few weeks I'm sure [08:14:47] <weshay> anyhoo [08:14:50] <weshay> #topic Active Squad status [08:14:50] <weshay> ci [08:14:50] <weshay> #link https://hackmd.io/IhMCTNMBSF6xtqiEd9Z0Kw?both [08:14:50] <weshay> validations [08:14:50] <weshay> #link https://etherpad.openstack.org/p/tripleo-validations-squad-status [08:14:50] <weshay> ceph-integration [08:14:50] <weshay> #link https://etherpad.openstack.org/p/tripleo-integration-squad-status [08:14:50] <weshay> transformation [08:14:50] <weshay> #link https://etherpad.openstack.org/p/tripleo-ansible-agenda [08:14:50] <weshay> mistral-to-ansible [08:14:50] <weshay> #link https://etherpad.openstack.org/p/tripleo-mistral-to-ansible [08:14:56] <weshay> where is the bot? [08:14:57] * haleyb (haleyb@nat/redhat/x-koblohkdhoozsgkh) has joined [08:15:09] <weshay> dang [08:15:26] <weshay> second week in a row.. I'll look into why the meeting bot is not active.. [08:15:32] * bogdando has quit (Ping timeout: 256 seconds) [08:15:48] <weshay> ok.. the point now of calling squads... again... is to facilitate reviews [08:16:02] <weshay> in a more public fashion [08:16:20] <cloudnull> o/ [08:16:27] <weshay> so just a reminder... guidance is to spend 30-60 minutes per day reviewing other peoples code [08:16:32] * bnemec (~bnemec(a)96-41-255-59.dhcp.eucl.wi.charter.com) has joined [08:16:55] <weshay> if you are not doing that.. you're doing opensource wrong :) [08:17:00] <cloudnull> ++ [08:17:32] <weshay> so.. w/o calling out folks specifically... anything that needs attention? [08:18:12] <cloudnull> work on removing mistral is going great: https://review.opendev.org/#/q/starredby:cloudnull+status:open,n,z - these are some reviews that are inflight and we'd greatly appreciate if folks could take a look at them. [08:18:21] <weshay> ++ [08:18:35] <marios> weshay: '3 a day' ;) [08:18:42] <weshay> ++ [08:18:49] <marios> used to be a minimum requirement to be core [08:19:08] <weshay> ya.. hasn't changed.. [08:19:21] * markllama has quit (Ping timeout: 256 seconds) [08:19:24] <marios> weshay: yeah but it used to be enforced more enthusiastically ;) [08:19:26] <weshay> well.. I can show everyone what we look for in cores.. I'll add that to next weeks agenda [08:19:36] <marios> s/enthusiastically/stricly [08:19:41] <marios> strictly even you know what i mean [08:19:49] <weshay> ya.. VERY open in ideas to help facilitate reviews.. [08:20:04] <weshay> all projects struggle w/ that.. but new ideas are welcome [08:20:18] <openstackgerrit> Rabi Mishra proposed openstack/python-tripleoclient master: Fix _get_image() of GlanceClientAdapter to call find_image() https://review.opendev.org/716277 [08:20:20] <weshay> ok.. /me ends the lecture [08:20:31] <weshay> #topic Moderately Active Squads [08:20:31] <weshay> Ironic-integration [08:20:31] <weshay> https://etherpad.openstack.org/p/tripleo-ironic-integration-squad-status [08:20:31] <weshay> upgrade [08:20:31] <weshay> #link https://etherpad.openstack.org/p/tripleo-upgrade-squad-status [08:20:31] <weshay> edge [08:20:31] <weshay> #link https://etherpad.openstack.org/p/tripleo-edge-squad-status [08:20:31] <weshay> networking [08:20:31] <weshay> #link https://etherpad.openstack.org/p/tripleo-networking-squad-status [08:20:31] <weshay> Any squad wanting to bring up their status, or a topic for the general public? [08:20:47] <weshay> #link https://launchpad.net/tripleo/+milestone/ussuri-3 [08:20:58] <Tengu> validations: we're aiming to get our code in train [08:21:08] <Tengu> at least for the new packages - validations-common and validations-libs. [08:21:16] <weshay> 5 New, 28 Incomplete, 5 Invalid, 5 Won't Fix, 4 Confirmed, 378 Triaged, 120 In Progress, 2 Fix Committed, 189 Fix Released [08:21:26] <weshay> Tengu++ [08:21:46] <Tengu> doing so will allow to get a clean code and, well, make our life easier on Red Hat side. [08:21:49] <weshay> Tengu, I see ptg topics in your future :) [08:22:00] * bnemec has quit (Read error: No route to host) [08:22:03] <Tengu> weshay: yep, maybe ;). [08:22:19] <Tengu> (hint: just dropped a mail to my team ;)) [08:22:21] <weshay> so.. bug triage will continue as I have time... just a reminder anything older than 365 days and in new.. will be closed [08:22:40] <weshay> Storyboard bugs. [08:22:40] <weshay> #link https://storyboard.openstack.org/#!/project_group/76 [08:23:02] <weshay> reminder.. be nice to the infra folks and folks driving storyboard... volunteer effort there.. [08:23:16] <openstackgerrit> Martin Kopec proposed openstack/ansible-role-collect-logs master: Extend infrared molecule tests https://review.opendev.org/705552 [08:24:27] * weshay notes... [08:24:40] <weshay> now is the time to start thinking about blueprints and specs for the next cycle [08:24:49] <weshay> here's a dump on ussuri [08:24:50] <weshay> Medium ansible-certmonger Approved Unknown Cédric Jeanneret ussuri [08:24:50] <weshay> Medium ironic-overcloud-ci Approved Slow progress Derek Higgins ussuri [08:24:50] <weshay> Medium multiarch-support Approved Good progress Tony Breeds ussuri [08:24:50] <weshay> Medium nova-less-deploy Approved Good progress Steve Baker ussuri [08:24:50] <weshay> Medium replace-keepalived-undercloud Approved Good progress Emilien Macchi ussuri [08:24:50] <weshay> Medium split-controlplane-workflow Approved Unknown ussuri [08:24:50] <weshay> Medium remove-puppet Drafting Not started Emilien Macchi ussuri [08:24:50] <weshay> Medium tripleo-firewall-rule-reporting New Not started ussuri [08:24:50] <weshay> Undefined tripleo-mistral-to-ansible Approved Good progress Dougal Matthews ussuri [08:25:07] * Tengu hides [08:25:34] <openstackgerrit> Martin Kopec proposed openstack/ansible-role-collect-logs master: Extend infrared molecule tests https://review.opendev.org/705552 [08:25:48] <weshay> ekultails, looks like progress on https://review.opendev.org/698828 [08:25:56] <weshay> Add spec for AWX integration. [08:25:58] <weshay> FYI ^ [08:26:17] <EmilienM> replace-keepalived-undercloud is WIP and waiting on HA byd efault, blocked by not having upgrade jobs on centos8 [08:26:29] <EmilienM> remove-puppet is not in progress, I'm not working on it [08:26:30] <Tengu> for the ansible-certmonger, it's in the Security capable hands, not mine... I just pushed the idea ^^' [08:26:48] <Tengu> ade_lee: -^^ [08:26:55] <weshay> aye.. EmilienM working in the background on that for you... getting advice on the priority for train + centos8 [08:27:43] <weshay> need help reviewing https://review.opendev.org/#/c/715734/ Add new project and repository for tripleo-compute-extras [08:27:45] <weshay> as well folks [08:28:08] <weshay> k.. /moving on [08:28:12] <weshay> #topic open discussion [08:28:12] <weshay> Anything else that folks want to bring up to the meeting? [08:28:26] <weshay> FYI.. I've nominated myself for ptl in victoria.. [08:28:32] <EmilienM> yay! [08:28:34] <Tengu> weshay: you'll get my vote for ptl :) [08:28:45] <fultonj> +1 [08:28:59] * zzzeek has quit (Quit: bye) [08:29:00] <weshay> I would like to help others this cycle better understand what is involved.. and the how-to's to the best of my ability :) [08:29:21] <weshay> so if you are interested in perhaps being ptl.. after victoria.. let me know and I'm happy to walk through it [08:29:50] <weshay> that's it from me.. anyone else have anything new? [08:30:14] <weshay> once [08:30:15] <weshay> twice [08:30:18] <weshay> #endmeeting tripleo [08:30:23] <weshay> thanks all :)

2 2

[election][octavia][ptl] Announcing my PTL candidacy for Octavia
by Michael Johnson 01 Apr '20

01 Apr '20

My fellow OpenStack community, I would like to nominate myself for Octavia PTL during the Victoria cycle. I have previously led the team during the Stein release, and I would like to continue helping our team provide network load balancing services for OpenStack. Looking forward to Victoria I expect the team to finish some major new features, such as the Jobboard transition and introducing HTTP/2 support. Thank you for your support and your consideration for Victoria, Michael Johnson (johnsom)

2 1

[tempest] what is a proper way to install a package into a vm instance spawned by tempest?
by Roman Safronov 01 Apr '20

01 Apr '20

Hi, I wrote a tempest test <https://review.opendev.org/#/c/710975/https://review.opendev.org/#/c/710975/)> which requires keepalived to be running inside vm instance. The test tries to install keepalived package inside vm by running "apt install/yum install". However as I see in upstream gates logs this does not work while the same code works perfectly in our downstream CI using the same image. Do vm instances spawned on upstream gates during tests have a route to the internet? Is there an alternative way that I can use in order to install a package? Thanks in advance -- ROMAN SAFRONOV SENIOR QE, OPENSTACK NETWORKING Red Hat <https://www.redhat.com/> Israel M: +972545433957 <https://red.ht/sig>

4 6

[tosca-parser][heat-translator][tacker] - Need new version of heat-translator and tosca-parser libraries for Tacker
by Patil, Tushar 31 Mar '20

31 Mar '20

Hi PTL and Core Reviewers, We are working on implementing ETSI spec in tacker for Ussuri release for which we have pushed couple of patches in heat-translator [1][2] and tosca-parser[3]. Patch [1] is not yet merged so request core reviewers to please take a look at it. We have uploaded many patches in tacker [4] but most of the patches are failing on CI as it's requires changes from heat-translator and tosca-parser. So we need a new release of heat-translator (after patch [1] is merged) and tosca-parser badly. Please let us know when are you planning to release a new version of these libraries. [1] : https://review.opendev.org/#/q/status:merged+project:openstack/heat-transla… [2] : https://review.opendev.org/#/q/status:open+project:openstack/heat-translato… [3] : https://review.opendev.org/#/c/688633 [4] : https://review.opendev.org/#/q/topic:bp/support-etsi-nfv-specs+(status:open… Thank you. Regards, tpatil Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

1 2

[election][ptl][swift] Tim Burke candidacy for Swift PTL
by Tim Burke 31 Mar '20

31 Mar '20

It would be my honor and pleasure to continue serving you as Swift PTL. The world continues to generate and retain ever-increasing amounts of data, and Swift continues to rise to the challenge of storing that data durably and making it highly available. I'm excited to help us engineer now to be ready for next year's data-center demands. To that end, there are several projects we'll be advancing; in general, these are not short-term, though some pieces will surely come in the next cycle. As hard-drive sizes increase, the lots-of-small-files problem has become a lots-of-files problem. Between 16TB hard drives hitting the market and cost concerns pushing us toward ever more drives per box, even historically "reasonable" object sizes will produce noticeable memory pressure that we'd like to reduce. OVH's explorations in this space give us all a leg up that we should take advantage of. As clusters grow, we must ensure Swift can scale with them. Some aspects of that will be relatively straight-forward, like allowing rings to support more than 64k devices. Other challenges are less well-defined; there are likely improvements that could be made in replication and backend protocols, for example, but there is no single way forward. There will likely be some experiments that never land on master -- but as long as they are in the open and we can all learn from them, they will not be failures. All of that must be driven by what we learn by operating real clusters at scale. To do that, we must improve our metrics and monitoring, and find ways to observe the system dynamically. Post-facto log analysis is not tenable when dealing with tens of thousands of requests per second across hundreds of nodes. At the same time, we cannot neglect our client ecosystem. This extends not just to python-swiftclient, but to S3 clients as well. For better or worse, S3 has become the de facto standard interface for object storage, and we must ensure our compatibility is as seamless as possible. This cycle we added S3-compatible versioning, but there is so much more we could be doing, from object life-cycle management to bucket inventories. As always, we will listen to our users and prioritize addressing their pain points. Tim Burke ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

1 0

[elections][tc] Nomination
by Radosław Piliszek 31 Mar '20

31 Mar '20

Dear Fellow OpenStackers, I am Radosław Piliszek (yoctozepto) and I am proposing myself as a TC candidate starting Victoria cycle. For the record, I have never been in TC nor a PTL... yet. I am affiliated with a relatively small Polish university: University of Białystok, with the local Computing Centre offering services to local academics. My experience is broad in that this work involves being a whole IT department at once. :-) OpenStack piqued my interest in 2018 when I joined the Foundation as an individual member. Since then I made myself COA (Certified OpenStack Administrator), learnt the jump from "administrator" to "operator" while deploying locally various PoC instances of basic OpenStack services and finally started contributing upstream via bug reports, patches and reviews. I was (and am!) really proud to have been recognized Kolla core due to my work with fellow project members. Later on, DevStack core nomination followed for which I am grateful as well. In the Kolla project I work mostly on ensuring sanity, enhancing testing and fixing current issues while helping fellow contributors to deliver their features and fixes. I also managed to deliver a bigger change in the Train cycle: all-around IPv6-only networking support. I enjoyed the cross-project aspect of this and decided to contribute a bit to the development experience as well and this is how I ended up DevStack core (true story). Nowadays I am wearing multiple hats in the wide community and many of you probably recognize me from IRC where I try to be helpful but also ask questions around (often technical ones like: to be or not to be?). One could say I'm inquisitive (hopefully in the good sense of this word) and in fact I value highly a deeper insight into the problem at hand (probably due to bad experience with hasty actions!). I react to issues quite quickly (bothering infra from time to time - I am really sorry, you folks are doing great job!) and work on solutions with fellow OpenStackers (aka you) which brings real joy and makes experience real. I have a few, rather broad, goals (or thoughts?) of mine: 1) To test, test and test. My motto is: "not tested = not working". Unfortunately, this is actually often the case in reality. :-( Hence, I encourage thorough testing, especially at the functional and integration level. I believe we need to be reliable to be trustworthy. 2) To make OpenStack easily consumable by small companies, especially in public academia but not only. Everyone deserves a good private cloud experience with decent learning curve. This involves prompt and current documentation but also reliable base for installs. (1) and (2) culminate in (3) [1+2=3 - could not have been simpler!] 3) Who are we? BUILDERS! What do we want? TO BUILD! (I hope you know the meme!) Ultimately OpenStack is software built for specific purpose and is meant to be consumed by cloud operators. We have plenty of ways to get OpenStack "installed" but officially we still rely on the archaic assumption that everything is thrown in the same environment. This is rarely the case nowadays due to various layers of separation being applied: virtual envs, OCI images. It would be beneficial to be able to rely on prebuilt official images of OpenStack services and their prerequisites, also for CI. We don't need to rebuild/reinstall keystone, glance, nova and swift just to test neutron that one more time, only to discover pip hangs installing dep of dep of not-even- neutron due to random networking issue.* Similarly this is wasted effort in case of multinode testing. Multiply this by the amount of scenarios and... well, you probably get the picture. I know we can do better: deliver more reliability via more reliability. * Order random for example purposes. This is as many relevant bits as I thought necessary to introduce my candidacy and share my mind with you. Thank you for reaching this far. Radosław Piliszek (yoctozepto) https://review.opendev.org/716363

1 0

[tc][elections] Nomination for TC
by Tobias Rydberg 31 Mar '20

31 Mar '20

Hi fellow Stackers, My name is Tobias Rydberg and I will by this email announce my candidacy for the OpenStack Technical Committee. For those who (yet) don't know me, I'm employed by the cloud provider City Network and through that I've been around and worked with OpenStack since 2014 when we as City Network started our OpenStack journey. I'm a simple person that speak my mind, love to have fun and get to know new people and technologies - and I have to say that being part of this community ticks a lot of those boxes. During the last couple of years I've been chair for the Public Cloud SIG (previously WG), and in that role you might have seen me hosting Forum sessions at all Summits since the Forum was introduced, spreading the word of why OpenStack is super important for public clouds (the Public Cloud Passport Program is a child of PC SIG) and what is still missing... ;-) Even though I'm a developer from the get go, I haven't done a lot of code contributions over the years, but I have tried to contribute in various other ways where being SIG chair is one, driving discussions in the Forums and being part of organising OpenStack days events (Nordic). So, what can I bring to the table? I believe that my background (and precent) with multiple years of running multiple public and private clouds will bring a lot of operator experience. We've over the years also been very focused to deliver OpenStack to customers with very high regulatory compliance demands, such as banks, health care, insurance industry, and as I see it, that is a pretty hot potato right now and I believe that will not cool down for some time. I my current role I have the blessing of talking a lot with customers building their services on top of OpenStack, listening to their experience and feedback - everything from how hard it can be to find the correct piece of documentation to limitations that hinders them from choosing OpenStack as a platform for their service - valuable feedback that not always reach the community. I think that the continued success of OpenStack (for at least 10 more strong years) lies in the hands of the "operators" - the people and the companies that live and breathe OpenStack - the people and the companies that have the experience how OpenStack operates in all the different use cases you can't predict in a public cloud. This is my first time running for a chair at the TC table, my experience of sitting in such chair is by that pretty limited, but I care a lot about this awesome community and I'm eager to learn and to do my fair share to make this community a success to the years to come... Thanks for taking the time to read and to consider my candidacy! Cheers, Tobias

1 0

Upcoming pip changes - stop installing test-requirements in devstack
by Monty Taylor 31 Mar '20

31 Mar '20

Heya, Recently we had to revert a change to devstack that ran pip check. This is a recommendation from the pip team to verify that upcoming addition of a depsolver to pip isn’t going to break us. Well - it is going to break us. The reason it’s going to break us is that we don’t apply constraints to linters (so that projects can deal with those at their own rate) BUT - we install every project’s test-requirements.txt (containing the linters) when we run devstack. That means we uninstall and reinstall flake8 at different versions over and over again - and the final state is not one that is completely consistent. I’ve pushed up this: https://review.opendev.org/#/c/715469/ Which is a patch to stop installing test-requirements in devstack. Realistically we should not need to install this in devstack. Devstack is installing the software which does not need test-requirements - and then we test it with tempest which has its own set of requirements. As a side benefit, devstack is quicker and none of the non-voting jobs on devstack fail now. It’s possible this change could impact people using devstack as a base for single-project functional tests - so it’s worth being careful with. But I think we should get it done and then re-add the pip check as a verification that we’re not going to get broken this summer. Monty

4 4

[charms][ptl][election] PTL Non-candidacy
by Frode Nordahl 31 Mar '20

31 Mar '20

Hello all, The Ussuri cycle is coming to an end and the contributors to the Charms project has done great progress in the key areas we set afoot at the beginning of the cycle. We have also had good participation from the broader community and I hope to see that flourish further in the coming cycles. I believe rotating leadership for open source projects is a good thing and I am happy to pass on the relay baton for the Victoria cycle. -- Frode Nordahl

1 0

[all][elections][ptl][tc] Conbined PTL/TC Nominations Last Days
by Kendall Nelson 31 Mar '20

31 Mar '20

Hello Everyone! A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Mar 31, 2020 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2020-03-24 23:45:00 UTC Nominations end @ 2020-03-31 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 8:25:21 Nominations progress : 94.99% --------------------------------------------------- Projects[1] : 60 Projects with candidates : 0 ( 0.00%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 60 (Adjutant Barbican Blazar Cinder Cloudkitty Congress Cyborg Designate Ec2_Api Freezer Glance Heat Horizon I18n Infrastructure Ironic Karbor Keystone Kolla Kuryr Loci Magnum Manila Masakari Mistral Monasca Murano Neutron Nova Octavia OpenStackAnsible OpenStackSDK OpenStack_Charms OpenStack_Helm Openstack_Chef Oslo Packaging_Rpm Placement Puppet_OpenStack Qinling Quality_Assurance Rally Release_Management Requirements Sahara Searchlight Senlin Solum Storlets Swift Tacker Telemetry Tricircle Tripleo Trove Vitrage Watcher Winstackers Zaqar Zun) =================================================== Stats gathered @ 2020-03-31 15:19:39 UTC This means that with approximately 2 days left, 60 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, Kendall Nelson(diablo_rojo) & the Election Officials [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[blazar][election][ptl] PTL candidacy for Victoria
by Pierre Riteau 31 Mar '20

31 Mar '20

Hi, I would like to self-nominate to serve as PTL of Blazar for the Victoria release cycle. I have been PTL since the Stein cycle and I am willing to continue in this role. As with many other projects, we are struggling with a lack of contributions. My focus will be to keep our small community active, help new contributors to be more involved in the project, and deliver functionality that will encourage further adoption. Thank you for your support, Pierre Riteau (priteau)

2 1

[nova] Proposing Ghanshyam Mann as nova core
by Balázs Gibizer 31 Mar '20

31 Mar '20

Hi, I'm proposing Ghanshyam Mann to the core team. He is a long time OpenStack and nova contributor. He is one of our API and QA expert. I think he would be a great addition to the team. Cores, please vote (-1, 0, +1) before next Monday (03.30.) Cheers, gibi

8 8

[nova] Proposing Lee Yarwood as nova core
by Balázs Gibizer 31 Mar '20

31 Mar '20

Hi, I'm proposing Lee to the core team. He is around for a long time and he became really active recently not only on the stable branches. I think he would be a great addition to the team. Cores, please vote (-1, 0, +1) before next Monday (03.30.) Cheers, gibi

8 8

[tc][election] Add Rico Lin candidacy for Victoria TC role
by Rico Lin 31 Mar '20

31 Mar '20

Dear all, It has been a great year for me to work on TC and work as TC vice-chair, and I do like to join TC election again and keep serving this community as TC member if I have the honor. In the past year, I have been working on the following tasks: * TC vice-chair: I thank for the vice-chair roles allows me to dive in deeper on TC activity. As we work on TC's daily support for TC chair. IMO, JP shows some nice example to running TC chair by standardizing routine processes. And I do feel it's great to work with him. And from what I learned, to consistent checking on actions for TCs is something we should keep on. Also ML update and host meetings. What I think we should try in advance are keep pushing TC plus UC merging task, and work on providing better decision system so we can make sure at the end of discussion, we have something put into actions and that's been decided by TCs as a group. * Meta SIG chair: It's a great opportunity to working on SIG govern, which works with coordination between devs, ops, and users. We achieved on items like pushing more new SIGs, create SIG guidelines, track SIG status, and of course general SIG govern stuff. But SIGs still needs more attention. Which is one of the goals I have to push SIG forward (And I'm happy to have others as Meta SIG chair). IMO SIG only successful when it can provide a better bridge across all roles. That's something we need to keep pushing our effort to expose SIGs. * Comparison of Official Group Structures: I also work on providing [1] so whoever join this community, can have better understanding on how we works. Over time, our structure require changes, so we can evolve and provide understandable structures for the whole time (and for old and new members). What we can keep working on is to consistently review the structure flow, to make sure everything makes sense for a community to allow consistency and evolution. Also as mentioned, to combine TC and UC, will require more review on structure to make sure teams all get benefits from the achievement we plan. * Cross culture bridge: This is something I'm reeeally proud of. To help community members reach better communication despite language, culture, and timezone barriers. I get the honor to serve a great number of community members on this task, and I'm proud of it. This also alerts me that we need more members in community to become the bridge. We have some great people to keep working on this, but we simply need more from different languages, cultures, and timezone. So community members can have a better way to reach to TCs. * community goal schedule: gmann doing really good job on keep community-wide goal forward. As we implemented our goal schedule to cover from pre-select, select, and implementation schedule. I'm planning to keep govern that process to make sure we jump in the correct routine. [1] https://governance.openstack.org/tc/reference/comparison-of-official-group-… -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[nova] FFU : When should we remove reshape support for a feature ?
by Sylvain Bauza 31 Mar '20

31 Mar '20

Hola, In Stein, I provided a new feature [1] that was checking inventories from multiple children resource providers (RP). Since in Rocky, those inventories were only on the root RP, I had to provide both : #1 : an upgrade support for RPs that were not having a parent RP (that was the case of Stein compute nodes) [2] #2 : a reshape method in the libvirt driver for moving allocations from a root RP to children RPs [3] Now, we're in the Ussuri timeframe and as I was usually doing, I removed the upgrade support (in #1) since we're 100% sure that all compute nodes are either Train or Ussuri [4] This is cool, but now the reshape code I wrote for #2 no longer works (which is normal, since the 'non-Stein' support was removed) [5] Soooooo. Can I also then remove the reshape support ? That would mean that upgrading from Rocky to Train would work, but Rocky to Ussuri wouldn't. I'm personally OK with this, but I guess other people could have concerns with. Do we have any consensus about how longer we would support a reshape ? I think honestly that a 3-releases time window is enough but I can hear some disagreements about this strawman proposal. If so, please voice. -Sylvain [1] https://blueprints.launchpad.net/nova/+spec/vgpu-stein [2] https://review.opendev.org/#/c/636591/ [3] https://review.opendev.org/#/c/599208/ [4] https://review.opendev.org/#/c/715489/ [5] https://541e2403478ac154d5eb-056bfb946e355d1a1a86dc411a70c5ec.ssl.cf2.rackc…

3 3

[all][elections][ptl][tc] Conbined PTL/TC Nominations Last Days
by Ian Y. Choi 31 Mar '20

31 Mar '20

A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Mar 31, 2020 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2020-03-24 23:45:00 UTC Nominations end @ 2020-03-31 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 9:22:53 Nominations progress : 94.42% --------------------------------------------------- Projects[1] : 60 Projects with candidates : 30 ( 50.00%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 30 (Adjutant Barbican Blazar Cloudkitty Congress Cyborg Designate Freezer Heat I18n Infrastructure Karbor Loci Magnum Manila Masakari Nova Octavia OpenStack_Charms Oslo Packaging_Rpm Placement Quality_Assurance Rally Requirements Searchlight Swift Tacker Tricircle Zaqar) =================================================== Stats gathered @ 2020-03-31 14:22:07 UTC This means that with approximately 2 days left, 30 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[kolla] Tomorrow's meeting cancelled
by Mark Goddard 31 Mar '20

31 Mar '20

Hi, I'm on leave tomorrow and several cores are unavailable so let's skip this week's meeting. Please bear in mind we're approaching OpenStack feature freeze, and our own freeze will follow shortly afterwards. As such, please focus on finishing off and reviewing our cycle priorities. Cheers, Mark

1 0

[qa] Not running for PTL
by Ghanshyam Mann 31 Mar '20

31 Mar '20

Hello Everyone, I would like to announce that I am not running for QA PTL for V cycle. Its been 4 cycles for me as the QA PTL and I think it's time for a new leader to take this responsibility. It has been a great experience for me as PTL and keeping the QA program healthy and active as it was from starting. Stabilizing the testing more and adopting new tooling under QA. Apart from PTL role, I will continue my contribution to QA with the same bandwidth as it is now. There is no change in that and you can keep pining me for any issue or discussions. Also, I will be there for a smooth PTL transition. Thanks everyone for making these 2 years a great learning period for me. -gmann

2 1

[election][heat] PTL candidacy for Victoria
by Rico Lin 31 Mar '20

31 Mar '20

Hi all, I would like to announce my candidacy for Heat PTL for Victoria cycle. Over the past couple of cycles, we running Heat dynamically according to requirements. We never stop encouraging people to join us and provide consistent reviews or fixes as much as we can basic on priorities. And if those priorities not working for you, that means you must join the community to help. I believe the goals for the next cycle should be community CI stability, cross-project/community scenario tests to ensure what we deliver to users will get higher quality and container-native support to make sure we provider useable Orchestration services for container environment. I believe in new features, so we will try to encourage more features and review them as many as possible, but will not plan for team feature goals unless we can trigger more discussion and hands-on.Thank you for taking my self-nomination into consideration. Rico Lin -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[election][kolla]
by Mark Goddard 31 Mar '20

31 Mar '20

Hi, I'd like to nominate myself to serve as the Kolla PTL for the Victoria cycle. I have been PTL for the Train and Ussuri cycles, and would like the opportunity to continue to lead the team. I am pleased with the current state of the project. We have an active community, produce interesting and useful features, and regularly receive positive feedback. The Kolla community has always been notable for being vendor-neutral and operator-driven. I recently made a proposal for a Kolla --SIG-- Club [1] with the aim of improving communication between regular contributors and the wider community. We had a good response, and I'm looking forward to seeing how it progresses this cycle. If elected this cycle I'd like to encourage continued work on some familiar themes - improving sustainability, increasing test coverage, and better integrating Kayobe [2]. I'd also like to see us focus on our documentation. Thanks for reading, Mark Goddard (mgoddard) [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013122.ht… [2] https://docs.openstack.org/kayobe

3 2

[Murano-Open-PaaS] Openstack using guacamole
by Roman Gorshunov 31 Mar '20

31 Mar '20

Hello Samuel, Thanks for your email. Yes, Guacamole can be installed as an app via Murano. Discussions about Open PaaS are now in openstack-discuss mailing list. Please use the tag [Murano-Open-PaaS] in the subject line. I'm re-routing your email. Here are docs for the Murano project [0]. [0] https://docs.openstack.org/murano/latest/ Best regards, Roman Gorshunov On Thu, Mar 26, 2020 at 4:37 PM Samuel Abdullah <samuel(a)silverliningsys.com> wrote: > Hi, > > Would like to ask if it is possible to run guacamole in openstack > environment? > Seek for help on how would this be possible as i saw that guacamole > component are part of the openstack in your murano project > > Looking forward for your reply > > Best Regards > > -- > > <https://www.silverliningsys.com/> > > www.silverliningsys.com > > > *Abu Bakar Samuel Abdullah* > > Cloud Infrastructure & Operations > > > P: +603-2712-0081 > > M: +60.12.654.5938 > > E: samuel(a)silverliningsys.com > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

3 4

[tc][elections] Nomination
by Belmiro Moreira 31 Mar '20

31 Mar '20

Greetings, I'd like to announce my candidacy for the OpenStack Technical Committee (TC). I'm involved with OpenStack since 2011 when CERN started to investigate a Cloud Infrastructure solution. I work in the design/deployment/operation of the CERN OpenStack Cloud. My particular interest has been how to scale and operate large OpenStack deployments. I was an active member of the old Large Deployment Team (LDT), a group of operators that shared ideas on how to scale OpenStack. I had the privilege to learn from a talented group of Operators on how they manage/run their infrastructures. Currently, a new group was created (Large Scale SIG) where I continue to have an active role. I'm fortunate enough to have attended most of the OpenStack Summits since San Francisco (2012). I'm a regular speaker talking about my experience operating OpenStack at scale. Also, I serve regularly as a track chair, participated in few OpenStack Days, Ops Meetups and wrote several blog posts. During the last year I served as a member of the OpenStack User Committee (UC). We focused in the Ambassador Program revamp and SIGs support. If elected I will focus to engage the Operator/Users community with the different Development teams and bring my experience as Developer/Operator to the group to help in the oversight on all the technical matters. It would be an honor to be an advocate of this great community and promote its mission. Thank you for your consideration, Belmiro Moreira

1 0

Add Masayuki Igawa candidacy for Quality_Assurance
by Masayuki Igawa 30 Mar '20

30 Mar '20

Hi everyone, I'd like to announce my candidacy as the PTL for the Quality Assurance PTL role for the Victoria cycle. First off, I would like to thank you all the contributors, core reviewers, PTLs, and anyone who involves and makes the OpenStack better. Let me introduce myself briefly. I have joined the OpenStack community since 2012 as a developer. Now, I'm a core member of some QA projects such as Tempest, os-testr, OpenStack-health, stackviz, coverage2sql, subunit2sql[1]. And I also played the mentors/instructors role at the upstream training in Japan several times. It was a great experience to know how difficult of telling people how OpenStack community is going. In the Ussuri cycle, we've almost completed "Drop Python 2.7 Support"[2] which is one of the Ussuri goals. We also have been trying to keep the gate stable which is the mission of the team. And we approved one interesting spec - "Whitebox Tempest Plugin"[3] which is one of the tempest plugins. It can access controller nodes and/or compute nodes such as read and write INI files, restart services, examine the database, etc. Tempest does not cover this feature because it isn't the scope. However, it is necessary to expand automated testing. We still have a few more planned work pending for Ussuri, such as removing/ migrating the .testr.conf to .stestr.conf, RBAC testing, removing tempest plugin sanity BLACKLIST, adding new glance tests, improving Tempest cleanup, etc. But I think we will be able to accomplish them in the Ussuri cycle as we still have around one month for Ussuri release. Along with daily QA activities, my priorities for QA for the next cycle will be: * New ideas for more tooling and/or tests project to focus on OpenStack or common communities. (whitebox tempest plugin, for example) * Stability of Tempest plugins. The sanity job is already voting, and there are 57 tempest plugins[4], but 12 plugins are in the blacklist. Some of the plugins are deprecated already, but it's hard to know from the registry page. It needs to be classified, and the page can be improved. * Guiding and motivating more contributors to QA projects, improving documentation, and advertising OpenStack QA projects. * Completing Ussuri priority items if it's still lasting. It's hard to accomplish without our collaboration. So, let's do it together! [1] http://stackalytics.com/?user_id=igawa [2] https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html [3] https://specs.openstack.org/openstack/qa-specs/specs/other/whitebox-tempest… [4] https://docs.openstack.org/tempest/latest/plugin-registry.html#detected-plu… Thanks for your consideration! -- Masayuki Igawa (masayukig)

1 1

[election][manila] PTL candidacy for Victoria
by Goutham Pacha Ravi 30 Mar '20

30 Mar '20

Greetings Zorillas & other Stackers, I would like to submit my candidacy to be the PTL of Manila for the Victoria cycle. I stepped up to this role for the Ussuri cycle and have had a tremendous learning experience. I achieved numerous things I set out to do with the support and encouragement of my fellow contributors. I'd like to continue in this role and drive the growth of this project and its community. In my role as the liaison for this community, I was able to effectively aid internalizing the "OpenStack way" of development. The project and its many deliverables saw several new contributors in the Ussuri cycle. This included successful Outreachy and Google Summer of Code interns who continue to contribute beyond the completion of their internships. We were able to prune the core maintainers group to active reviewers while mentoring and adding three new individuals. We also had a significant reduction in our bug backlog, while we continue to farm out issues for potential first time contributors. In the Victoria cycle, I plan to continue on this mission of growing the contributor base, and having Manila be a great on-boarding project for the OpenDev community. In the Ussuri cycle, thanks to our Outreachy interns, their mentors and the reviewers, we merged feature functionality to support the OpenStack Client. Similar velocity was achieved in the manila-csi project through the GSoC internship program and the continued investment beyond. We didn't get much merged in the Ussuri cycle in terms of improving the availability and fault tolerance of the core share-manager service. These multi-cycle work items will remain a matter of focus and I'd devote time to drive these further. The Ussuri cycle also saw reducing feature parity between the DHSS=True and DHSS=False driver modes. This was a goal for this community for several releases and it's coming to fruition through vendor-agnostic community driven design. In Victoria, we plan to continue down this patch and eliminate further feature gaps between many deployment and usability choices with Manila. As PTL, I will drive the community through the OpenStack-wide goals during the Victoria cycle, alongside some of our own: - Graduating experimental features: We have had significant soak time for all three features (Share Replication, Share Migration and Share Groups); and we have begun the steps to take them out of their experimental state. - Apply for the "vulnerability-managed" TC tag: As a community, we worked through our first CVE in Ussuri cycle with the aid and support from the OpenStack Vulnerability Management Team. In the Victoria cycle, we'll drive to achieve this TC tag for the project. - Evolve bug triage criteria, and automate it: Seeing an unmanageable number of bugs is a distraction enough to ignore the bug backlog. As a community we discussed the idea of automating some triage tasks on our backlog. - Address testing gaps: We'll continue to add new test case scenarios and address gaps such as the lack of scenario testing for the cephfs-native protocol. While this goal may not have a definition of done, it is here to convey my intention to prioritizing regression testing on par with feature development. So, if you will have me, I wish to serve through Victoria and get things done. Thank you for your support, Goutham Pacha Ravi <gouthampravi(a)gmail.com> IRC: gouthamr [1] https://review.opendev.org/#/c/716107/

1 0

[all] Virtualized PTG Brainstorming Community Meetings
by Kendall Nelson 30 Mar '20

30 Mar '20

Hello Everyone! So! After Marks initial email[1] that announced we would be virtualizing the PTG and collected volunteers[2] to help brainstorm the best way to hold the PTG virtually, we polled the volunteers for the best times to meet. In trying to be the most inclusive we have settled on three meetings to brainstorm together as a community. They are as follows: - April 2nd at 12:00 UTC - April 6th at 17:00 UTC - April 7th at 2:00 UTC We will be using my zoom[3] and continue using the same etherpad [2] that we collected volunteers in for all the notes from all three meetings. All are welcome! And if you can attend more than one meeting, please do! The more overlap we have the more cohesive discussions we will have. Hope to see you all there! -Kendall Nelson (diablo_rojo) [1] http://lists.openstack.org/pipermail/foundation/2020-March/002854.html [2] https://etherpad.openstack.org/p/Virtual_PTG_Planning [3] https://zoom.us/my/diablorojo

1 0

review.opendev.org Downtime March 20, 2020 at 1400UTC
by Clark Boylan 30 Mar '20

30 Mar '20

Hello all, The OpenDev team is planning to take a short downtime March 20, 2020 from 14:00UTC to 15:00UTC. This outage will enable us to rename a few projects and redeploy Gerrit using containers. The container based deployment is an important first step in our longer term plan for upgrading Gerrit to a modern version. We recognize that this will be a disruption during an already disrupted week for many. We feel this is worthwhile as it fits into project release schedules and sets us up well for the future. Thank you for your patience. Feel free to ask us any questions you may have on this thread or in #opendev on Freenode. Clark

4 5

[first contact][all] Meeting Frequency & Time
by Kendall Nelson 30 Mar '20

30 Mar '20

Hello Everyone, In our meeting yesterday[1], the first one of the year, we discussed changing our meeting frequency to once a month and maybe shifting the day/time. I think Tuesday still works for me but an hour or two earlier wouldn't go amiss. If no-one objects to this, I will put a patch up to change the meeting time & frequency next week to monthly instead of biweekly and -Kendall (diablo_rojo) [1] Meeting Log: http://eavesdrop.openstack.org/meetings/fc_sig/2020/fc_sig.2020-03-25-02.39… [2] Current Meeting Info: http://eavesdrop.openstack.org/#First_Contact_SIG_Meeting

1 1