[openstack-dev] OpenStack Developer Mailing List Digest January 14-20

Mike Perez mike at openstack.org
Fri Jan 20 20:44:15 UTC 2017

HTML version: https://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170120/

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: https://wiki.openstack.org/wiki/Successes

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: http://lists.openstack.org/pipermail/openstack-dev/2017-January/thread.html#110278

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
  - 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: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110384.html

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: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110391.html

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
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html

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: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110441.html

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
* See the README.rst file in openstack/releases for more details about how to
  format branch specifications.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110218.html

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
* 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
* 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: http://lists.openstack.org/pipermail/openstack-dev/2017-January/thread.html#110192

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: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110522.html

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
* 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: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110529.html

[1] - http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-01-18.log.html
[2] - http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-01-18.log.html
[3] - http://lists.openstack.org/pipermail/openstack-dev/2016-November/107035.html
[4] - http://bugs.python.org/issue9216
[5] - http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-17-20.00.log.html
[6] - https://review.openstack.org/#/c/418010/
[7] - http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
[8] - https://review.openstack.org/#/c/421846/
[9] - https://review.openstack.org/421956
[10] - https://review.openstack.org/421957
[11] - http://eavesdrop.openstack.org/#Architecture_Working_Group
[12] - https://www.openstack.org/marketplace/drivers/
[13] - http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
[14] - https://etherpad.openstack.org/p/driverlog-validation
[15] - http://governance.openstack.org/election/#how-to-submit-your-candidacy
[16] - http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[17] - https://governance.openstack.org/election/
[18] - https://governance.openstack.org/election/#pike-ptl-candidates
[19] - https://review.openstack.org
[20] - http://lists.openstack.org/pipermail/openstack-dev/2016-December/108923.html
[21] - https://github.com/square/keywhiz
[22] - https://review.openstack.org/#/c/422264/
[23] - https://review.openstack.org/#/c/421084/
[24] - https://review.openstack.org/#/c/411528/
[25] - https://review.openstack.org/#/c/411849/
[26] - https://review.openstack.org/417441
[27] - https://review.openstack.org/#/c/411529/
[28] - https://review.openstack.org/#/c/390973/
[29] - https://review.openstack.org/#/c/386555/
[30] - http://releases.openstack.org/ocata/schedule.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170120/0d895fc8/attachment.pgp>

More information about the OpenStack-dev mailing list