- openstack-discuss - lists.openstack.org

[requirements] freeze
by Matthew Thode 09 Mar '19

09 Mar '19

No puns this time With R-5 done this week requirements is now in a freeze. If you want to seek an exception please email this list (openstack-discuss) with '[requirements][FFE]' prepended to your subject line. In the body please explain why you need this exception and any projects that the change will impact that you know. -- Matthew Thode

1 0

[tc] forum planning
by Doug Hellmann 09 Mar '19

09 Mar '19

It's time to start planning the forum. We need a volunteer (or 2) to set up the etherpad and start collecting ideas for sessions the TC should be running. Who wants to handle that? -- Doug

2 3

[election][openstack-ansible] candidacy
by Mohammed Naser 09 Mar '19

09 Mar '19

I'd like to announce my candidacy for OpenStack Ansible PTL. Over the past cycle, we've made a lot of forward progress in improving the stability of our gate, aiming at making our roles much more linear and improving deploy times. There's still a lot more work to be done, and there's a lot less resources available to get the work done with. Therefore, I think the upcoming cycle should be strongly focused on increasing stability, this would be done by looking at the following - Simplifying scenarios for usage and testing - Using integrated repository for testing and dropping role tests - Progress on switching all deployments to use Python3 - Eventual addition of CentOS 8 option - Reduction in number of config variables (encouraging overrides) - Increase cooperation with other deployment projects (i.e. TripleO) I would like us to aim at a cycle where we stabilize things and make sure that things chug along smoothly. This will help reduce our overhead and allow us to focus on the stability and robustness of the deployment project as I believe that at this point, there's not much more 'features' to be added in the deployment tool. In doing this, we should hopefully drive down the time of deployment and increase the reliability of the deployment. Thank you for your consideration. -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 1

[ptl][barbican][election]
by Douglas Mendizabal 09 Mar '19

09 Mar '19

I would like to announce my candidacy to serve as Barbican PTL for the Train cycle. I've been involved in the Barbican project since its inception, and I have previously had the opportunity to serve as PTL for the Kilo through Newton cycles. With Ade Lee stepping down as PTL at the end of the Stein cycle, I think it is a good time for me to serve as PTL once again. My goals for the Train cycle are to continue to improve the usability of the various projects under the Barbican umbrella (especially python- barbicanclient) as well as continue to improve quality through more and better testing. Thank you, Douglas Mendizábal

1 0

[puppet] PTL non-candidacy
by Tobias Urdin 08 Mar '19

08 Mar '19

Hello, I'm announcing that I won't be running for PTL of the Train release cycle for the Puppet OpenStack project. Due to changes at work I cannot facilitate having my mind exclusively on OpenStack for the upcoming six months and I would love to see more involvement and new perspectives surrounding the Puppet OpenStack project. I won't go nowhere though! My personal (and professional) involvement in OpenStack is bigger than ever and I'm looking forward to another cycle with more existing work. I will keep being a core and review and commit changes as much as I can. I feel proud of our achivements this cycle, my personal feeling is that we've got more momentum and it's been really great seeing people stepping up and commiting new features, improvements, bug fixes and all the cleanup of removed configuration options and technical depth that we've had for so many releases. I would love to come back to the PTL role in the future, if you would have me. Thanks to all of the people that I've interacted with, and not least all of you out there doing any work in the OpenStack scope. Remember that you are all awesome :) If you've read this far, please bare with me. I just wanted to give a brief recap on what we've achieved, together, this cycle. * Remove and/or deprecated hundreds of configuration options that either did nothing or was already removed from projects * Removed the keystone related auth_uri option for www_authenticate_uri * Started work to minimize the dependencies between classes that is the main cause for duplicate declarations * Fixed structure of all modules to conform with Puppet standards * Added Ubuntu Stein support (python3 only!) * Publishing all modules to Puppetforge automatically (shoutout for Infra and release team for the huge help here!) * Moved keystone to port 5000 only, changed all v2.0 to v3 references, deprecated all paste and PKI related code * Move almost all testing to rspec-puppet-facts (only puppet-keystone left) * Started work moving away from non-Apache licensed Puppet modules * Added new puppet-placement module, deprecated deploying placement from puppet-nova * Converted all Puppet parser functions to Puppet 4 API functions * puppet-nova deprecated cells v1, Support native TLS for migration and disks over NBD * Apache WSGI support for Sahara, Octavia, Nova metadata API * Deprecated Puppet 4 support, added Puppet 6 support * All testing uses Ubuntu Bionic or CentOS 7 And a lot more! Lastly, to anybody that is considering running for PTL I stongly encourage you to run. To anybody; I'm always available on IRC for feedback, questions or if you just want to say hello or chat about something. Best regards Tobias (tobias-urdin on IRC)

3 2

[kolla][magnum] Unable to create a PersistentVolumeClaim with Cinder backend
by Giuseppe Sannino 08 Mar '19

08 Mar '19

Hi all, I would need your help. As per the subject, I'm trying to create a PersistentVolumeClaim using Cinder as backend on a K8S cluster I deployed via Magnum, but I'm not able to. I think I'm hitting one or two issues (not sure if the second depends on the first). Here is the story. *>Background<* I managed to deploy a K8S cluster using Magnum and I can also create POD or any other K8S "entity" except persisten volumes and/or claims. Configuration: kolla-ansible: 7.0.1 OS Release: Rocky Base Distro: CentOS I applied the WA as per https://review.openstack.org/#/c/638400/ (a previous issue I found) so K8S cluster is working fine. *> PROBLEM <* I've created the following storageClass: kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: standard provisioner: kubernetes.io/cinder parameters: type: fast availability: nova NOTE: I'm trying to use Cinder as backend. NOTE2: I tried with an hostPath and I have no issue. I then tried to create a PersistentVolumeClaim linking the above StorageClass. kind: PersistentVolumeClaim apiVersion: v1 metadata: name: cinder-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: standard2 It stays in "Pending" state forever. I had a look at the "kube-controller-manager.service" log and found the following: -------- Mar 08 14:25:21 kube-cluster-march-ppqfakx76wsm-master-0.novalocal runc[3013]: I0308 14:25:21.017065 1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"cinder-claim", UID:"ea41e0ac-41ad-11e9-8ffc-fa163e9b393f", APIVersion:"v1", ResourceVersion:"112059", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' Failed to provision volume with StorageClass "standard2": OpenStack cloud provider was not initialized properly : stat /etc/kubernetes/cloud-config: no such file or directory -------- *>>> ISSUE 1 <<<* It seems like that service expects the cloud provider configuration to be in the "cloud-config" file which does not exist. As *workaround*, I created that file and copied the content of "kube_openstack_config" which is: [Global] auth-url=http://10.1.7.201:5000/v3 user-id=eed8ce6dd9734268810f3c23ca91cb19 password=M3rE6Wx9sTB94BQD2m trust-id= ca-file=/etc/kubernetes/ca-bundle.crt region=RegionOne [LoadBalancer] use-octavia=False subnet-id=8c9e0448-2d40-449f-a971-e3acde193678 create-monitor=yes monitor-delay=1m monitor-timeout=30s monitor-max-retries=3 [BlockStorage] bs-version=v2 *>>> ISSUE 2 <<<* Checking again the log of the "kube-controller-manager.service" service I can see this time: Mar 08 14:29:21 kube-cluster-march-ppqfakx76wsm-master-0.novalocal runc[3013]: I0308 14:29:21.403038 1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"cinder-claim", UID:"ea41e0ac-41ad-11e9-8ffc-fa163e9b393f", APIVersion:"v1", ResourceVersion:"112059", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' Failed to provision volume with StorageClass "standard2": unable to initialize cinder client for region: RegionOne, err: unable to initialize cinder v2 client for region RegionOne: No suitable endpoint could be found in the service catalog. >From Openstack I see: root@hce03:~# openstack endpoint list | grep keystone | 011e5905a4a04e348b3fd1d3d1a1ab09 | RegionOne | keystone | identity | True | public | http://10.1.7.201:5000 | | 0fb51c8e0edb45839162a1afe412f9f7 | RegionOne | keystone | identity | True | internal | http://10.1.7.200:5000 | | 34c269a31260459fbd2c0967fda55b1d | RegionOne | keystone | identity | True | admin | http://10.1.7.200:35357 | root@hce03:~# openstack endpoint list | grep cinder | 55b109ed383c4705b71c589bdb0da697 | RegionOne | cinderv3 | volumev3 | True | admin | http://10.1.7.200:8776/v3/%(tenant_id)s | | 6386e4f41af94c25ac8c305c7dbc1af4 | RegionOne | cinderv3 | volumev3 | True | public | http://10.1.7.201:8776/v3/%(tenant_id)s | | 78e706cd0cd74a42b43adc051100b0bc | RegionOne | cinderv2 | volumev2 | True | admin | http://10.1.7.200:8776/v2/%(tenant_id)s | | 83a7da1e426f4aa4b5cac3f4a564f480 | RegionOne | cinderv3 | volumev3 | True | internal | http://10.1.7.200:8776/v3/%(tenant_id)s | | a322b3442a62418098554d23ae6a1061 | RegionOne | cinder | volume | True | public | http://10.1.7.201:8776/v1/%(tenant_id)s | | c82a65eb60cc49348397085233882ba1 | RegionOne | cinder | volume | True | internal | http://10.1.7.200:8776/v1/%(tenant_id)s | | cf2e6d9cb6b640ea876c9f5fe16123d3 | RegionOne | cinderv2 | volumev2 | True | public | http://10.1.7.201:8776/v2/%(tenant_id)s | | e71733a7dbb94a69a44d03ee14389eb5 | RegionOne | cinderv2 | volumev2 | True | internal | http://10.1.7.200:8776/v2/%(tenant_id)s | | e9add20fea3c4d57b2a752832455f6f1 | RegionOne | cinder | volume | True | admin | http://10.1.7.200:8776/v1/%(tenant_id)s | >From the Kube Master I checked whether or not the auth_url, as per the cloud-config is reachable, and it is: [root@kube-cluster-march-ppqfakx76wsm-master-0 kubernetes]# curl http://10.1.7.201:5000/v3 {"version": {"status": "stable", "updated": "2018-10-15T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.11", "links": [{"href": "http://10.1.7.201:5000/v3/", "rel": "self"}]}} I also tried to change the block storage version from "v2" to "v1" or "v3". Again the same error. May I ask some support on this ? Many thanks! BR /Giuseppe

1 0

[dev][keystone] Keystone Team Update - Week of 4 March 2019
by Colleen Murphy 08 Mar '19

08 Mar '19

# Keystone Team Update - Week of 4 March 2019 ## News ### PTL Elections PTL election season is upon us. Lance has announced he will be stepping down[1], so if you would like to take on the role please submit your self-nomination by next Tuesday[2]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003421.ht… [2] https://governance.openstack.org/election/ ### Ops Meetup Summary I attended the operators meetup in Berlin this week and ended up moderating a session on keystone. We didn't uncover many big surprises, though I was pleased to realize that keystone is commonly used as an identity provider in front of services like Openshift or Ceph RadosGW. See the session notes[3] for other takeaways. [3] https://etherpad.openstack.org/p/BER19-OPS-KEYSTONE-FEEDBACK ### Forum Proposals We proposed four forum sessions already[4]. The submission deadline is today, so if you have other keystone-related session ideas, submit them today. [4] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions ### RBAC Work Lance summarized the state of the system-scope and reader-role work to date[5]. We made a ton of progress this cycle but we still have more work to do within keystone continuing into next cycle. [5] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003552.ht… ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 27 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 24 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 10 new bugs and closed 1. Most of these are new bugs tracking the remaining default roles work that we hadn't captured before. One interesting one (#1819036) is about the performance of token validation[6], where we seem to be duplicating some effort. Bugs opened (10) Bug #1819036 (keystone:High) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1819036 Bug #1818725 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818725 Bug #1818736 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818736 Bug #1818844 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818844 Bug #1818732 (keystone:Low) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818732 Bug #1818734 (keystone:Low) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818734 Bug #1818744 (keystone:Low) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818744 Bug #1818846 (keystone:Low) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818846 Bug #1818850 (keystone:Low) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818850 Bug #1818845 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818845 Bugs fixed (1) Bug #1804462 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804462 [6] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Milestone Outlook https://releases.openstack.org/stein/schedule.html Feature freeze and final client release is this week. We already did our final client release last week and merged the last of our planned feature work on Monday (or agreed to push it to next cycle, in the case of app cred access rules). This week is also the soft string freeze[7], so please do not accept changes to user-facing strings after today until next cycle opens. [7] https://releases.openstack.org/stein/schedule.html#s-soft-sf ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[ptl][charms][election] PTL candidacy
by James Page 08 Mar '19

08 Mar '19

Hi All After taking a PTL break for the Stein cycle I'd like to announce my candidacy for PTL of the OpenStack Charms project for the Train cycle (see [0]). Under Frode's leadership the project has made some great steps forward during the Stein cycle; specifically we've made good progress on Python 3 adoption with the majority of charms now using Py3 for charm execution, and a large number of the OpenStack projects we deploy running under Python 3 as of the Rocky release. This is important work bearing in mind the limited amount of Py2 lifetime left and something I want to ensure we complete during the upcoming cycle. We might still have a few bumps to get through but I think we know the gaps and it should be achievable. We have also made some great progress on removing our dependence on legacy charm tooling such as Amulet; Zaza is a great step forward providing us with a much cleaner codebase for sharing and executing tests across the charms. Again we need to tick off the last few stragglers and get our charm gating up to spec across the board in the upcoming cycle. A number of charm users have been attempting to deploy the OpenStack Charms using some of the new Juju cross-model relation features. This is a somewhat bumpy experience right now with various issues which block full use - I'd like to focus on identifying the common use cases for using multiple models and ensure we have test coverage for these use cases in our regular charm testing so we can resolve any immediate issues and make sure we don't cause regressions going forward. As always I'm sure there will be new and interesting features to expose across the OpenStack Charms and I look forward to helping steer the project for the next 6 months. See you all in Denver! Cheers James [0] https://review.openstack.org/#/c/641999/

1 0

[charms] PTL Non-Candidacy
by Frode Nordahl 08 Mar '19

08 Mar '19

Hello all, The Stein cycle is coming to a 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 cycle. I believe rotating leadership for open source projects is a good thing and I am happy to pass on the relay baton for the Train cycle. -- Frode Nordahl

1 0

[ptl][kolla][election] Mark Goddard PTL candidacy
by Mark Goddard 08 Mar '19

08 Mar '19

Hi, I'd like to nominate myself to serve as the Kolla PTL for the Train cycle. I've been a user and developer of Kolla and Kolla Ansible since 2016 - initially while at Cray, but my upstream contribution really started in earnest when I joined StackHPC two years ago. I became core in May last year. I am passionate about this particularly operator-driven and community-led project, and started the Kayobe [1] project that allows deployment of an OpenStack control plane to bare metal using Kolla, Kolla Ansible and Bifrost. The flip side of being an operator-driven project is that contributors come and go, and even regular contributors don't always have as much time as they might like. That said, the project is very much alive in terms of code and review contributions. I'd like to help those on the periphery of the project to get more involved. Kolla is also a very global project, with many contributors in Asia particularly. This is really healthy, and I'd like to try out a more APAC-friendly IRC meeting time and a virtual PTG to keep everyone involved. I'm lucky enough to also be an Ironic core (I don't intend for that to change if elected Kolla PTL), and it's been interesting to compare how these two quite different projects operate. The Ironic team does a great job of planning and tracking their work, making use of a whiteboard [2]. I'd like to try adopting a lightweight version of some of these practices in Kolla. As the project matures, stability becomes increasingly important. This is particularly true for the images, which are used by multiple projects. We've been working on improving our CI testing this cycle, but still have a way to go. I want to make sure that work continues, to ensure we can continue to make changes with confidence, whatever the hype cycle throws at us. Thanks for reading, Mark Goddard (mgoddard) [1] https://kayobe.readthedocs.io [2] https://etherpad.openstack.org/p/IronicWhiteBoard

1 0