Juju on MAAS agent tools upgrade mechanism

[Mark Shuttleworth]

On 01/09/15 13:44, Peter Grandi wrote:
>> https://bugs.launchpad.net/juju-core/+bug/1447899 The bug is
>> fixed in the recently released 1.25-alpha1.  What you can try on
>> your system is to explicitly specify the version you want to
>> upgrade to:
> Had a look and forgot to mention that I tried that and got "ERROR
> no matching tools available", that's why I tried to build a local
> cache with known metadata content.
>
> As it is so typical ("cannot read file" style...), the error
> message does not say which component it came from and which
> version it was trying to match against, and in which list it was
> trying to match it.


This would be a nice introductory code contributions project:

 * review error messages for usefulness and clarity to a new user
   - fix those that can be improved directly and simply

 * review the architecture of tools and bootstrapping

I myself find the term "tools" to be misleading, to the point that I
wouldn't be surprised if someone follows up to this email to correct my
understanding as expressed below :)

AIUI there are only three bodies of code, and we should call them what
they are, which is:

 * the client ("juju") which is cross-platform and runs from your laptop
/ desktop as a CLI

 * the server which could also be cross-platform and provides the
central API / DB

 * the agents which run on each machine or unit being managed

The messages you describe would be much clearer to me if it was explicit
that it was the *agent* code that was being downloaded to the *server*
so that it can be sent to the machines-and-containers-and-units that are
spun up dynamically.

I also think that this could take advantage of another significant
change, which is the move to having multiple "environments" hosted on a
single Juju server. If you think about it, you may well want to have
different versions of the agent as the default for each different
environment, so it makes sense to have "agent-version" as a property of
the environment. But even then, think of each individual machine being
driven in that environment. When you change the agent-version for the
environment, each machine will have to go through an upgrade process
(modulo netflix-style upgrades where you grow new machines of the new
versions while leaving the old ones immutable till you kill them :)). So
that means its likely that the Juju server knows:

 * for each environment, the default agent-version ("tools")

 * for each machine / container / unit in the environment, the ACTUAL
agent-version

There is a good opportunity here to clean this all up, making the
various pieces more explicit and hence understandable.

As a straw man proposal:

"juju bootstrap [--version X]"

  - is a command of the juju client (which knows its own version)
  - should start the same server version as the juju client if no
--version is specified
  - should use version X of the server if specified and compatible with
the client
     - should error if version X does not exist or is not compatible
with the client

"juju create-environment [--version X]"

 - is a command of the client which we assume to be compatible with the
server
 - should create an environment with agent-version the same as the
*server* unless --version is specified
 - should error if the agent-version is not compatible with the *server*
(since agent talks to server)


Would that be more understandable for you?

Anybody see a major problem with that?

Then we could have:

  $ juju version            # shows the version of client, server and agent
  Client 1.25.2
  Server 1.25.1
  Agent 1.24.5

Or specific ones like:

  $ juju version --server
  Server 1.25.1


> * http://wiki.cloudbase.it/juju-centos
>
>     «Now you should edit the environments.yaml file in
>     ~/.juju. Make maas the default provider. Then in the section
>     for maas configuration set: agent-metadata-url:
>     http://<MaaS-Machine-IP>/tools»
>
> My impression overall is that Juju with MAAS or private cloud is
> not a priority ("abandonware"? "scratch-your-itch"?) and therefore
> I need to reverse engineer it and find a workaround based on
> understanding how it is *supposed* to work and how it *actually*
> works, considering that the 'juju-core' package is 1.24.5 and the
> 'jujud' instances in the units are still 1.23.3.
>
> So my request for help in understanding how it is *supposed* to
> work for MAAS.

Part of what you are seeing there is work done by the excellent folks at
CloudBase to add support for CentOS as a first class platform in Juju.

It looks like that page documents the process needed to build the
relevant agent on CentOS and publish it to your Juju server so that
CentOS machines will have agents delivered to them that work on CentOS.
The page was needed before CentOS support landed upstream; that work is
now either already "upstream" in mainline Juju or close to that goal.
Once it's upstream and released as part of a normal Juju release, the
CentOS agents should "just work" and you wouldn't need a custom build of
the agents just to have CentOS machines in the mix. So hopefully you
don't actually need that page or those steps at all; just using a
CentOS-ready release of Juju (1.24? 1.25?) would "just work" with
managed CentOS machines.

In fact, I think there is likely work going on to generalise that so
that the Juju SERVER might be on CentOS (or even Windows), which is
great. Don't be put off by the fact that some pre-release stuff is
available with some custom hackery needed to activate it!

MAAS is very much a target environment for us, the combination of
MAAS+Juju lets us bring amazing workloads to the bare metal. So
currently, for example, there is a lot of joint work between the MAAS
and Juju teams to line things up for networking and storage so that you can:

 * commission a load of hardware in MAAS
 * automatically detect, test and tag the NICs and disks
 * easily specify rules for bonding NICS and RAIDING disks
 * juju deploy OpenStack beautifully

There are, as you can imagine, quite a few details to get right, but if
you look in Juju 1.25-alpha and MAAS 1.9-alpha you'll see the storage
pieces in MAAS looking pretty good, and the networking stuff for Juju
mainly expressed in the AWS environment but coming soon to MAAS too.

Mark