juju cli api should be invokable outside of units/hooks

[Kapil Thangavelu]

At least for read only, config-get, relation-list, relation-get, juju-log should all default to known unit container locations for socket and client id

root@ubuntu-sample-apache-django-wsgi-12:/var/lib/juju/units/apache-django-wsgi-12/charm# juju-log "normal log"
usage: juju-log [-h] [-o OUTPUT] [-s SOCKET] [--client-id CLIENT_ID]
                [--format FORMAT] [--log-file FILE]
                [--log-level CRITICAL|DEBUG|INFO|ERROR|WARNING]
                [-l CRITICAL|DEBUG|INFO|ERROR|WARNING]
                message [message ...]
No JUJU_AGENT_SOCKET/-s option found

root@ubuntu-sample-apache-django-wsgi-12:/var/lib/juju/units/apache-django-wsgi-12/charm# config-get app-source
usage: config-get [-h] [-o OUTPUT] [-s SOCKET] [--client-id CLIENT_ID]
                  [--format FORMAT] [--log-file FILE]
                  [--log-level CRITICAL|DEBUG|INFO|ERROR|WARNING]
                  [option_name]
No JUJU_AGENT_SOCKET/-s option found

[Jim Baker (jimbaker)]

Making these commands invocable outside of hooks would certainly be useful, especially for triggering action in Juju, not to mention debugging. But it seems likely to have security and other implications.

One alternative to consider is to make it possible to externally trigger hook execution in a unit agent. Such triggering could be done by cron, puppet, or some other tool, based on knowledge that something interesting has happened outside of Juju, but that orchestration is now needed to respond to it.

Such hooks (possibly just -relation-changed or a new hook like "external") could access arbitrary channels (such as the local file system, etc, etc), then publish any desired changes to relation settings, as normal.

Some possible minimal syntax to trigger running a possible "external" hook:

$ trigger-hook <service-unit>

Schedules hook to be run in the lifecycle of the agent, with normal one-at-time sequencing of hooks occurring.

[Kapil Thangavelu (hazmat)]

Excerpts from Jim Baker's message of Fri Nov 18 00:35:58 UTC 2011:
> Making these commands invocable outside of hooks would certainly be
> useful, especially for triggering action in Juju, not to mention
> debugging.

The main purpose would be to allow external access to juju data. Triggering juju
actions is out of scope (ie. its read only usage.)

> But it seems likely to have security and other implications.
>

Its already available, the implementation here removes the obscurity of
parameter passing. Security needs to rely on other mechanisms. We don't assume
security at a container/unit level as we're already deploying third party
charms as root with unknown software payloads. ie we assume compromised
containers, and security is focused on ensuring compromises can't propogate.

> One alternative to consider is to make it possible to externally trigger
> hook execution in a unit agent. Such triggering could be done by cron,
> puppet, or some other tool, based on knowledge that something
> interesting has happened outside of Juju, but that orchestration is now
> needed to respond to it.

That sort of event based reaction is something i think best left driving an
explicit juju control tier (ie. rest api). I've got a spec in the works on the
topic.

>
> Such hooks (possibly just -relation-changed or a new hook like
> "external") could access arbitrary channels (such as the local file
> system, etc, etc), then publish any desired changes to relation
> settings, as normal.
>

I'm rather wary of arbitrary hook execution driven externally, We'd be violating
our hook contracts.

> Some possible minimal syntax to trigger running a possible "external"
> hook:
>
> $ trigger-hook <service-unit>
>
> Schedules hook to be run in the lifecycle of the agent, with normal one-
> at-time sequencing of hooks occurring.
>

While this is potentially useful, its a rather different topic then the one
filed under this bug (ie. external access to juju data). If its of interest
i'd suggest capturing it in a different bug report.

[Marius B. Kotsbak (mariusko)]

This also makes it hard to add notifications about new commits for using git based deployments, as the notification must be triggered from a git hook or http script. See blueprint:

https://blueprints.launchpad.net/juju/+spec/juju-charm-app-git-deployment

[Marius B. Kotsbak (mariusko)]

So what is the recommended workaround here? I guess some communication channel needs to be established during the relation hooks then, exchanging IP/port/URL and authentication. Do the machines contain some sort of common passwords or ssh keys? I assume that we must assume that the machines are in a semi-public network.

[Marius B. Kotsbak (mariusko)]

That was about relation, but what should the workaround be for "config-get"? To save the configuration somewhere in the file system? Where should that be then?