Open Stack

HTML version: http://www.openstack.org/blog/2016/05/openstack-developer-mailing-list-digest-20160506/

Success Bot Says
================
* Sdague: nova-network is deprecated [1]
* Ajaeger: OpenStack content on Transifex has been removed, Zanata on
  translate.openstack.org has proven to be stable platform for all translators
  and thus Transifex is not needed anymore. 
* All: https://wiki.openstack.org/wiki/Successes


Backwards Compatibility Follow-up
=================================
* Agreements from recent backwards compatibility for clients and libraries
  session:
  - Clients need to talk to all versions of OpenStack. Clouds.
  - Oslo libraries already do need to do backwards compatibility.
  - Some fraction of our deploys between 1% to 50% are trying to do in place
    upgrades where for example Nova is upgrade, and Neutron later. But now
    Neutron has to work with the upgraded libraries from the Nova upgrade.
* Should we support in-place upgrades? If we do, we need at least 1 or more
  versions of compatibility where Mitaka Nova can run Newton Oslo+client
  libraries.
  - If we don't support in-place upgrades, deployment methods must be
    architected to avoid ever encountering where a client or one of N services
    is going to be upgraded on a single python environment. All clients and
    services must be upgraded together on a single python environment or none.
* If we decide to support in-place upgrades, we need to figure out how to test
  that effectively; its a linear growth with the number of stable releases we
  choose to support.
* If we decide not to, we have no further requirement to have any cross-over
  compatibility between OpenStack releases.
* We still have to be backwards compatible on individual changes.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-April/thread.html#93403


Installation Guide Plans for Newton
===================================
* Continuing from a previous Dev Digest [2], big tent is growing and our
  documentation team would like for projects to maintain their own installation
  documentation. This should be done while still providing quality in valid
  working installation information and consistency the team strives for.
* The installation guide team held a session at the summit that was packed and
  walked away with some solid goals to achieve for Newton.
* Two issues being discussed:
  - What to do with the existing install guide.
  - Create a way for projects to write installation documentation in their own
    repository.
* All guides will be rendered from individual repositories and appear in
  docs.openstack.org.
* The Documentation team has recommendations for projects writing their install
  guides:
  - Build on existing install guide architecture, so there is no reinventing
    the wheel.
  - Follow documentation conventions [3].
  - Use the same theme called openstackdocstheme.
  - Use the same distributions as the install guide does. Installation from
    source is an alternative.
  - Guides should be versioned.
  - RST is the preferred documentation format. RST is also easy for
    translations.
  - Common naming scheme: “X Service Install Guide” - where X is your service
    name.
* The chosen URL format is
  docs.openstack.org/project-install-guide/RELEASE/SERVICE.
* Plenty of work items to follow [4] and volunteers are welcome!
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-April/093475.html


Proposed Revision To Magnum's Mission
=====================================
* From a summit discussion, there was a proposed revision to Magnum's mission
  statement [5].
* The idea is to narrow the scope of Magnum to allow the team to focus on
  making popular container orchestration engines (COE) software work great with
  OpenStack. Allowing users to setup fleets of cloud capacity managed by COE's
  such as Swarm, Kubernetes, Mesos, etc.
* Deprecate /containers resource from Magnum's API. Any new project may take on
  the goal of creating an API service that abstracts one or more COE's.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-April/093542.html


Supporting the Go Programming Language
======================================
* The Swift community has a git branch feature/hummingbird that contains some
  parts of Swift reimplemented in Go. [6]
* The goal is to have a reasonably read-to-merge feature branch ready by the
  Barcelona summit. Shortly after the summit, the plan is to merge the Go code
  into master.
* An amended Technical Committee resolution will follow to suggest Go as
  a supported language in OpenStack projects [7].
* Some Technical Committee members have expressed wanting to see technical
  benefits that outweigh the community fragmentation and increase in
  infrastructure tasks that result from adding that language.
* Some open questions:
  - How do we run unit tests?
  - How do we provide code coverage?
  - How do we manage dependencies?
  - How do we build source packages?
  - Should we build binary packages in some format?
  - How to manage in tree documentation?
  - How do we handle log and message string translations?
  - How will DevStack install the project as part of a gate job?
* Designate is also looking into moving a single component into Go.
  - It would be good to have two cases to help avoid baking any project
    specific assumptions into testing and building interfaces.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-May/thread.html#93795


Release Countdown for Week R-21, May 9-13
=========================================
* Focus
  - Teams should be focusing on wrapping up incomplete work left over from the
    end of the Mitaka cycle.
  - Announce plans from the summit.
  - Completing specs and blueprints.
* General Notes
  - Project teams that want to change their release model tag should do so
    before the Newton-1 milestone. This can be done by submitting a patch to
    governance repository in the projects.yaml file.
  - Release announcement emails are being proposed to have their tag switched
    from “release” to “newrel” [8].
* Release Actions
  - Release liaisons should add their name to and contact information to this
    list [9].
  - Release liaisons should have their IRC clients join #openstack-release.
* Important Dates
  - Newton 1 Milestone: R-18 June 2nd
  - Newton release schedule [10]
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-May/094082.html


Discussion of Image Building in Trove
=====================================
* A common question the Trove team receives from new users is how and where to
  get guest images to experiment with Trove.
  - Documentation exists in multiple places for this today [11][12], but things
    can still be improved.
* Trove has a spec proposal [13] for using libguestfs approach to building
  images instead of using the current diskimage-builder (DIB).
  - All alternatives should be equivalent and interchangable.
  - Trove already has elements for all supported databases using DIB, but these
    elements are not packaged for customer use. Doing this would be a small
    effort of providing an element to install the guest agent software from
    a fixed location.
  - We should understand the deficiencies if any in DIBof switching tool
    chains. This can be be based on Trove and Sahara's experiences.
* The OpenStack Infrastructure team has been using DIB successfully for a while
  as it is a flexible tool.
  - By default Nova disables file injection [14]
  - DevStack doesn't allow you to enable Nova file injection, and hard sets it
    off [15].
  - Allows to bootstrap with yum of debootstrap
  - Pick the filesystem for an existing image.
* Lets fix the problems with DIB that Trove is having and avoid reinventing the
  wheel.
* What are the problems with DIB, and how do they prevent Trove/Sahara users
  from building images today?
  - Libguestfs manipulates images in a clean helper VM created by libguestfs in
    a predictable way.
    + Isolation is something DIB gives up in order to provide speed/lower
      resource usage.
  - In-place image manipulation can occur (package installs, configuration
    declarations) without uncompressing or recompressing an entire image.
    + It's trivial to make a DIB element which modifies an existing image and
      making it in-place.
  - DIB scripts' configuration settings passed in freeform environment
    variables can be difficult to understand document for new users. Libguestfs
    demands more formal formal parameter passing.
  - Ease of “just give me an image. I don't care about twiddling knobs”.
    + OpenStack Infra team already has a wrapper for this [16].
* Sahara has support for several image generation-related cases:
  - Packing an image pre-cluster spawn in Nova.
  - Building clusters from a “clean” operating system image post-Nova spawn.
  - Validating images after Nova spawn.
* In a Sahara summit session, there was a discussed plan to use libguestfs
  rather than DIB with an intent to define a linear, idempotent set of steps to
  package images for any plugin.
* Having two sets of image building code to maintain would be a huge downside.
* What's stopping us a few releases down the line deciding that libguestfs
  doesn't perform well and we decide on a new tool? Since DIB is an OpenStack
  project, Trove should consider support a standard way of building images.
* Trove summit discussion resulted in agreement of advancing the image builder
  by making it easier to build guest images leveraging DIB.
* Project repository proposals have been made [17][18]
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-May/093937.html


[1] - https://review.openstack.org/#/c/310539/
[2] - http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160318-2/
[3] - http://docs.openstack.org/contributor-guide/
[4] - http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html#work-items
[5] - https://review.openstack.org/311476
[6] - http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html
[7] - http://governance.openstack.org/resolutions/20150901-programming-languages.html
[8] - https://review.openstack.org/#/c/312762
[9] - https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
[10] - http://releases.openstack.org/newton/schedule.html
[11] - http://docs.openstack.org/developer/trove/dev/building_guest_images.html
[12] - https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst#writing-an-element
[13] - https://review.openstack.org/#/c/295274/
[14] - https://review.openstack.org/#/c/70239/
[15] - https://review.openstack.org/#/c/194586/
[16] - http://git.openstack.org/cgit/openstack-infra/project-config/tree/tools/build-image.sh
[17] - https://review.openstack.org/#/c/312805/
[18] - https://review.openstack.org/#/c/312806/