The content below is taken from the original (OpenStack Developer Mailing List Digest March 11-17), to continue reading please visit the site. Remember to respect the Author & Copyright.

SuccessBot Says

Dims [1]: Nova now has a python35 based CI job in check queue running Tempest tests (everything running on py35)
jaypipes [2]: Finally got a good functional test created that stresses the Ironic and Nova integration and migration from Newton to Ocata.
Lbragstad [3]: the OpenStack-Ansible project has a test environment that automates rolling upgrade performance testing
annegentle [4]: Craig Sterrett and the App Dev Enablement WG: New links to more content for the appdev docs [5]
jlvillal [6]: Ironic team completed the multi-node grenade CI job
Tell us yours via OpenStack IRC channels with message “#success <message>”

Pike Release Management Communication

The release liaison is responsible for:
- Coordinating with the release management team.
- Validating your team release team requests.
- Ensure release cycle deadlines are met.
- It’s encouraged to nominate a release liaison. Otherwise this tasks falls back to the PTL.
Ensure the releaase liaison has time and ability to handle the communication necessary.
- Failing to follow through on a needed process step may block you from meeting deadlines or releasing as our milestones are date-based, not feature-based.
Three primary communication tools:
- Email for announcements and asynchronous communication
  - “[release]” topic tag on the openstack-dev mailing list.
  - This includes the weekly release countdown emails with details on focus, tasks, and upcoming dates.
- IRC for time sensitive interactions
  - With more than 50 teams, the release team relies on your presence in the freenode #openstack-release channel.
- Written documentation for relatively stable information
  - The release team has published the schedule for the Pike cycle [8]
  - You can add the schedule to your own calendar [9]
Things to do right now:
- Update your release liaisons [10].
- Make sure your IRC and email address listed in projects.yaml [11].
Update your mail filters to look for “[release]” in the subject line.
Full thread [12]

“Forum” proper
- 3 medium sized fishbowl rooms for cross-community discussions.
- Selected and scheduled by a committee formed of TC and UC members, facilitated by the Foundation staff members.
- Brainstorming for topics [20]
“On-boarding” rooms
- Two rooms setup classroom style for projects teams and workgroups who want to on-board new team members.
- Examples include providing introduction to your codebase for prospective new contributors.
- These should not be tradiitonal “project intro” talks.
Free hacking/meetup spaces
- Four to five rooms populated with roundtables for ad-hoc discussions and hacking.
Full thread [21]

Created early 2015 as a market place of pre-packaged applications [22] that you can deploy using Murano.
This has grown to 45 Glance images, 13 Heat templates and 6 Tosca templates. Otherwise did not pick up a lot of steam.
~30% are just thin wrappers around Docker containers.
Traffic stats show 100 visits per week, 75% of which only read the index page.
In parallel, Docker developed a pretty successful containerized application marketplace (Docker Hub) with hundreds or thousands regularly updated apps.
- Keeping the catalog around makes us look like we are unsuccessfully trying to compete with that ecosystem, while OpenStack is in fact complimentary.
In the past, we have retired projects that were dead upstream.
- The app catalog is however has an active maintenance team.
- If we retire the app catalog, it would not be a reflection on that team performance, but that the beta was arguably not successful in build an active market place and a great fit from a strategy perspective.
Two approaches for users today to deploy docker apps in OpenStack:
- Container-native approach using “docker run” after using Nova or K8s cluster using Magnum.
- OpenStack Native approach “zun create nginx”.
Full thread [23][24]

Devstack defaults to ZooKeeper and is opinionated about it.
Lots of container related projects are using etcd [25], so do we need to avoid both ZooKeeper and etcd?
For things like databases and message queues, it’s more than time for us to contract on one solution.
- For DLMs ZooKeepers gives us mature/ featureful angle. Etcd covers the Kubernetes cooperation / non-java angle.
OpenStack interacts with DLM’s via the library Tooz. Tooz today only supports etcd v2, but v3 is planned which would support GRPC.
The OpenStack gate will begin to default to etcd with Tooz.
Full thread [26]

An etherpad [27] has been started to begin tackling the new language requirements [28] for Go.
An golang-commons repository exists [29]
Gopher cloud versus having a golang-client project is being discussed in the etherpad. Regardless we need support for os-client-config.
Full thread [30]

Guidelines under review:
- Add API capabilities discovery guideline [31]
- Refactor and re-validate API change guidelines [32]
- Microversions: add next_min_version field in version body [33]
- WIP: microversion architecture archival doc [34]
Full thread [35]

Castellan is a python abstraction to different keymanager solutions such as Barbican. Implementations like Vault could be supported, but currently is not.
The rename would emphasize the Castellan is an abstraction layer.
- Similar to oslo.db supporting MySQL and PostgreSQL.
Instead of oslo.keymanager, it can be rolled into the oslo umbrella without a rename. Tooz sets the precedent of this.
Full thread [36]

Focus:
- Specification approval and implementation for priority features for this cycle.
Actions:
- Teams should research how they can meet the Pike release goals [37][38].
- Teams that want to change their release model should do so before end of Pike-1 [39].
Upcoming Deadlines and Dates
- Boston Forum topic formal submission period: March 20 – April 2
- Pike-1 milestone: April 13 (R-20 week)
- Forum at OpenStack Summit in Boston: May 8-11
Full thread [40]

Mission: To collaborate on best practices for deploying and configuring OpenStack in production environments.
Examples:
- OpenStack Ansible and Puppet OpenStack have been collaborating on Continuous Integration scenarios but also on Nova upgrades orchestration
- TripleO and Kolla share the same tool for container builds.
- TripleO and Fuel share the same Puppet OpenStack modules.
- OpenStack and Kubernetes are interested in collaborating on configuration management.
- Most of tools want to collect OpenStack parameters for configuration management in a common fashion.
Wiki [41] has been started to document how the group will work together. Also an etherpad [42] for brainstorming.