- openstack-discuss - lists.openstack.org

[nova][ptl][election] Start the battle
by Jens Harbott 15 Mar '19

15 Mar '19

We are having two excellent PTL candidates now, making it very difficult for me - and probably others - to decide between them. So I would like to ask the candidates for some statements explaining why they would be the better PTL, lest the election ends up in a tie.

5 4

[nova][dev] Train community goals seeking review/feedback
by melanie witt 15 Mar '19

15 Mar '19

Hi all, As mentioned in the nova meeting today, the TC has two community goals proposed for the Train cycle, available for review and feedback from developers. Please take a look and add your comments to the reviews, if you're interested in helping decide our community goals for Train. * Project Deletion: https://review.openstack.org/639010 * Move legacy client CLIs to OSC: https://review.openstack.org/639376 Cheers, -melanie

1 0

Re: [Release-job-failures] Release of openstack/tripleo-ui failed
by Thierry Carrez 15 Mar '19

15 Mar '19

zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-javascript http://logs.openstack.org/b5/b5dbb90fb347db2876f61cae8c2623f9ce767dfe/relea… : POST_FAILURE in 6m 25s > - announce-release announce-release : SKIPPED Issue: ------ The release jobs for openstack/tripleo-ui failed while processing the recently-added 10.3.0 tag. The upload-npm task failed with: The task includes an option with an undefined variable. The error was: "hostvars['ubuntu-xenial']" is undefined The error appears to have been in '/var/lib/zuul/builds/83dee2d5710f427583d21e5f49a4c186/trusted/project_1/git.openstack.org/openstack-infra/zuul-jobs/roles/upload-npm/tasks/main.yaml': line 15, column 3, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - name: Upload tarball to npm ^ here This is likely due to the transition to ubuntu-bionic servers. Impact: ------- The 10.3.0 tarball was never copied to tarballs.openstack.org, and it was not uploaded to NPM either. Once the issue is resolved we should probably re-enqueue that reference to re-trigger the job. -- Thierry Carrez (ttx)

2 3

[baremetal-sig][ironic] Bare metal logo program
by Chris Hoge 15 Mar '19

15 Mar '19

Hi, We're looking at launching a new bare metal logo program, and we'd like some feedback from the baremetal-sig on how it's implemented and if there's interest in participating in it. This is an early draft of the proposal for community community feedback, and isn't our final plan. This program has several goals. Raising awareness of Ironic as it's being used in production is one of them. This will highlight how Ironic is being used and also serve as a introduction to organizations that are considering tools to manage their bare metal infrastructure. This will also help to help to change the mind-set from OpenStack being a virtualization-focused platform to being a general infrastructure management platform. Ironic is an excellent example of OpenStack software being applicable across a variety of different use cases, like container infrastructure, high-performance computing, and network functions. At a high level anyone in the community who is using Ironic for managing bare-metal services would qualify for it. This would cover a variety of cases, including but not limited to: * Distributions that ship Ironic. * Deployment tools and private clouds that use Ironic to manage servers. * Public clouds that resell bare-metal clouds. * Any private cloud that is using Ironic to manage their bare metal infrastructure, whether end-user facing or not. * Really, any production use of Ironic in any form. As part of the program we will have a bare-metal landing page that links out to the white paper, other documents related to Ironic, participants in the logo program, and links to case studies provided by the participants. The Foundation will also promote how participants in the program are using Ironic through their provided case studies through our various channels. Any vendor who has a marketplace listing will have the bare metal logo applied to that listing. Our major two requirements for participation are that: * You're actually using Ironic or providing software or services based on Ironic. * You provide a relatively short (500-1000 word) use case describing a real-world application (we'd prefer that it not just be a marketing brochure, but something that really highlights how Ironic is being used in production). We would also like for this content to be built into the white paper, as we've seen a demand for case studies in previous publications. If we go forward with the program we plan to launch at the upcoming Open Infrastructure Summit in Denver and highlight the early participants in the program. As the year goes on we'll continue to promote Ironic usage and will always welcome new participants. There are two ways that you can help out right now. The first is just in giving us feedback on this proposal. The second is for you to contact me directly if you would like to be one of the founding participants in the program. Thanks in advance to everyone for your feedback and participation! -Chris

1 1

Re: [Release-job-failures] Release of openstack/governance failed
by Thierry Carrez 14 Mar '19

14 Mar '19

zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-python http://logs.openstack.org/21/21a5154f6a4d1c317d7b2fe084ecd919ed8cb93e/relea… : POST_FAILURE in 3m 54s > - announce-release announce-release : SKIPPED > - propose-update-constraints propose-update-constraints : SKIPPED Issue: ------ The release jobs for openstack/governance failed while processing the recently-added 0.4.0 tag. During collection of the built artifacts, the following command: /usr/bin/rsync --delay-updates -F --compress --archive --rsh=/usr/bin/ssh -S none -o Port=22 --out-format=<<CHANGED>>%i %n%L zuul@104.130.6.123:/home/zuul/zuul-output/artifacts/ /var/lib/zuul/builds/16d67fd9d85342bfabfd82292183e76c/work/artifacts/ failed host key verification: ED25519 host key for 104.130.6.123 has changed and you have requested strict checking. Impact: ------- The 0.4.0 tarball was never copied to tarballs.openstack.org, and it was not uploaded to Pypi either. Once the issue is resolved we should either re-enqueue that reference to re-trigger the job, or push a 0.4.1. -- Thierry Carrez (ttx)

2 2

[requirements][FFE][ironic] Stein release freeze exception for Sushy
by Dmitry Tantsur 14 Mar '19

14 Mar '19

Hi all, It came to our attention that rsd-lib is pinning sushy to 1.7.0 [1] because of the issue in the latest 1.8.0 release. This is causing troubles for packagers [2]. I'm proposing releasing 1.8.1 [3] to unblock them. Thanks, Dmitry [1] https://github.com/openstack/rsd-lib/commit/e3a061f4d2bf70e3a2f9411f810d328… [2] https://bugs.launchpad.net/python-rsdclient/+bug/1820032 [3] https://review.openstack.org/#/c/643258/

2 3

[nova] Does anyone remember why server_group_members quota is enforced at the user rather than project level?
by Matt Riedemann 14 Mar '19

14 Mar '19

Change [1] in Juno added the server_groups and server_group_members quotas. Server group quota is counted per project and user [2]. Server group member quota is only counted per group and user [3]. The question coming up in IRC today is why is the server group member count not also constrained by project? Or is project implied since the member count is within the scope of a group, which is itself per-project? Note that the original change that added these quotas said, "They can be defined per project or per user within a project". Given none of the people that originally added this are around still maintaining it, nor was there a spec (we didn't have specs in Juno), we're left to guess as to the reasons. If we changed the server_group_members quota enforcement to count per group/project/user, would that break anything? [1] https://review.openstack.org/#/c/104957/ [2] https://github.com/openstack/nova/blob/caa37cf099933c5aed02dcdb256055e18479… [3] https://github.com/openstack/nova/blob/caa37cf099933c5aed02dcdb256055e18479… -- Thanks, Matt

7 6

[cinder][os-brick] hold recheck for cinder and os-brick
by Rajat Dhasmana 14 Mar '19

14 Mar '19

Hi All, Due to legacy jobs migration to bionic, we're facing a gate failure in cinder's cinder-tempest-dsvm-lvm-lio-barbican job and os-brick's legacy-tempest-dsvm-full-lio-src-os-brick and os-brick-cinder-tempest-dsvm-lvm-lio-barbican jobs. A workaround is proposed[1] and soon will be merged. Kindly avoid any recheck in cinder and os-brick until then. [1] https://review.openstack.org/#/c/643130/

1 0

[placement] cycle-highlights for stein required
by Chris Dent 14 Mar '19

14 Mar '19

Placement contributors, One of the things that should be done alongside placement having a Stein release is the creation of cycle highlights [1]. I've created an etherpad [2] to get us started, including links to more information and some examples. Please add to it. I'll refine it to something presentable and make the appropriate patch. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003597.ht… [2] https://etherpad.openstack.org/p/stein-placement-cycle-highlights -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[oslo] admin-ness not properly scoped and oslo.policy current status about this issue
by Herve Beraud 14 Mar '19

14 Mar '19

Hello ## Overview I want to bring up this topic (admin-ness not properly scoped)[1] to get a big picture of the state of this issue and that was needed on the oslo.policy side. Few weeks ago some RHOSP customers request for an enhancement of oslo.policy since their admin domain can manage other domains. They use OSP13. The goal of this ML thread is to help us to track informations about this topic and I also planned to discuss about this topic during the next oslo meeting (Monday 18 of March). ## Details After some investigations I've found a lot of related issues on launchpad[1][2][3], and a lot of disucssions inside the openstack community about this topic. First I guess it's not an RFE but it's a known issue. This bug has side-effects across several services, not just oslo or keystone, making the fix complex to orchestrate across services. In a first time, I want to know more about the latest events on this topic on the oslo side: - the states of the related specs ( https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope… ). - if we need to add more changes to completely fix this issue and/or if everything is complete on the oslo side and know since which version. I guess this one[4] is related to. Also due to the complexity of this issue I guess is not totally fixed on the whole openstack components on stein and it can't be fully (whole) backported to stable branches, but your point of view is really appreciate. In other words I guess some parts are already fixed on some components but some services still need to be fixed and the issue partially occur on stein, so fix that on stable branches is not really possible, can you confirm? Also I've found few related specs that I guess can be useful to track the evolution: - https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/c… - https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/d… - https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/… - https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope… If I missed something useful do not hesitate to reply on and to share it with us. [1] https://bugs.launchpad.net/keystone/+bug/968696 [2] https://bugs.launchpad.net/keystone/+bug/1783659 [3] https://bugs.launchpad.net/nova/+bug/1649532 [4] https://bugs.launchpad.net/oslo.policy/+bug/1577996 -- 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-----

3 4