<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>Hello Ubuntu Technical Board, </div><div> </div><div>The Juju Core team requests your review and approval of the Juju Stable Update Policy outlined below:</div> <div> </div> <div>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. <a href="https://docs.google.com/a/canonical.com/document/d/1TVW0QzpLo622pzBUsEK9SqZAod4oJn9ROF1IWMqa9tg/edit#heading=h.f3goroun9jd1" target="_blank">Juju CI Design and Operation</a> 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: <ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"> 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. </li><li dir="ltr" style="list-style-type:disc;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"> 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. </li><li dir="ltr" style="list-style-type:disc;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"> 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. </li><li dir="ltr" style="list-style-type:disc;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"> 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. </li></ul> 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: <div class="gmail_chip gmail_drive_chip" style="width:396px;min-height:18px;max-height:18px;background-color:#f5f5f5;padding:5px;color:#222;font-family:arial;font-style:normal;font-weight:bold;font-size:13px;border:1px solid #ddd"> <a href="https://docs.google.com/a/canonical.com/document/d/1iSJZM1V_-2GHb9XZxfO4bl9rmNB1sIMc2kgHVQX8mNE/edit?usp=drive_web" style="display:inline-block;max-width:366px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;text-decoration:none;padding:1px 0;border:none" target="_blank"><img style="vertical-align:bottom;border:none" src="https://ssl.gstatic.com/docs/doclist/images/icon_11_document_list.png"> Stable Update Exception Criteria - Landscape Approval</a></div> <div class="gmail_chip gmail_drive_chip" style="line-height:1.15;font-size:13px;width:396px;min-height:18px;max-height:18px;background-color:rgb(245,245,245);padding:5px;font-family:arial;font-weight:bold;border:1px solid rgb(221,221,221)"> <a href="https://docs.google.com/a/canonical.com/document/d/1TVW0QzpLo622pzBUsEK9SqZAod4oJn9ROF1IWMqa9tg/edit?usp=drive_web" style="display:inline-block;max-width:366px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;text-decoration:none;padding:1px 0;border:none" target="_blank"><img style="vertical-align:bottom;border:none" src="https://ssl.gstatic.com/docs/doclist/images/icon_11_document_list.png"> Juju CI Design and Operation</a></div> <div class="gmail_chip gmail_drive_chip" style="width:396px;min-height:18px;max-height:18px;background-color:#f5f5f5;padding:5px;color:#222;font-family:arial;font-style:normal;font-weight:bold;font-size:13px;border:1px solid #ddd"> <a href="https://docs.google.com/a/canonical.com/document/d/17u3_DfQcWIBLiuxkFtFSdWNxtQTb5dMz2MOAjKyahWM/edit?usp=drive_web" style="display:inline-block;max-width:366px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;text-decoration:none;padding:1px 0;border:none" target="_blank"><img style="vertical-align:bottom;border:none" src="https://ssl.gstatic.com/docs/doclist/images/icon_11_document_list.png"> Simple Streams Rationale</a></div> -- </div></div></div></div></div></div></div></div><div dir="ltr">Alexis Bruemmer<div>Juju Core Manager, Canonical Ltd.</div><div>(503) 686-5018</div><div><a href="mailto:alexis.bruemmer@canonical.com" target="_blank">alexis.bruemmer@canonical.com</a></div> </div> </div>