<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 17, 2013 at 7:20 AM, John Arbash Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
>> I believe the rationale was so that juju-run can target machines<br>
>> as well as units. To target a machine without any units deployed<br>
>> would mean hooks are out of the question.<br>
><br>
<br>
</div>Then just run a hook context runner in the Machine agent. Still *much*<br>
better than actually needing to SSH into every machine and violating<br>
the model of every-other-way we run stuff on machines in the environment.<br></blockquote><div><br></div><div>It's not quite that simple: a hook context demands a bunch of unit-specific information. Faking up that information for a "machine context" with the same tools available is not likely to be very helpful; the only point of similarity, I think, is that machine commands usually want to be serialized with unit commands and hook executions.</div>
<div><br></div><div>To speak to your larger point: we have a *very* specific mechanism for running hooks on remote units, and most of that mechanism is simply inapplicable here; the choice of what hooks to run is determined by the individual units, after interpreting remote state in the context of local state, and the API server certainly knows nothing about hooks. So, ofc, it is perfectly reasonable to suggest that this sort of functionality be mediated by the API (even if it doesn't entirely replace the need for live SSH access), but it's not as simple as paraphrasing "we have the functionality, let's use it". </div>
<div><br></div><div>To speak to tim's general points -- we cannot indeed assume that users have ssh keys, or even that they are entirely au fait with what ssh keys are and do. Allowing those users to negotiate a bootstrap without confronting that topic is clearly a Good Thing, and we must be prepared to allow *new* users to be able to bootstrap environments from a GUI alone; and ofc we can support these use cases with the key-updating stuff we just wrote. So for those reasons, yes, we should generate environment identities.</div>
<div><br></div><div>But the juju-run perspective STM to favour jam's views. Live SSH access for individual users must surely be done via the user's own SSH key -- it doesn't seem like an API connection is really very well suited to this use case -- but the user who wants to `apt-get upgrade` across a few thousand machines is probably not well served by an architecture that demands that *anything* make a separate SSH connection to each machine.</div>
<div><br></div><div>So, I endorse the general idea of an environment identity, but I don't think it's the right mechanism for bulk juju-run commands. There's clearly open space for extracting the  serialized execution context code (that can be reused by unit and machine agents [0]); there's surely an opportunity for us to write new code that delivers those commands to either unit or machine agents; and there may even be some possibility of integrating that delivery code with the hook queuing mechanism to make that code more generally useful [1].</div>
<div><br></div><div>WRT juju-run in particular, I think it's more important to figure out the right API-based delivery mechanism than to add environment identities; those *are* important too, but I don't think they're really part of this work.</div>
<div><br></div><div>Cheers</div><div>William</div><div><br></div><div><br></div><div><br></div><div>[0] There's *also* definitely a use case for executing code directly on a machine *outside* a serialized context, and we mustn't cut this off. This should not be the default, though.</div>
<div><br></div><div>[1] at the moment we don't have any ability to set priority across queues for different relations.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im"><br>
John<br>
=:-><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.13 (Cygwin)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div>iEYEARECAAYFAlKv7T0ACgkQJdeBCYSNAAPsLwCfVDV/adPkzKk8RfIhEJgCZEEl<br>
gU4An3TxGlipHH2FhDFlH8YSlfPtdOrN<br>
=EDgS<br>
<div class=""><div class="h5">-----END PGP SIGNATURE-----<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br></div></div>