juju system ssh keys - revisiting

[William Reade]

On Tue, Dec 17, 2013 at 7:20 AM, John Arbash Meinel
<john at arbash-meinel.com>wrote:
>
> >> I believe the rationale was so that juju-run can target machines
> >> as well as units. To target a machine without any units deployed
> >> would mean hooks are out of the question.
> >
>
> Then just run a hook context runner in the Machine agent. Still *much*
> better than actually needing to SSH into every machine and violating
> the model of every-other-way we run stuff on machines in the environment.
>

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.

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

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.

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.

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

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.

Cheers
William



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

[1] at the moment we don't have any ability to set priority across queues
for different relations.


>
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (Cygwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKv7T0ACgkQJdeBCYSNAAPsLwCfVDV/adPkzKk8RfIhEJgCZEEl
> gU4An3TxGlipHH2FhDFlH8YSlfPtdOrN
> =EDgS
> -----END PGP SIGNATURE-----
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131217/6e21b04f/attachment.html>