OpenStack Developer Mailing List Digest Jan 23 – Feb 5

February 5, 2016

SuccessBot Says

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://lists.openstack.org/pipermail/openstack-dev/2016-January/085145.html

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://lists.openstack.org/pipermail/openstack-dev/2016-January/084963.html

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://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html

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://lists.openstack.org/pipermail/openstack-dev/2016-February/085855.html

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://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html

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://lists.openstack.org/pipermail/openstack-dev/2016-January/084739.html