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.


Helping PTG attendees and other developers get to the OpenStack Summit

Although the OpenStack design events have changed, developers and operators still have a critical perspective to bring to the OpenStack Summits. At the PTG, a common whisper heard in the hallways was, “I really want to be at the Summit, but my [boss/HR/approver] doesn’t understand why I should be there.” To help you out, we took our original “Dear Boss” letter and made a few edits for the PTG crowd. If you’re a contributor or developer who wasn’t able to attend the PTG, with a few edits, this letter can also work for you. (Not great with words? Foundation wordsmith Anne can help you out–anne at


Dear [Boss],


I would like to attend the OpenStack Summit in Boston, May 8-11, 2017. At the Pike Project Team Gathering in Atlanta (PTG), I was able to learn more about the new development event model for OpenStack. In the past I attended the Summit to participate in the Design Summit, which encapsulated the feedback and planning as well as design and development of creating OpenStack releases. One challenge was that the Design Summit did not leave enough time for “head down” work within upstream project teams (some teams ended up traveling to team-specific mid-cycle sprints to compensate for that). At the Pike PTG, we were able to kickstart the Pike cycle development, working heads down for a full week. We made great progress on both single project and OpenStack-wide goals, which will improve the software for all users, including our organization.


Originally, I––and many other devs––were under the impression that we no longer needed to attend the OpenStack Summit. However, after a week at the PTG, I see that I have a valuable role to play at the Summit’s “Forum” component. The Forum is where I can gather direct feedback and requirements from operators and users, and express my opinion and our organization’s about OpenStack’s future direction. The Forum will let me engage with other groups with similar challenges, project desires and solutions.


While our original intent may have been to send me only to the PTG, I would strongly like us to reconsider. The Summit is still an integral part of the OpenStack design process, and I think my attendance is beneficial to both my professional development and our organization. Because of my participation in the PTG, I received a free pass to the Summit, which I must redeem by March 14.      


Thank you for considering my request.
[Your Name]

The OpenStack Summit is returning to Vancouver in May 2018

Back by popular demand, the OpenStack Summit is returning to Vancouver, Canada from May 21-24, 2018. Registration, sponsorship opportunities and more information for the 17th OpenStack Summit will be available in the upcoming months. 

Can’t wait until 2018? Brush up on your OpenStack skills in 2017 by registering to attend the OpenStack Summit Boston, May 8-11 and marking your calendar for the OpenStack Summit Sydney, November 6-8.

For news on new and upcoming OpenStack Summits, visit 

Photos from the 2015 OpenStack Summit Vancouver




User Group Newsletter February 2017

Welcome to 2017! We hope you all had a lovely festive season. Here is our first edition of the User Group newsletter for this year.


2017 sees some new arrivals and departures to our Ambassador program. Read about them here.



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


Ireland – Cork

Russia – St Petersburg

United States – Phoenix, Arizona

Romania – Bucharest

We wish them all the best with their OpenStack journey and can’t wait to see what they will achieve!

Looking for a your local group? Are you thinking of starting a user group? Head to the groups portal for more information.


We’re going to Boston for our first summit of 2017!!

You can register and stay updated here.

Consider it your pocket guide for all things Boston summit. Find out about the featured speakers, make your hotel bookings, find your FAQ and read about our travel support program.


The community has spoken! A new board of directors has been elected for 2017.
Read all about it here. 

Submit your response the latest OpenStack User Survey!
All data is completely confidential. Submissions close on the 20th of February 2017.
You can complete it here. 


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. 


Supporting our global community

OpenStack is a global open source community. The OpenStack Foundation serves members in 180 countries focused on advancing the capabilities and accessibility of open infrastructure everywhere. We fundamentally believe diversity and collaboration are a powerful force for innovation, and it has been amazing to see the product of tens of thousands of people around the world over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump that targets individuals from 7 countries. The order restricts the travel and movement of people in a discriminatory way that  results in a restriction on access to talent and ideas. It is still unclear how the policies will play out and be enforced, but we will be watching, advocating for and supporting our community members to the best of our ability.

This executive order will not impact the governance of the Foundation or the way the community operates globally. We will continue to support user groups and community members that are active in the seven countries named by the executive order, alongside our 120+ user groups around the world. However, we have two scheduled events in the United States within the next six months that will attract a global audience: the PTG (Project Teams Gathering) in Atlanta, Feb 20-24, a smaller event that will bring together hundreds of upstream contributors, and the OpenStack Summit in Boston, May 8-11, our larger event that happens every six months.

This executive order could impact some community members ability to travel to Atlanta and Boston, but unfortunately it is too late at this point to change the location of these events. The following three OpenStack Summits, however, are now scheduled to occur outside of the United States. The next Summit will be in November 2017 in Sydney, Australia and we are working to finalize the details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned that his plans to travel from Canada to Atlanta to attend the PTG may be restricted, simply because he a dual citizen of Canada and Iraq.  Mohammed has been contributing code to OpenStack since 2011 and is the CEO and Founder of Vexxhost. Blocking his travel would serve no purpose and rob the community of a valuable contributor during an important event. If you are concerned about the impact or have any questions, please don’t hesitate to reach out to me at [email protected]

Political actions like this highlight the importance of our collective values. The Four Opens, the founding principles of our community, exist to ensure the free flow of talent and ideas, across geographic, national, organizational or other lines that might divide us. We believe in humanity. We believe in opportunity. We believe in the power of collaboration across borders, and we will continue to carry forward our mission.

Jonathan Bryce
Mark Collier
Lauren Sell

This blog post has now been translated into Korean by Sungjin Kang, a member of the OpenStack community in Korea.

OpenStack Developer Mailing List Digest January 21-27

SuccessBot Says

  • dims [1] : Nova now has a python35 based CI job in check queue running Tempest tests (everything running on py35)
  • markvoelker [2]: Newly published Foundation annual report starts off with interoperability right in the chairman’s note [3]
  • Tell us yours via OpenStack IRC channels with message “#success <message>”
  • All: [4]

Get Active in Upstream Training

  • There is a continuous effort in helping newcomers join our community by organizing upstream contribution trainings [5][6] before every summit.
    • 1.5 – 2 days of hands-on steps of becoming an active OpenStack contributor.
  • Like everything else, this is a community effort.
    • In preparation for the Boston summit and the upcoming PTG in Atlanta, we are looking for coaches and mentors to help us make the training better.
    • If you’re interested in helping contact:
      • Ildiko Vancsa IRC freenode at ildikov or email [7]
      • Kendall Nelson IRC freenode at diablo_rojo or email [8]
  • Full thread: [9]

Project Team Gathering Coordination Tool

  • No central scheduling, beyond assigned rooms to teams and days.
    • Each team arranges their time in their room.
    • List of etherpads [10]
  • We still need centralized communication beyond each room:
    • An event IRC channel: #openstack-ptg on free node IRC
      • Do public service announcements
      • Pings from room to room.
    • An EtherCalc spreadsheet powered dynamic schedule with extra rooms available:
      • One fishbowl
      • A few dark rooms with projectors and screens (not all will have a/v equipment due to budget).
      • Infra is working on setting up EtherCalc
  • Full thread: [11]

POST /api-wg/news

  • API Guidelines proposed for freeze:
    • Add guidelines on usage of state vs. status [12]
    • Clarify the status values in versions [13]
    • Add guideline for invalid query parameters [14]
  • Guidelines currently under review:
    • Add guidelines for boolean names [15]
    • Define pagination guidelines [16]
    • Add API capabilities discovery guideline [17 ]
  • Full thread: [18]

Lots of Teams Without PTL Candidates

  • We are reaching close to the end of the PTL nominations (Jan 29, 2017 23:45 UTC), but have projects that are leaderless:
  • Community App Catalog
  • Ec2 API
  • Fuel
  • Karbor
  • Magnum
  • Monasca
  • OpenStackClient
  • OpenStackUX
  • Packaging Prm
  • Rally
  • RefStack
  • Requirements
  • Senlin
  • Stable Branch Maintenance
  • Vitrage
  • Zun
  • Full thread [19]

OpenStack Developer Mailing List Digest January 14-20

SuccessBot Says

  • stevemar 1 : number of open keystone bugs < 100!
  • morgan 2 : Good policy meeting, provided history and background that cleared up a lot of confusion
  • Tell us yours via OpenStack IRC channels with message “#success <message>”
  • All

FIPS Compliance

  • Previous threads 3 have been discussing enabling Federal Information Processing Standards (FIPS).
  • Various OpenStack projects make md5 calls. Not for security purposes, just hash generation, but even that blocks enabling FIPS.
  • A patch has been proposed for newest versions of Python for users to set if these are used for security or not 4 .
    • Won’t land until next versions of Python, but in place for current RHEL and CentOS versions.
    • We will create a wrapper around md5 with a useforsecurity=False parameter to check the signature of hashlib.md5.
  • Steps forward:
    • Create the wrapper
    • Replace all md5 calls in OpenStack projects with the wrapper.
  • Unfortunately the patch 4 has stopped having progress since 2013. We should get that merged first.
    • Even if this did land, it would be a while before it was adopted, since it would land in Python 3.7.
  • Full thread

Refreshing and Revalidating API Compatibility Guidelines

  • In the last TC meeting 5 , a tag was in review for supporting API compatibility 6 .
  • The tag evaluates projects by using the API guideline which is out of date 7.
    • A review has been posted to refresh these guidelines 8 .
    • API compatibility of overtime is a fundamental aspect of OpenStack interoperability. Not only do we need to get it it right, we need to make sure we understand it.
  • Full thread

Base Services

  • in open stack all components can assume that a number of external services won’t be present and available (e.g. A message queue, database).
  • The Architecture working group has started this effort 9 .
  • This proposal 10 is a prerequisite in order for us to have more strategic discussions with adding base services.
  • Review the proposal and/or join the Architecture working group meeting 11
  • Once solidified the technical committee will have a final discussion and approval.
  • Full thread

Improving Vendor Discoverability

  • In previous Technical Committee meetings, it was agreed that vendor discoverability needs to be improved.
  • This is done today with the OpenStack Foundation marketplace 12 .
    • This is powered by the community driven project call driver log which is a big JSON file 13.
  • Various people in the community did not know how the marketplace worked and we’re unhappy that the projects themselves weren’t owning it.
  • The goal of this discussion is to have this process be more community driven than it is today.
  • Suggestion: Split driver log into smaller JSON files that are inside each project to maintain.
    • Projects will set how they validate vendors into this list.
    • There’s a trend today for third party CI’s being a choice of validation 14.
  • Full thread

Nominations for OpenStack PTLs Are Now Open!

  • Will remain open until January 29, 2017 23:45 UTC.
  • Candidates must submit a text file openstack/election repository 15
    • Filename convention is $cyclename/$projectname/$ircname.txt.
    • To be eligible, you need to have contributed an accepted patch to one of the corresponding program’s projects 16 during the Neutron-Ocata timeframe (April 11, 2016 00:00 UTC to January 23, 2017 23:59 UTC).
  • Additional information about the nomination process 17
  • Approved candidates will be listed 18.
  • Electorate should confirm their email address in Gerrit 19 in Settings ←Contact Information ←Preferred Email prior to Jan 25, 2017 23:59 UTC.
  • Full thread

The Process of Creating stable/ocata branches

  • As previously mentioned 20, it’s possible for teams to setup stable branches when ready.
  • The release team will not be automatically setting up branches this cycle.
    • The release liaison within teams will need to inform when ready.
    • The PTL or release liaison may request a new branch by submitting a patch to the openstack/releases repository specifying the tagged version to be used as the base of the branch.
  • Guidelines for when projects should branch:
    • Projects using the cycle-with-milestone release model should include the request for their stable branch along with the RC1 tag request (target week is R-3 week, so use Feb 2 as the deadline)
    • Library projects should be branched with, or shortly after, their final release this week (use Jan 19 as the deadline)
    • I will branch the requirements repository shortly after all of the cycle-with-milestone projects have branched. After the   requirements repository is branched and the master requirements list is opened, projects that have not branched will be tested with Pike requirements as the requirements master branch advances and stable/ocata stays stable. Waiting too long to create the stable/ocata branch may result in broken CI jobs in either stable/ocata or master. Don’t delay any further than necessary.
    • Projects using the cycle-trailing release model should branch by R-0 (23 Feb). The remaining two weeks before the trailing deadline should be used for last-minute fixes, which will need to be backported into the branch to create the final release.
    • Other projects, including cycle-with-intermediary and independent  projects that create branches, should request their stable branch when they are ready to declare a final version and start working on Pike-related changes. This must be completed before the final release week, use 16 Feb as the deadline.
  • See the README.rst file in openstack/releases for more details about how to format branch specifications.
  • Full thread

Why Are Projects Trying To Avoid Barbican, Still?

  • Some projects are wanting to implement their own secret storage to avoid Barbican or avoid adding a dependency on it.
    • Some developers are doing this to make the operator’s lives simpler.
  • Barbican Positives:
    • Barbican has been around for a few years and deployed by several companies that have probably been audited for security purposes.
    • Most of the technology involved in Barbican is proven to be secure. This has been analyzed by the OpenStack’s own security group.
    • Doesn’t have a requirement on hardware TPM, so no hardware cost.
    • Several services provide the option of using Barbican, but not a hard requirement.
  • Feedback of problems with Barbican:
    • Relying on something that cannot be guaranteed will be present in a deployment.
      • The base service 9 proposal could help with this.
    • OpenStack specific solution. Some companies are using solutions that integrate with other things:
      • Keywhiz 21 to work with Kubernetes and their existing systems.
    • Devstack plugin just sets up Barbican. It’s not actually configuring any existing services to use it.
    • No fixed key manager for testing. The Barbican team pushed back on maintaining this because it’s not secure.
    • API stability with version 2 ←3 changes were made without a deprecation path or guarantees.
    • Tokens are open ended for users. Keystone and Barbican need to be much closer.
  • Castellan provides an abstraction for key management, but today only Barbican.
  • Rackspace recently made Barbican available. Maybe it’s easier now to perform an HA deployment.
  • Full thread

POST /api-wg/news

  • New guidelines:
    • Accurate status code vs backwards compatibility 22
    • Fix no sample file in browser 23
  • Guidelines proposed for freeze:
    • Add guidelines on usage of state vs. status 24
    • Clarify the status values in versions 25
    • Add guideline for invalid query parameters 26
  • Under review:
    • Add guidelines for boolean names 27
    • Define pagination guidelines 28
    • Add API capabilities discovery guideline 29
  • Full thread

Release Countdown for Week R-4 Jan 23-27

  • Focus:
    • This week begins feature freeze for all milestone-based projects.
    • No feature patches should be landed after this point.
    • PTLs may grant exceptions
    • Soft string freeze begins.
      • Review teams should reject any modifications to user-facing strings.
    • Requirement freeze begins.
      • Only critical requirements and constraints changes will be allowed.
  • Release Tasks:
    • Prepare final release and branch requests for all client libraries.
    • Review stable branches for unreleased changes and prepare those releases.
    • Milestone based projects should ensure that membership of $project-release gerri groups is up to date with the team who will finalize the project release.
  • General Notes:
    • RC1 target week in R-3 is only one week after freeze.
  • Important Dates:
    • Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan
    • Ocata RC1 target: 2 Feb
    • Ocata Final Release candidate deadline: 16 Feb
    • Ocata release schedule 30
  • Full thread


[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] –