Juju Stable Update Policy

[Steve Langasek]

Hi Alexis,

Given the lack of response so far, I guess that this is fairly
uncontroversial.

It's clear to me that the client-server nature of juju warrants an exception
to the SRU rules, analogous to the exception already in place for Landscape.

I am also satisfied by the general policies in place for Juju stable
updates, though as you suggest it would be a good idea for the SRU team to
review the specifics in depth with Curtis.

Does anyone else on the TB have any feedback here, or is everyone happy to
ratify this plan as-is?


On Thu, Jun 26, 2014 at 01:00:20PM -0700, Alexis Bruemmer wrote:
> 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,

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20140707/499aec64/attachment.pgp>