Open Stack

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].
- dulled: Conference between Nova and Cinder mid-cycles worked!
- odyssey4me: OpenStack Ansible Kilo 11.2.9 released [2].
- odyssey4me: OpenStack Ansible Liberty 12.0.6 released [3].
- All: https://wiki.openstack.org/wiki/Successes

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

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


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


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


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


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


[1] - https://review.openstack.org/#/c/269908/
[2] - https://launchpad.net/openstack-ansible/+milestone/12.0.6
[3] - https://launchpad.net/openstack-ansible/+milestone/11.2.9
[4] - https://review.openstack.org/#/c/245629/
[5] - https://review.openstack.org/#/c/242852/
[6] - https://review.openstack.org/#/c/183599
[7] - https://review.openstack.org/#/c/243429
[8] - https://review.openstack.org/#/c/273158
[9] - https://review.openstack.org/#/c/243414
[10] - https://review.openstack.org/#/c/196918
[11] - https://review.openstack.org/#/c/273756/
[12] - https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[13] - https://git.openstack.org/cgit/openstack/os-client-config/tree/os_client_config/constructors.json