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

[John Arbash Meinel]

-----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).

2) Client.InjectMachine was not in 1.16, not a big deal, we can invoke
the State.InjectMachine directly (after casting some parameters
because state.MachineJob is not a params.MachineJob)

3) Client.DestroyMachines was not in 1.16. We might be adding it in
1.16.5, but for now it doesn't exist.

The code that *used* to exist in state was moved solely into the API
Server. Now for "juju destroy-machine" we copied the old code as
'cmd/juju/destroymachine.go destroyMachines".

I *could* put that code back into State, since we now have two places
that want it.

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.
And 1.16 *also* doesn't have ForceDestroyMachines. Which means while
it tries to "clean up" it really only sets the machine to
"agent-state: Pending, life: Dying". and never really goes away.

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

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.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKkdYgACgkQJdeBCYSNAAO7+QCgiCRMSS/qZ2+2Z0efYnTRgdDt
zeQAn1gNNu8gQxu3zKqV9Z1wW5BbG/cT
=q07k
-----END PGP SIGNATURE-----