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

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