[Openstack-operators] OpenStack Developer Mailing List Digest April 23 - May 6
mike at openstack.org
Mon May 9 21:36:35 UTC 2016
HTML version: http://www.openstack.org/blog/2016/05/openstack-developer-mailing-list-digest-20160506/
Success Bot Says
* Sdague: nova-network is deprecated 
* 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
- 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
- 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 , 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
* All guides will be rendered from individual repositories and appear in
* The Documentation team has recommendations for projects writing their install
- Build on existing install guide architecture, so there is no reinventing
- Follow documentation conventions .
- 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
- Common naming scheme: “X Service Install Guide” - where X is your service
* The chosen URL format is
* Plenty of work items to follow  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
* 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. 
* 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
* An amended Technical Committee resolution will follow to suggest Go as
a supported language in OpenStack projects .
* 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
- 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” .
* Release Actions
- Release liaisons should add their name to and contact information to this
- Release liaisons should have their IRC clients join #openstack-release.
* Important Dates
- Newton 1 Milestone: R-18 June 2nd
- Newton release schedule 
* 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 , but things
can still be improved.
* Trove has a spec proposal  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 
- DevStack doesn't allow you to enable Nova file injection, and hard sets it
- 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
* 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
- 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 .
* 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 
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-May/093937.html
 - https://review.openstack.org/#/c/310539/
 - http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160318-2/
 - http://docs.openstack.org/contributor-guide/
 - http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html#work-items
 - https://review.openstack.org/311476
 - http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html
 - http://governance.openstack.org/resolutions/20150901-programming-languages.html
 - https://review.openstack.org/#/c/312762
 - https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
 - http://releases.openstack.org/newton/schedule.html
 - http://docs.openstack.org/developer/trove/dev/building_guest_images.html
 - https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst#writing-an-element
 - https://review.openstack.org/#/c/295274/
 - https://review.openstack.org/#/c/70239/
 - https://review.openstack.org/#/c/194586/
 - http://git.openstack.org/cgit/openstack-infra/project-config/tree/tools/build-image.sh
 - https://review.openstack.org/#/c/312805/
 - https://review.openstack.org/#/c/312806/
More information about the OpenStack-operators