juju cli api should be invokable outside of units/hooks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pyjuju |
Triaged
|
Low
|
Unassigned |
Bug Description
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-
usage: juju-log [-h] [-o OUTPUT] [-s SOCKET] [--client-id CLIENT_ID]
[-l CRITICAL|
No JUJU_AGENT_
root@ubuntu-
usage: config-get [-h] [-o OUTPUT] [-s SOCKET] [--client-id CLIENT_ID]
No JUJU_AGENT_
Changed in juju: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
summary: |
- juju cli api should be invokable outside of units + juju cli api should be invokable outside of units/hooks |
Changed in juju: | |
milestone: | none → 0.8 |
Changed in juju: | |
status: | Confirmed → Triaged |
Changed in juju: | |
importance: | Medium → Low |
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.