The content below is taken from the original (OpenStack Developer Mailing List Digest Jan 23 – Feb 9), to continue reading please visit the site. Remember to respect the Author & Copyright.

SuccessBot Says

• odyssey4me: OpenStack Ansible Liberty 12.0.5 released.
• stevemar: Devstack now defaults to v3 for Keystone.
• boris-42: osprofiler functional job passed [1].
• odyssey4me: OpenStack Ansible Kilo 11.2.9 released [2].
• odyssey4me: OpenStack Ansible Liberty 12.0.6 released [3].
• All: http://bit.ly/1VJsrMI

Cross-Project Specs

• A common policy scenario across all projects [4].
• Query config from web UI [5]

API Guidelines

• Must not return service-side tracebacks [6].

Service Type vs. Project Name For Use In Headers

• There’s a question of whether we should be using service type or project names in headers. Some reviews involving this [7][8][9][10].
• We should be selecting things that better serve the API consumers and according to Dean Troyer the API working group is going in the right direction.
• The service type as the primary identifier for endpoints and API services is well established, and is how the service catalog has and will always work. Service types therefore should be the way to go.
• Full thread: http://bit.ly/1PctPqc

OpenStack Ansible Without Containers

• Gyorgy annouces a new installer for OpenStack under GPLv3 using Ansible, but without containers.
  • Reasons for another installer since we already have the OpenStack Ansible project and Kolla:
    • Containers adding unnecessary complexity.
    • Packages: avoid mixing pip and distributor packages. Distributor packages includes things like init scripts, proper system users, upgrade possibilities, etc.
      • Kevin Carter mentions that these benefits are actually also included with the OpenStack Ansible project.
• Without containers, upgrading a single controller can be tricky and disruptive since you have to upgrade every service at the same time. Rollbacks are also easier.
• OpenStack Ansible project can already today do deployment without containers using the is_metal=true variable.
• Full thread: http://bit.ly/1Q0gDIw

Release Countdown for Week R-8, Feb 8-12

• Focus:
  • 2 more weeks before final releases for non-client libraries for this cycle.
  • 3 more weeks before the final releases for client libraries.
  • Projects should focus on wrapping up feature work in all libraries.
• Release Actions:
  • The release team will be strictly enforcing library release freeze before M3 in 3 weeks.
• Important Dates:
  • Final release for  non-client libraries: Feb 24
  • Final release for client libraries: Mar 2
  • Mitaka 3: Feb 29-Mar 4 (includes feature freeze and soft string freeze)
• Full thread: http://bit.ly/1PctPqd

“No Open Core” in 2016

• Before OpenStack had a name, the “four opens” principles were created to define how we operate as a community.
• In 2010 when OpenStack started, it was different from other open source cloud platforms (Eucalyptus) which followed open core strategy of producing a crippled community edition and an “enterprise version”.
• Today we have a non-profit independent foundation, which cannot do an “enterprise edition”.
  • Today member companies build “enterprise products” on top of the apache licensed upstream project. Some are drivers that expose functionality in proprietary components.
• What does it mean to “not do open core” in 2016? What is acceptable and what’s not?
• Thierry Carrez believes it’s time to refresh this of what is an acceptable official project in OpenStack.
  • It should have a fully-functional production grade open source implementation
  • If you need proprietary software of commercial entity to fully use the project, then it should not be accepted in OpenStack as an official project.
    • These projects can still be non-official projects and still be hosted by OpenStack infrastructure.
• Doug Hellmann brings up Poppy [11] which is applying to be an official OpenStack project.
  • A wrapper to content delivery networks, but there is no open source solution.
  • Is this something that can be an official project, or is open core?
• Full thread: http://bit.ly/1Q0gDIx

The Trouble with Names

• A few issues have crept up recently with the service catalog, API headers, API end points, and even similarly named resources in different resources (e.g. backup), that are all circling around a key problem. Distributed teams and naming collision.
• Each project has a unique name that is ensured by their git repository in the OpenStack namespace.
• There’s a desire to replace project names with generic names like nova/compute in:
  • service catalog
  • api headers
• Options we have are:
  • Use the code names we already have: nova, glance, swift, etc.
    • Upside: collision problem solved.
    • Downside: You need a secret decoder ring to know what a project does.
  • Have a registry of common names.
    • Upside: we can safely use common names everywhere and not fear collision down the road.
    • Downside: yet another contention point.
• Approvals by the various people in the community to have a registry of the common names. Maybe in the governance projects.yaml file [12]?
  • This list does include only the official projects by the technical committee, therefore only those projects can reserve the common names.
• OpenStack Client has already encoded some of these common names to projects [13].
• Full thread: http://bit.ly/1PctNyG

Announcing Ekko – Scalable Block-Based Backup for OpenStack

• The goal of Ekko is to provide incremental block-level backup and restore of Nova instances.
• Two place with overlapping goals:
  • Cinder volume without having the incremental backups be dependent.
  • Nova instances
    • OpenStack Freezer today leverages Nova’s snapshot feature.
    • Ekko would leverage live incremental block-level backup of a nova instance.
• Jay Pipes begins the discussion on the two projects (Freezer and Ekko) working together to make sure their REST API endpoints are not overlapping. Having two APIs for performing backups that are virtually identical is not good.
• The creator of Ekko sees the reason for another backup project because of “actual implementation and end results are wildly different” even if they are the same API call.
• Jay doesn’t like that today all the following endpoints exist:
  • Freezer’s /backups
  • Cinder’s /{tenant_id}/backups
• Having these endpoints make for bad user experience and is just confusing.
• The current governance model does not prevent competition of projects. So if two projects overlap in API endpoints, there should be an attempt in collaboration.
• Full thread: http://bit.ly/1Q0gC7D

The content below is taken from the original (Technical Committee Highlights January 22, 2016), to continue reading please visit the site. Remember to respect the Author & Copyright.

Upstream development track – please submit

We’ll have an “Upstream development” track at the Austin Summit. It will happen on the Monday, before the Design Summit starts. This is a classic Summit conference track with recorded videos, so we want polished proposals for this track. We expect these to include general communication about development process changes, new features in a central project that need adoption in other projects, corner use cases that may need support from development, developer-oriented infra talks and upstream development best practices. To propose a talk for this track, use the Summit proposal system, select Upstream development, and meet the February 1st deadline.

Our mission

The OpenStack overall mission has stood proudly for years now, and is due for an update to increase focus on cloud consumers rather than solely on cloud builders. So we have proposed an amendment to the original mission. You can read the current and proposed new mission on governance.openstack.org.

And now, even more doc

In a clarification effort, we pushed the definition of the 4 opens, as well as clarified OpenStack licensing requirements as reference documents under the governance repository. Previously those were maintained in oral tradition, the wiki, or left as an exercise to the reader of the Foundation bylaws. You can now find them published (like all Technical Committee resolutions and reference information) on the governance website.

The names are here! The names are here!

The N and O releases directly after Mitaka will be Newton and Ocata. For the Austin Summit, the tie-in is to the “Newton House”, located at 1013 E. Ninth Street in Austin, Texas. It’s listed on the National Register of Historic Places. For the Barcelona Summit, know that Ocata is a beach about 20 minutes north of Barcelona by train.

Clarifying licensing requirements

A new governance page clarifies guidelines for licensing for projects in and around OpenStack.  We want to raise awareness and highlight that page for future reference. In the subset of OpenStack projects that may be included in a Defcore trademark program, the project must be licensed under Apache Software License v2, ASLv2. Libraries and software built in the OpenStack infrastructure system should use OSI-approved licenses that do not restrict distribution of the consuming project. Read more on the governance website.

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

Success Bot Says

• mriedem: nova liberty 12.0.1 released [1].
• OpenStack Ansible Kilo 11.2.7 has been released.
• OpenStack-Ansible Liberty 12.0.4 has been released.
• Tell us yours via IRC with a message “#success [insert success]”.
• All: http://bit.ly/1VJsrMI

Governance

• License requirement clarification for big tent projects [2].
• Make constraints opt in at the test level [3].
• OSprofiler is now an official OpenStack project [4].

Cross-Project

• TC approved:
  • Deprecate individual CLIs in favor of OpenStack client [5].
  • clouds.yaml support in clients [6].
• Current open specs: http://bit.ly/1neQI2W

Release Count Down For Week R-10, Jan 25-29

• Focus: with the second milestone behind us, project teams should be focusing on wrapping up new feature work and stabilizing recent additions.
• Release actions:
  • Strictly enforcing library release freeze before M3 (5 weeks).
  • Review client/integration libraries and whatever other libraries managed by your team.
  • Ensure global requirements and constraints lists are up to date with accurate minimum versions and exclusions.
  • Quite a few projects with unreleased changes on stable/liberty branch. Check for your project [7].
• Important dates:
  • Final release for non client libraries: February 24th
  • Final release for client libraries: March 2nd
  • Mitaka-3: Feb 29 through March 4 (includes feature freeze and soft string freeze).
  • Mitaka release schedule [8].
• Full thread: http://bit.ly/1Qqjqta

Stabilization Cycles: Elaborating on the Idea To Move It Forward

• At the Tokyo summit, the OpenStack Development Theme session, in which people discuss overall focus in shared efforts, having cycles to stabilize projects was brought up.
• A project could decide to spend some percentage of time of the cycle on focusing on bug fixing, review backlog, refactoring, instead of entirely on new features.
• Projects are already empowered to do this, however, maybe the TC could work on formalizing this process so that teams have a reference when they want to.
• Some contributors from the summit feel they need the Technical Committee to take leadership on this, so that they can sell it back to their companies.
• Another side of discussion, healthy projects should naturally come up with bursts of feature additions and burst of repaying technical debt continuously.
  • Imposing specific periods of stabilization prevents reaching that ideal state.
• Full thread: http://bit.ly/1neQIja