OpenStack Developer Mailing List Digest July 22-28


  • Nova placement/resource providers update 30 1
  • TC Report 30 2
  • POST /api-wg/news 3
  • Release countdown for week R-4, July 28 – Aug 4 4
  • Technical Committee Status update, July 28 5

Project Team Gathering Planning

  • Nova 6
  • Keystone 7
  • Sahara 8
  • Cinder 9
  • Oslo 10
  • Neutron 11
  • Documentation 12

Oslo DB Network Database Base namespace throughout OpenStack Projects

  • Mike Bayer has been working with Octave Oregon on adding the network database storage engine for mysql to oslo.db module so other projects can take advantage of it. Mike Bayer notes:
    • The code review 13
    • Support in Nova 14
    • Support in Neutron 15
  • New data types that map to types from the NDB namespace.
    • oslo_db.sqlalchemy.types.SmallString
    • oslo_db.sqlalchemy.types.String
  • Full thread: 16

User Group Newsletter – July 2017

Sydney Summit

We’re getting excited as the Sydney Summit draws closer. Don’t miss out on your early bird tickets, sales end September 1. Find your Summit pocket guide hereIt includes information about where to stay, featured speakers, a Summit timeline, the OpenStack Academy and much more.

An important note regarding travel. All non-Australian residents will need a visa to travel to Australia (including United States citizens). Click here for more information 

Travel Support Program

Need some support to make the trip? You can apply for the Travel Support ProgramSuperuser has a great article with handy tips to help you complete your application. Find the Superuser article here. 

Superuser Awards

The Superuser Awards recognize teams using OpenStack to meaningfully improve business and differentiate in a competitive industry, while also contributing back to the community. Nominations for the OpenStack Summit Sydney Superuser Awards are open and will be accepted through midnight Pacific Time September 8. Find out more information via this Superuser article. 

User Survey

Make your voice heard in the User survey. It’s available in 7 languages (Chinese (traditional & simplified), Japanese, Korean, German, Indonesian). Submissions close on the 11th of August. Complete it here. 

User Committee Elections

The User Committee Elections are right around the corner. Active user contributors (AUCs) — including operators, contributors, event organizers and working group members, are invited to apply. Nominations open July 31 and close on August 11th. Find out all you need know with this Superuser article. 

Boston Summit recap

We hope you all enjoyed the Boston Summit in May. Catch up on the sessions you weren’t able to see, via the OpenStack Foundation’s YouTube channel.

Certified OpenStack Administrator exam

OpenStack skills are in high demand as thousands of companies around the world adopt and productize OpenStack. The COA is the first professional certification offered by the OpenStack Foundation. It’s designed to help companies identify top talent in the industry, and help job seekers demonstrate their skills. For more information, head to the COA website. You can also check out this video. 

Call for Papers

There are a number of call for papers for upcoming events:

OpenStack Days

There are a number of upcoming OpenStack Days this year across the globe. See the full calendar here.

New User Groups

Welcome to our new user groups!

Looking for your local user group or want to start one in your area? Head to the groups portal.

Looking for speakers?

If you’re looking for speakers for your upcoming event or meetup, check out the OpenStack Speakers Bureau. It contains a fantastic repository of contacts, including information such as their past talks, languages spoken, country of origin and travel preferences.

Jobs Portal

Find that next great opportunity via the OpenStack Jobs Portal.

Are you following the Foundation on social media? Check out each of our channels today.

Twitter, Linkedin, Facebook, YouTube


Contributing to the User Group Newsletter.

If you’d like to contribute a news item for next edition, please submit to this etherpad.

Items submitted may be edited down for length, style and suitability.

OpenStack Developer Mailing List Digest July 1-8

Important Dates

  • July 14, 2017 23:59 OpenStack Summit Sydney Call for Presentations closes 1.
  • Around R-3 and R-4 (July 31 – August 11, 2017) PTL elections 2
  • All 3


  • TC status update by Thierry 4
  • API Working Group new 5
  • Nova placement/resource providers update 6

SuccessBot Says

  • pabelanger on openstack-infra 7: opensuse-422-infracloud-chocolate-8977043 launched by nodepool
  • clark on openstack-infra 8: infra added citycloud to the pool of test nodes.
  • fungi on openstack-infra 9: OpenStack general mailing list archives from Launchpad (July 2010 to July 2013) have been imported into the current general archive on
  • adreaf on openstack-qa: 10 Tempest ssh validation running by default in the gate on master.
  • All 11

Most Supported Goals And Improving Goal Completion

  • Community wide goals discussions started at the OpenStack Forum, then the mailing list and IRC for those that couldn’t be at the Forum.
    • These discussions help the TC make decisions on which goals will be to a release.
  • Potential goals:
    • Split Tempest plugins into separate repos/projects 12
    • Move policy and docs into code 13
  • Goals in Pike haven’t been really reached.
  • An idea from the meeting to address this is creating a role called “Champions” who are drum beaters to get a goal done, by helping projects with tracking status, and sometime doing code patches.
  • Interested volunteers who have a good understanding of their selected goal and its implementation to be a trusted person.
  • From the the discussion in thread, it seems we’re mostly in agreement with the Champion idea.
    • We have a volunteer for splitting out tempest plugins into repos/projects.
  • Full thread 14


  13.[email protected]/msg106392.html

#openstack #openstack-dev-digest

OpenStack Developer Mailing list Digest June 10-16


  • TC report 24 by Chris Dent 1
  • Release countdown for week R-10 and R-9, June 16-30 by Thierry 2
  • TC Status Update by Thierry 3.

Making Fuel a Hosted Project

  • Fuel originated from Mirantis as their OpenStack installer.
  • Approved as an official OpenStack project November 2015.
  • The goal was to get others involved to make one generic OpenStack installer.
  • In Mitaka and Newton it represented more commits than Nova.
  • While the Fuel team embraced open collaboration, it failed to attract other organizations.
  • Since October 2016 Fuel’s activity dropped from it’s main sponsor.
    • 68% drop between 2016 and 2017.
    • Project hasn’t held a meeting for three months.
    • Activity dropped from ~990 commits/month (April 2016, August 2016) to 52 commits in April 2017 and 25 commits May 2017.
  • Full thread: 4

Moving Away from “big tent” Terminology

  • Back in 2014 our integrated release was not really integrated, too big to be installed by everyone, yet too small to accommodate the growing interest in other forms of “open infrastructure”.
  • Incubation process created catch-22’s.
  • Project structure reform 4 discussions switched us to a simpler model: project teams would be approved based on how well they’d it the OpenStack overall mission and community principles rather than maturity.
    • Nick named the big tent 5
  • It ended up mostly creating confusion due to various events and mixed messages which we’re still struggling with today.
  • This was discussed during a TC office hour in channel openstack-tc 6
  • There is still no agreement on how to distinguish official and unofficial projects. The feedback in this thread will be used to assist the TC+UC+Board sub group on better communicating what is OpenStack.
  • Full thread: 7


[1] –

[2] –

[3] –

[4] –

[5] –

[6] –

[7] –

#openstack #openstack-dev-digest

OpenStack Developer Mailing List Digest June 3-9

SuccessBot Says

  • fungi 1: OpenStack general mailing list archives from Launchpad (July 2010 to July 2013) have been imported into the current general archive on
  • andreaf 2: Tempest ssh validation running by default in the gate on master

etcd as a Base Service Update

  • Update to base service resolution from the TC 3.
  • Projects wanting to use etc v3 API grpc 4.
  • Projects that depend on eventlet, use the etcd3 v3 alpha HTTP API 5.
  • If you use too, there are two driver choices 67.
  • Oslo.cache driver 8.
  • Devstack uses etcd3 by default 9.
  • Cinder points to it 10.
  • Keystone using etcd3 for caching 11.
  • oslo.config to store configurations in etcd3 12.
  • Full thread: 13

Global Request ID Progress

  • oslo.context / oslo.middleware – everything DONE
  • devstack logging additional globalrequestid – DONE
  • cinder:
    • client supports globalrequestid – DONE
    • Cinder calls Nova with globalrequestid – TODO (waiting on Novaclient release)
    • Cinder calls Glance with globalrequestid – TODO
  • neutron:
    • client supports globalrequestid – IN PROGRESS (this landed, released, but the neutron client release had to be blocked for unrelated issues).
    • Neutron calls Nova with globalrequestid – TODO (waiting on Novaclient release)
  • nova:
    • Convert to oslo.middleware (to accept globalrequestid) – DONE
    • client supports globalrequestid – IN PROGRESS (waiting for release here 14)
    • Nova calls cinder with globalrequestid – DONE
    • Nova calls neutron with globalrequestid – TODO (waiting on working neutronclient release)
    • Nova calls Glance with global request id – IN PROGRESS (review needs final +2 here 15)
  • glance:
    • client supports globalrequestid – DONE
    • Glance supports setting globalrequestid – IN REVIEW 16 *(some debate on this).
  • Full thread: 17

Unreleased Libraries

  • Several teams with library deliverables that haven’t see any release this cycle:
    • glance-store
    • instack
    • pycadf
    • python-barbicanclient
    • python-congressclient
    • python-designateclient
    • python-searchlightclient
    • python-swiftclient
    • python-tackerclient
    • requestsexceptions
  • Full thread 18

POST /api-wg/news

  • Guidelines proposed for freeze:
    • Add guideline about consuming endpoints from catalog 19.
    • Add support for historical service type aliases 20.
    • Describe the publication of service-types-authority data 21.
  • Guidelines Under Review
    • Microversions: add nextminversion field in version body 22.
    • A suite of several documents about doing version discovery 23
    • WIP: microversion architecture archival doc (very early; not yet ready for review) 24
  • Full thread: 25

TC Report 23

  • Chris Dent already does a wonderful summary 26.

Project Teams Gathering – Denver September 11-15th

  • What: Second Project Team Gathering
  • When: September 11-15
  • Where Denver Coloradoat the Renaissance Hotel 27
  • Schedule:
    • How long: PTG will run for 5 days Monday – Friday, September 11-15th
    • Inter-project team work: Monday – Tuesday
    • Single project meetings: Wednesday-Friday
  • Check with PTL’s before booking travel as some teams may not meet all three days.
  • Work in progress schedule 28
  • The OpenStack Foundation has reserved a block of discounted rooms at $149/night USD. Rooms will be available 27 until August 20 or until they sell out.
  • Check if you need a visa 29
  • Requests for invitation letters can be submitted here 30, and must be received by Friday, August 25, 2017.
  • Travel support program first round starts July 2nd. Apply now 31
  • Full thread: 32

[1] –

[2] –

[3] –

[4] –

[5] –

[6] –

[7] –

[8] –

[9] –

[10] –

[11] –

[12] –

[13] –

[14] –

[15] –

[16] –

[17] –

[18] –

[19] –

[20] –

[21] –

[22] –

[23] –

[24] –

[25] –

[26] –

[27] –

[28] –

[29] –

[30] –

[31] –

[32] –

OpenStack Developer Mailing List Digest May 20-26

SuccessBot Says

  • clarkb 1 : infra added city cloud to the pool of test nodes.
  • pabelanger 2 : opensuse-422-infracloud-chocolate-8977043 launched by nodepool.
  • All: 3

etcd 3.x as a Base Service

  • A devstack review 4 that adds a new etcd3 service.
  • Two options to enable the DLM use case with Tooz (for eventless based services) 5 6
  • Full thread: 7

Do We Want to be Publishing Binary Container Images?

  • During the Forum, the discussion on collaboration between various teams building or consuming container images.
  • Decide how to publish images from the various teams to docker hub or other container registries.
  • The community has refrained from publishing binary packages in other formats such as debs and RPMs. Instead we have left this to the responsibility of the downstream consumers to build production packages.
  • This would require more tracking of upstream issues (bugs, CVEs, etc) to ensure the images are updated as needed.
    • Given our security and stable team resources, this might not be a good idea at this time.
  • Kolla is interested in doing this for daily builds. Everything is licensed with ASL which gives no guarantees.
    • Even if you mark something to not be used in production, people still use it. Take the recent user survey with DevStack being used in production.
    • Kolla today publishes build instructions. Manually every release they provide built containers.
    • Built containers would run through our CI gate, so others don’t have to have a local CI build pipeline.
  • Things we publish to Pypi are different from this proposal:
    • The formats published by pypi are source formats (sdist) and developer friend but production ready format (wheel).
    • Most of our services are not packaged and published to PyPi. The libraries are to make them easy to consume in our CI.
    • The artifacts in PyPi contain references to dependencies, the dependencies are not built into the packages themselves.
  • Iterating on the infra-spec review for publishing to DockerHub has started 8
  • Full thread: 9

RFC Cross Project Request ID Tracking

  • In the logging Forum session, it was brought up how much effort operators are having to put into reconstructing flows for things like server boot when they go wrong.
    • Jumping from service to service, the request-id is reset to something new.
    • Being able to query in elastic search for the same request-id in communication between services would be useful.
  • There is a concern of trusting the request-id on the wire, because it’s coming from a random user.
    • We have a new concept of “service users” which are set of higher privilege services that we are using to wrap user requests.
  • Basic idea is:
    • services will optionally take an inbound X-OpenStack-Request-ID which we’ll strongly validate req-$uuid format.
      • They will continue to generate one as well.
      • When the context is built we’ll check the service user was involved, and if not, reset the request-id to the local generated one.
      • Both request-ids will be logged.
    • Python clients and callers will need to be augmented to pass the request-id in on requests.
    • Servers will opt into calling other services this way.
  • Oslo spec for this has been merged 10.
  • Full thread: 11

Can We Stop Global Requirements Update (Cont.)

  • Gnocchi has gate issues with Babel this time. Julien plans to remove all oslo dependencies over the next few months.
  • The project Cotyledon was presented at some summit ago as an alternative to oslo.service and getting rid of eventless. The library lives under the telemetry umbrella for now.
    • The project doesn’t live under oslo so that it’s encouraged for the greater python ecosystem to adopt and help maintain it.
  • Octavia is also using Cotyledon.
  • Full thread: 12

Revised Postgresql Deprecation Patch for Governance

  • In the Forum session we agreed to the following:
    • Explicitly warn in operator facing documentation Postresql is less supported than MySQL.
    • Sure is the process of investigating migration from Postgresql to Gallera for future versions of OpenStack products.
    • TC governance patch is updated 13.
  • Current sticking points:
    • It’s important that the operator community largely is already in one camp or not.
    • Future items listed that are harder are important enough to justify a strict trade off here.
    • It’s ok to have the proposal have a firm lean in tone, even though it’s set of concrete actions are pretty reversible and don’t commit to future removal of Postgresql.
  • What has been raised as being hard by an abstraction layer like SQLAlchemy:
    • OpenStack services taking a more active role in managing DBMS.
      • See Active or passive role with our database layer summary below for this discussion.
    • The ability to have zero down time upgrade for services such as Keystone.
      • Expand/contract with code and carefully dancing around the existence of two schema concepts simultaneously (e.g. Nova and Neutron).
      • This shouldn’t be a problem because we use alembic or sqlalchemy-migrate to abstract away ALTER TABLE types.
      • Expand/contract using server side triggers to reconcile the two schema. This is more difficult because there is no abstraction layer that exists in SQLAlchemy. It could be feasible to build one specific to OpenStack.
    • Consistent UTF-8 4 & 5 byte support in our APIs
      • Unicode itself only needs 4 bytes and that is as far as any database supports right now. This problem has been solved by SQLAlchemy well before Python 3 existed.
    • The requirement that Postgresql libraries are compiled for new users trying to just run unit tests.
      • New developers who aren’t concerned with Postgresql don’t have to run these tests.
      • OpenStack went all the way with Kilo using the native python-MySQL driver which required compiling.
      • This is OpenStack. We are the glue to thousands of c-compiled libraries and packages.
    • Consistency around case sensitivity collation.
      • MySQL is defaulting to case-insensitive.
      • Postgresql almost has no support for case-insensitive.
      • SQLAlchemy supports things like ilike().
      • String datatype in SQLAlchemy guarantees case-insensitive.
  • Top concerns that remain:
    • A1) Do not surprise users late by them only finding out they are on less traveled once they are so deeply committed. It’s fine for users to choose the path, as long as they are informed they are going to need to be more self reliant.
    • A2) Do not prevent features like zero downtime in Keystone making forward progress with a MySQL only solution.
  • Orthogonal concerns:
    • B1) Postgresql was chosen by people in the past, maybe more than we realized, that’s real users we don’t want to throw under the bus. Whole sale delete is off the table. There’s no clear path off and missing data of who’s on it.
    • B2) The upstream code isn’t so irreparably changed (e.g. delete the SQLAlchemy layer) that it’s not possible to have alternative database backends.
  • The current proposal 13 addresses A1 and B1.
  • Full thread: 14

[1] –

[2] –

[3] –

[4] –

[5] –

[6] –

[7] –

[8] –

[9] –

[10] –

[11] –

[12] –

[13] –

[14] –

OpenStack Developer Mailing List Digest April 29 – May 5

POST /api-wg/news

  • Newly Published Guidelines
    • Create a set of API interoperability guidelines 1
  • Guidelines Current Under Review
    • Microversions: add nextminversion field in version body 2
    • A suite of five documents about version discovery 3
    • Support for historical service type aliases 4
    • WIP: microversion architecture archival document 5
  • Full thread: 6

Release countdown for week R-16 and R-15 May 8-9

  • Focus:
    • Pike feature development and completion of release goals.
    • Team members attending the Forum at the Boston summit should be focused in requirements gathering and collecting feedback from other parts of the community.
  • Actions:
    • Some projects still need to do Ocata stable point release.
      • aodh
      • barbican
      • congress
      • designate
      • freezer
      • glance
      • keystone
      • manila
      • mistral
      • sahara
      • searchlight
      • tricircle
      • trove
      • zaqar
    • Projects following intermediary-release models and haven’t done any:
      • aodh
      • bitfrost
      • ceilometer
      • cloud kitty[-dashboard]
      • ironic-python-agent
      • karbor[-dashboard]
      • magnum[-ui]
      • murano-agent
      • panko
      • senlin-dashboard
      • solum[-dashboard]
      • tacker[-dashboard]
      • virtage[-dashboard]
    • Independent projects that have not published anything for 2017:
      • solum
      • bandit
      • syntribos
    • Upcoming deadlines and dates:
      • Forum at OpenStack Summit in Boston: May 8-11
      • Pike-2 milestone 2: June 8
    • Full thread: 7

OpenStack moving both too fast and too slow at the same time

  • Drew Fisher makes the observation that the user survey 8 shows the same issue time and time again on page 18-19.
    • Things move too fast
    • No LTS release
    • Upgrades are scary for anything that isn’t N-1 ←N
      • The OpenStack community has reasonable testing in place to ensure that N-1 ←N upgrades work.
      • Page 18: “Most large customers move slowly and thus are running older versions, which are EOL upstream sometimes before they even deploy them.”
      • We’re unlikely to add more stable releases or work on them longer because:
    • We need more people to do the work. It has been difficult to attract contributors to this area.
    • Find a way to do that work that doesn’t hurt our ability to work on master.
  • We need older versions of the deployment platforms available in our CI to run automated tests.
    • Supported version of development tools setup tools and pip.
    • Supported versions of the various libraries and system-level dependencies like libvirt.
  • OpenStack started with no stable branches, where we were producing releases and ensuring that updates vaguely worked with N-1 ←N.
  • Distributions maintained their own stable branches.
    • It was suggested instead of doing duplicate effort, to share a stable branch.
      • The involvement of distribution packagers became more limited.
      • Today it’s just one person, who is currently seeking employment.
  • Maintaining stable branches has a cost.
    • Complex to ensure that stable branches actually keep working.
    • Availability of infrastructure resources.
  • OpenStack became more stable, so the demand for longer-term maintenance became stronger.
    • People expect upstream to provide it, not realizing that upstream is made of people employed by various organizations, and apparently this isn’t of interest to fund.
  • Current stable branch model is kind of useless in only supporting stable branches for one year. Two potential outcomes:
    • The OpenStack community still thinks there is a lot of value in doing this work upstream, in which organizations should invest resources in making that happen.
    • The OpenStack community thinks this is better handled downstream, and we should get rid of them completely.
  • For people attending the summit, there will be an on-boarding session for the stable team 9
  • Matt Riedemann did a video 10 ether pad 11 and slides 12 on the stable work. In the end, it was determined the cost of doing it didn’t justify the dream on, lack of resources to do it.
  • Full thread: 13


[1] –

[2] –

[3] –

[4] –

[5] –

[6]  –

[7] –

[8] –

[9] –

[10] –

[11] –

[12] –

[13] –

User Group Newsletter March 2017

User Group Newsletter March 2017



Exciting news! The schedule for the Boston Summit in May has been released. You can check out all the details on the Summit schedule page.

Travelling to the Summit and need a visa? Follow the steps in this handy guide, 

If you haven’t registered, there is still time! Secure your spot today! 



The OpenStack Summit kicks off in less than six weeks and seven deserving organizations have been nominated to be recognized during the opening keynotes. For this cycle, the community (that means you!) will review the candidates before the Superuser editorial advisors select the finalists and ultimate winner. See the full list of candidates and have your say here. 



About 40 people from the OpenStack Technical Committee, User Committee, Board of Directors and Foundation Staff convened in Boston to talk about the future of OpenStack. They discussed the challenges we face as a community, but also why our mission to deliver open infrastructure is more important than ever. Read the comprehensive meeting report here.



Fantastic new project mascots were released just before the Project Teams Gathering. Read the the story behind your favourite OpenStack project mascot via this superuser post. 



We have some new user groups which have joined the OpenStack community.

Spain- Canary Islands

Mexico City – Mexico

We wish them all the best with their OpenStack journey and can’t wait to see what they will achieve! Looking for your local group? Are you thinking of starting a user group? Head to the groups portal for more information.


OpenStack is participating in a series of upcoming Community events this April.

April 3: Open Networking Summit Santa Clara, CA

  • OpenStack is sponsoring the Monday evening Open Source Community Reception at Levi Stadium
  • ldiko Vancsa will be speaking in two sessions:
  • Monday, 9:00-10:30am on “The Interoperability Challenge in Telecom and NFV Environments”, with EANTC Director Carsten Rossenhovel and Chris Price, room 207
  • Thursday, 1:40-3:30pm, OpenStack our Mini-Summit, topic “OpenStack:Networking Roadmap, Collaboration and Contribution” with Armando Migliaccio and Paul Carver from AT&T; Grand Ballroom A&B


April 17-19: DockerCon, Austin, TX

  • Openstack will be in booth #S25


April 19-20: Global Cloud Computing Open Source Summit, Beijing, China

  • Mike Perez will be delivering an OpenStack keynote



We have lots of upcoming OpenStack Days coming up:

Upcoming OpenStack Days

June 1: Australia

June 5: Israel

June 7: Budapest

June 26: Germany Enterprise (DOST)

Read further information about OpenStack Days from this website. You’ll find a FAQ, see highlights from previous events and an extensive toolkit for hosting an OpenStack Day in your region. 



If you’d like to contribute a news item for next edition, please submit to this etherpad.

Items submitted may be edited down for length, style and suitability.

This newsletter is published on a monthly basis.




OpenStack Developer Mailing List Digest March 18-24

SuccessBot Says

  • Yolanda [1]: Wiki problems have been fixed, it’s up and running
  • johnthetubaguy [2]: First few patches adding real docs for policy have now merged in Nova. A much improved sample file [3].
  • Tell us yours via OpenStack IRC channels with message “#success <message>”
  • All: [4]

Release Naming for R

  • It’s time to pick a name for our “R” release.
  • The assoicated summit will be in Vancouver, so the geographic location has been chosen as “British Colombia”.
  • Rules:
    • Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of “Austin”. After “Z”, the next name should start with “A” again.
    • The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
    • The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process.
    • The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so “Foo City” or “Foo Peak” would both be eligible as “Foo”.
  • Full thread [5]

Moving Gnocchi out

  • The project Gnocchi which has been tagged independent since it’s inception has potential outside of OpenStack.
  • Being part of the big tent helped the project be built, but there is a belief that it restrains its adoption outside of OpenStack.
  • The team has decided to move it out of OpenStack [6].
    • In addition out of the OpenStack infrastructure.
  • Gnocchi will continue thrive and be used by OpenStack such as Ceilometer.
  • Full thread [7]

POST /api-wg/news

  • Guides under review:
    • Define pagination guidelines (recently rebooted) [8]
    • Create a new set of api stability guidelines [9]
    • Microversions: add next_min_version field in version body [10]
    • Mention max length limit information for tags [11]
    • Add API capabilities discovery guideline [12]
    • WIP: microversion architecture archival doc (very early; not yet ready for review) [13]
  • Full thread [14]


OpenStack Developer Mailing List Digest March 11-17

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>”
  • All: [7]

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]

OpenStack Summit Boston Schedule Now Live!

  • Main conference schedule [13]
  • Register now [14]
  • Hotel discount rates for attendees [15]
  • Stackcity party [16]
  • Take the certified OpenStack Administrator exam [17]
  • City guide of restaurants and must see sites [18]
  • Full thread [19]

Some Information About the Forum at the Summit in Boston

  • “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]


The Future of the App Catalog

  • 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]

ZooKeeper vs etcd for Tooz/DLM

  • 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]

Small Steps for Go

  • 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]

POST /api-wg/news

  • 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]

Proposal to Rename Castellan to oslo.keymanager

  • 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]

Release Countdown for week R-23 and R-22

  • 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]

Deployment Working Group

  • 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.