The content below is taken from the original (OpenStack Developer Mailing List Digest April 23 – May 6), to continue reading please visit the site. Remember to respect the Author & Copyright.
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
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
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 http://bit.ly/1ZywxtK.
- Plenty of work items to follow [4] and volunteers are welcome!
- Full thread
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
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
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
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.
- 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.
- 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].
- Libguestfs manipulates images in a clean helper VM created by libguestfs in a predictable way.
- 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.
- Full thread