Comment 71 for bug 1267393

This is an answer to some of the questions Seth asked

> In 1339770, in May 2015, it was mentioned that 1.18 was end-of-life and no
> further updates could be prepared for it. 1.18.0 was released just 13
> months earlier and 1.18.1 had been included in 14.04 LTS. Why was the 1.18
> infrastructure torn down so shortly after including 1.18 in a release with
> five-year support?

I believe that this change was primarily brought about by the change
from using bzr to git. The build and test infrastructure had to be
re-tooled to make this work.

> Have there been any similar changes in process that
> would prevent or delay issuing an update to the currently supported
> versions of juju already in the archive?

We are unlikely to change from git.

> It is currently impossible to upgrade from 14.04 LTS to 15.04 due to
> incorrect version numbers. Has anyone else noticed this yet? When will
> this be fixed? Are there any changes in process needed to ensure this
> doesn't happen in the future?

The older versions of Juju were not very good at handling unknown
series. I have targeted a previously created bug to address this:
  https://bugs.launchpad.net/juju-core/+bug/1403689

There are work-arounds that have been used by IS to upgrade older
environments.

We do test a number of upgrade combinations, and I'm curious as to why
you say it is impossible to upgrade? What exactly is the situation you
are attempting?

> Will the juju team be asking for an MRE? Is it anticipated that new series
> (e.g., the 1.18 to 1.22 change) would be included as an MRE? What
> processes are in place to test updates before including updates into the
> archive? What processes are available to the security team to test
> updates that we would prepare?

There are CI tests around upgrading from older versions to the current
tested release. I believe that one of these tests includes going from
1.18 to the current tested release.

> I had more trouble reading the Juju code this review cycle than last
> review cycle -- the Facade indirection mechanism makes code navigating
> harder. I'm worried about it for a few reasons:
> - Strings to reference method names are brittle and can't be checked at
> compile time. What methods are in place to ensure that these aren't
> typoed?

There are unit tests in place that test both the client and server side
of every call, and in addition to that there are full feature tests that
make sure all the parts align.

> - Generic args and return types defeat type checking. What ensures types
> being returned or accepted have the desired properties?

The specified unit and feature tests.

> - Java has had significant problems with their Reflection mechanism,
> probably dozens of issues per year. At what points of a process
> lifetimes is the Facade mechanism dynamic?

During the low level RPC call from the client to the API server.

> Here's a few issues I found:
>
> - ./apiserver/apiserver.go logs passwords when tracing is enabled -- this
> is fine IFF this is loudly documented somewhere obvious. Is it? It'd be
> best to filter out passwords regardless.

I have created a bug to address this more completely:
  https://bugs.launchpad.net/juju-core/+bug/1500298

> - Chown() doesn't quote the user or group

In which cases is this really necessary? All the chowns that the Juju
code base does is to either ubuntu, syslog or adm. Other chowns copy the
uid/gid directly from the source.

> - ./api/client.go WatchDebugLog() claims to read a line but looks like it
> may read up to 4096 bytes -- is this correct?

The first line returned in the WatchDebugLog is a serialized error, and
only a serialized error. The size of the error is always less than 200
bytes, but 4k is a nice block size. Once this initial error has been
returned, the websocket is used as a stream.

> - significant number of TODO comments; is there a method in place to find
> unowned comments and assign them somewhere? is there a process in place
> to ensure they get revisited?

I don't believe we have a formal process at this stage. New TODO
comments are expected to have an associated bug, and a date.

> - Which versions of the client work with which versions of the servers?
> Where's that described?

All clients from 1.18 on should work with any API server. This is the
expected behaviour until at least Juju 2.0.

> - ./api/keyupdater/authorisedkeys.go AuthorisedKeys(),
> WatchAuthorisedKeys() expects exactly one authorized key, this seems
> fragile

I believe it expects one string, which may be multi-line, and each key
is on a different line.

> - Is -static-libgo still being used?

No idea sorry.

> I'm concerned with how previous issues have been handled -- the three
> referenced bug reports have combined to represent the single most
> expensive consequence I've personally seen and all were known issues five
> months earlier. So I need reassurance that the Juju team will help the
> security team maintain Juju in our supported releases:
>
> - Ask for an MRE, if that's the most appropriate mechanism to update Juju.
> - Ask for special treatment that allow more frequent full-version updates,
> if that's the most appropriate mechanism to update Juju.
> - Commitment to help the security team diagnose and prepare fixes.
> - Commitment to help the security team backport fixes to all supported
> versions, as necessary.
> - Commitment to help the security team prepare test cases and use testing
> infrastructures.

Commitment to helping the security team deal with any Juju problem will
not be an issue. Of course the team is there to help.