[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
[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: 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
[14].
* 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
deadline.
* 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
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: 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
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: 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