<div dir="ltr">On Sun, Dec 8, 2013 at 2:35 PM, John Arbash Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
So I'm trying to finish the work to maintain compatibility between<br>
trunk and 1.16 for all commands.<br>
<br>
I think I've finished everything except for manual provisioning.<br>
However, this rabbit hole keeps getting deeper, so I wanted to ask how<br>
much we really care.<br>
<br>
The issues I've run into so far:<br>
  lp:~jameinel/juju-core/add-machine-manual-compat-1253631<br>
<br>
1) Code factoring. We have a call to 'recordMachineInState' which<br>
actually does a bit of work to figure out what state the machine is in<br>
(series, arch, etc) and then directly calls the API. I have one change<br>
which I think makes it much nicer, which is to have 1 call to gather<br>
the information, and then a *different* function to actually record<br>
it. (That way the gather step can be reused when we have to fall back<br>
to direct DB manipulation).<br></blockquote><div><br></div><div>+1, that sounds like the right factoring to me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

However, it actually doesn't really do what we want anyway. The code<br>
in question detects that we had an error after allocating a machineId,<br>
and then tries to clean up by calling DestroyMachine. It is fairly<br>
likely, though, that the machine agent will never actually come up.<br></blockquote><div><br></div><div>I don't follow. If there's no machine id, there's no machine, and no need to destroy it.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seems like a lot of busy work to end up with a machine that is in a<br>
bad state.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>
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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) Client.MachineConfig didn't exist in 1.16. This is probably the<br>
biggest deal. The API actually does a lot of work. It grabs the API<br>
and State addresses, looks up tools for the machine (in the provider),<br>
and sets up a new Machine ID + Password combination for the agent.<br>
<br>
The big thing is having to reproduce all that chunk of code seems like<br>
a PITA and searching for tools from the client is annoying to do again.<br></blockquote><div><br></div><div>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?</div>
<div><br></div><div>Cheers</div><div>William</div></div></div></div>