pyjuju

Bug #891868
Comment #2

Comment 2 for bug 891868

Revision history for this message

Kapil Thangavelu (hazmat) wrote on 2011-11-22: Re: [Bug 891868] Re: juju cli api should be invokable outside of units

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.

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.

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.