- openstack-discuss - lists.openstack.org

[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

[KOLLA] DPDK deployed by default?
by Manuel Sopena Ballesteros 14 Mar '19

14 Mar '19

Dear Openstack/Kolla community, I just realised that DPDK is installed on my compute nodes however I didn't enabled it? [root@openstack-deployment ~]# grep -i "dpdk" /etc/kolla/globals.yml #enable_ovs_dpdk: "no" [root@openstack-deployment ~]# pip freeze | grep -i kolla kolla==7.0.0 kolla-ansible==7.0.0 [root@zeus-53 ~]# docker exec -it openvswitch_vswitchd ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.9.0 DPDK 17.11.0 Is this by default? Thank you NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

3 2

[vitrage] Nominating Muhamad Najjar for Vitrage core
by Ifat Afek 14 Mar '19

14 Mar '19

Hi, I would like to nominate Muhamad Najjar for Vitrage core. Muhamad joined Vitrage a year and a half ago. During this time, he worked on several important tasks, including the Vitrage persistor and the Prometheus datasource. Muhamad has an extensive knowledge in Vitrage and I’m sure he would make a great addition to our team. Thanks, Ifat.

1 0

[nova] hold recheck for nova-next job failing and workaround is about to merge
by Ghanshyam Mann 14 Mar '19

14 Mar '19

Hi All, Due to legacy jobs migration to Bionic, you will see nova-next jobs failing on gate, Hold the recheck until this workaround is merged - https://review.openstack.org/#/c/643129/ -gmann

1 3

[tc][ptl][quality-assurance][infra] Switching default node type to ubuntu-bionic
by Jeremy Stanley 14 Mar '19

14 Mar '19

We've committed to testing[*] on Ubuntu 18.04 LTS (Bionic Beaver) by the Stein release, but it's nearly upon us and we still have quite a few jobs, particularly Python 2.7 unit tests for most projects, running on older Ubuntu 16.04 LTS (Xenial Xerus) images instead. I propose that next Wednesday, March 13, we update the default node type in our Zuul job configurations from ubuntu-xenial to ubuntu-bionic for master branches of our projects. Note that most projects are already running Python 3.6 unit testing which happens on ubuntu-bionic images and DevStack/Tempest testing is already happening on ubuntu-bionic as well, so the switch for any job definitions not calling an explicit node type should be a non-event. Nevertheless, I wanted to start a brief discussion on the list as we are coming close to RC target week and it would be good to have the cut-over happen before then as some projects may not see any additional changes in Stein after their first RC tag. [*] https://governance.openstack.org/tc/reference/runtimes/stein.html -- Jeremy Stanley

3 9

[congress][i18n][octavia][powervmstackers][telemetry][zaqar] Missing PTL candidates, only 5 hours remaining
by Jeremy Stanley 13 Mar '19

13 Mar '19

Calling all contributors to these 6 projects: Congress I18n Octavia PowerVMStackers Telemetry Zaqar There are just 5 hours remaining in the candidate nomination period for the "Train" cycle PTL election. If you want to make sure the OpenStack Technical Committee doesn't need to take special action due to lack of a candidate and are willing to lead your team through the upcoming development cycle, please don't delay in following our instructions to nominate yourself: https://governance.openstack.org/election/#candidates -- Jeremy Stanley

5 10

Glance with Swift backend specify CACERT
by Vladislav Kuzmin 13 Mar '19

13 Mar '19

I found this comments in devstack https://github.com/openstack-dev/devstack/blob/master/lib/glance#L180-L181 and I'm trying to reproduce this not implemented behavior. I installed devstack with the following local.conf file: > [[local|localrc]] > ADMIN_PASSWORD=supersecret > DATABASE_PASSWORD=$ADMIN_PASSWORD > RABBIT_PASSWORD=$ADMIN_PASSWORD > SERVICE_PASSWORD=$ADMIN_PASSWORD > enable_service tls-proxy > enable_service s-proxy s-object s-container s-account > SWIFT_REPLICAS=1 > SWIFT_HASH=1234123412341234 > USE_PYTHON3=True > HOST_IP=10.0.2.15 After that I changed http to https in /etc/glance/glance-swift-store.conf for auth_address and restarted g-api service. After that I upload an image, but everything working good. Does anybody know how to reproduce it?

1 0