Juju Stable Update Policy

Thu Jun 26 20:00:20 UTC 2014

Hello Ubuntu Technical Board,

The Juju Core team requests your review and approval of the Juju Stable
Update Policy outlined below:

Introduction

 Juju is a open source service from Canonical for service orchestration.

 A typical juju install consists of a “cloud environment” which consists of
a set of central state servers and any number of managed services and
machines.  Each managed machine in the environment runs “agents” which talk
to the central state server(s) for that environment.

The package in ubuntu is the “juju client” and is what is used to spin up
cloud servers, bootstrap a set of state servers, and then communicate via a
stable API with one or more state servers about what workloads to deploy
and how to configure them.  The juju client also allows for SSH access
(tunneled through the state servers) to managed machines, as well as the
ability to run actions on sets of machines in the environment.

The juju client can also run a simulated cloud environment on containers
directly on the user’s host box (via the ‘juju-local’ package).

Plans for this cycle include a centralized multi-tenant state servers,
which will serve multiple environments, and be hosted by Canonical, or our
clients.  They also include juju deployed workloads running on a wide
variety of “Host OS’s” including Ubuntu of course, but also Windows and
other versions of Linux/Unix.
As might be expected from this kind of design, there are well defined API’s
that manage the interactions between the state servers and the agents that
run on individual managed hosts, as well as the juju clients that might be
installed on individual user’s machines.

It is critical that the state server and agents be kept in sync, and both
of these sets of machines are created, booted, and managed by Juju.   The
code for the state servers and host machine agents is pulled down by Juju
at install time, and could be running on a completely different
architecture, and even a completely different OS than the juju client
(which is supported on Windows and Mac OS as well as a variety of
linux/unix platforms).  These installs are managed by Juju itself (since it
is a service orchestration and configuration management tool) and do not
use the ubuntu packages -- instead they pull the appropriate juju binary
from the same place they get OS images (simple streams).

It is desirable to update both clients and servers to provide newer
features, but many features of newer servers will be unavailable with older
clients.  And it is possible that security updates on the server will
require compatible client updates.
At present, users of the Juju service are typically instructed to use a PPA
to work around this. However, since the `juju` package is part of Ubuntu,
the juju team needs the ability to push updates into the LTS, otherwise it
is unlikely the version we ship will remain actually useful to juju users.

Rationale

Canonical produces another system management tool, Landscape, which
received a similar exception in 2009.   Like Landscape, we believe Juju’s
requirements as a system management tool make it a candidate for a stable
release update.

In some ways the juju client is subject to less possibility for
destabilizing the OS than Landscape.  As of today it consists of a single
binary (though discussions with the Ubuntu team are in progress to break
that down) which neither has dependencies on any third party libraries, nor
is depended on by any other Ubuntu packages.

Prior to making this request, the Juju Core update process has been updated
to include an exceptionally strict QA process which closely matches that
required of the Landscape client.

Tests are required for all changes, each change must be signed off by two
Juju developers and have a specific QA review, and a variety of fresh
install and upgrade combinations must be explicitly tested on every cloud
that Juju supports (for details see the “Testing a revision” section of the
Juju CI Design and Operation document linked below) .  Furthermore we are
working to create a full set of functional tests of juju deployed workloads
that will be used to gate any stable release.

The Juju team requests that the ubuntu-sru team review these processes in
detail with Curtis (our release and QA manager) and the juju team will
update these test suites with any additional tests that are required to
assure that we provides an acceptable degree of quality assurance.

*Juju CI Design and Operation
<https://docs.google.com/a/canonical.com/document/d/1TVW0QzpLo622pzBUsEK9SqZAod4oJn9ROF1IWMqa9tg/edit#heading=h.f3goroun9jd1>
*

We are fully aware that users of Ubuntu's stable releases require a very
high degree of stability. Any regressions may be extremely disruptive; even
relatively innocuous changes may cause problems if they break known and
deployed workarounds; and experience has taught us to expect the unexpected
at all times.

The best way to maintain stability is simply not to make any changes. Thus
we require that updates to existing juju packages are not only believed to
be safe, but also that the rationale for each update includes benefits that
outweigh the risks of making '''any''' change rather than simply leaving
the package alone.
However, the world changes underneath us, and there are a variety of
special cases where examination indicates that not changing the operating
system is not in fact a guarantee of stability.  In approving the landscape
stable release update policy the Ubuntu Technical board enumerated several
ways in which external change can impact the stability of an unchanged
system.   A few of these are particularly relevant here:

   -

   The set of hardware [and cloud substrates] deployed in the field is
   liable to frequent change, and thus it has been necessary to update stable
   releases with improvements to hardware support: the Linux kernel and the
   `hal-info` package have been updated for this reason.
   -

   The Ubuntu archive contains references to some packages that are not
   part of the Ubuntu archive, to make them easier to find; these references
   need to be updated when external archives change.
   The`app-install-data-partner` package has been updated for this reason.
   -

   Any computer system is subject to external events that cannot be
    ignored, such as changes in daylight savings time imposed by local
    legislation. The `tzdata` package has been updated for this reason.
   -

   Software that interacts with external servers forms part of a larger
   system, only part of which can be controlled by Ubuntu's update policies.
   When the server changes, it is no longer obvious that stasis guarantees
   stability. Packages such as MSN or ICQ clients have been updated for this
   reason.

Juju is built on cloud APIs from Microsoft, Joyent, HP, Openstack, and many
others, and we have been required to push updates that fix juju when those
APIs change in backwards incompatible ways. Likewise juju is subject to
changes in real and virtual machine hardware deployed in the field and in
particular is being used as a test bed for high density server systems with
ARM and Power hardware which provide very rapid moving targets.

As mentioned in the Landscape stable release exception process, the
 “general thread running through these special cases is that we contemplate
updates when the external environment changes in ways that have a
significant effect on Ubuntu packages.” It is our belief that like
Landscape, the juju client represents a core part “of a system where
administrative actions are reasonably expected to be applicable in
parallel.  The system will manage disparate client systems” across multiple
architectures, multiple clouds, and multiple Ubuntu versions, as well as
multiple Non-Ubuntu Operating Systems.

As such, we request that the Technical Board approves a proposed stable
release exception with specific cases at the discretion of the ubuntu-sru
team.

Thank you in advance for your careful review and consideration,

Alexis Bruemmer

Supporting Material:

 Stable Update Exception Criteria - Landscape Approval
<https://docs.google.com/a/canonical.com/document/d/1iSJZM1V_-2GHb9XZxfO4bl9rmNB1sIMc2kgHVQX8mNE/edit?usp=drive_web>

 Juju CI Design and Operation
<https://docs.google.com/a/canonical.com/document/d/1TVW0QzpLo622pzBUsEK9SqZAod4oJn9ROF1IWMqa9tg/edit?usp=drive_web>

 Simple Streams Rationale
<https://docs.google.com/a/canonical.com/document/d/17u3_DfQcWIBLiuxkFtFSdWNxtQTb5dMz2MOAjKyahWM/edit?usp=drive_web>

-- 
Alexis Bruemmer
Juju Core Manager, Canonical Ltd.
(503) 686-5018
alexis.bruemmer at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20140626/13c7462a/attachment-0001.html>