Do we care about 1.16 compatibility for 'juju add-machine ssh:user at host" ?

[William Reade]

On Sun, Dec 8, 2013 at 2:35 PM, John Arbash Meinel
<john at arbash-meinel.com>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So I'm trying to finish the work to maintain compatibility between
> trunk and 1.16 for all commands.
>
> I think I've finished everything except for manual provisioning.
> However, this rabbit hole keeps getting deeper, so I wanted to ask how
> much we really care.
>
> The issues I've run into so far:
>   lp:~jameinel/juju-core/add-machine-manual-compat-1253631
>
> 1) Code factoring. We have a call to 'recordMachineInState' which
> actually does a bit of work to figure out what state the machine is in
> (series, arch, etc) and then directly calls the API. I have one change
> which I think makes it much nicer, which is to have 1 call to gather
> the information, and then a *different* function to actually record
> it. (That way the gather step can be reused when we have to fall back
> to direct DB manipulation).
>

+1, that sounds like the right factoring to me.

However, it actually doesn't really do what we want anyway. The code
> in question detects that we had an error after allocating a machineId,
> and then tries to clean up by calling DestroyMachine. It is fairly
> likely, though, that the machine agent will never actually come up.
>

I don't follow. If there's no machine id, there's no machine, and no need
to destroy it.

It seems like a lot of busy work to end up with a machine that is in a
> bad state.
>

So, do we (1) figure out what to run (series, arch) and whether it's
possible; (2) add that machine to state; (3) start the agent on the machine?

If (2) fails, we shouldn't have changed the machine; and if (3) fails I
agree we need a fast path to just nuke the machine in state, but it's
surely not going to leave the actual system in a confused state, is it?

4) Client.MachineConfig didn't exist in 1.16. This is probably the
> biggest deal. The API actually does a lot of work. It grabs the API
> and State addresses, looks up tools for the machine (in the provider),
> and sets up a new Machine ID + Password combination for the agent.
>
> The big thing is having to reproduce all that chunk of code seems like
> a PITA and searching for tools from the client is annoying to do again.
>

I'm willing to pay an additional tools lookup to keep manual provisioning
in sync with everything else; and ISTM that this is otherwise just a matter
of moving that code temporarily to a shared location (like statecmd), and
then putting it back into the api server directly when we don't need direct
db access any more. Am I missing something?

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131208/de332fe5/attachment.html>