cf-charmers team mailing list archive

[Whit Morriss <whit.morriss@xxxxxxxxxxxxx>]

Hey Alex,


> Currently service declaration have only two ways to determine relations of
> CF components: `required_data` and `provided_data`. What about handling
> optional relationships? As I see they are not provided, but what if I want
> to use Munin, but not Graphite with Collector component.
>

The GraphiteContext returns True for any call to ctx.is_ready().  This is a
bit of hack, an explicit interface would be preferable, and a context
written this way has to deal with calls with incomplete data.

Wrt additional relationships, the collector only support emit to carbon and
opentsb by the cf-release config.  The app itself supports plugins and I
suppose you could patch something in (there is an http posting plugin by
default).

WRT to munin specifically, iirc munin operates by running procs on a local
machine and shipping the metrics by to a master daemon which shoves them in
RRD.  I'm guessing you would need some extra piping to get data out of the
collector, and a script for the munin agent to run.   If you were implement
this, in theory I think these would be the steps:

  - add a munin plugin to cf that can query the collector state
  - extend the munin-node subordinate to have a plugin interface scoped to
container
  - create a MuninContext cf with an overridden is_ready state
    * have the context provide the data munin will need to find the plugin,
configure it etc
    * add context to service blocks in provide and require for the collector


> Other question is relations with external services like ELK bundle. To
> make them work together you need to run additional command like `juju set
> CustomLogFile=[...]` [1], this is not too much, but it could be done on
> add-relation stage. Is there any way to determine such relation, or
> mediator subordinate charm would be a solution in this case?
>

Yeah, it definitely could. It would require extending the subordinate charm
and services to have such a contract.  Process would be similar to what is
described above, except *every* service would need to provide data on it's
logging (in which case it ought to be general for any sort of agent).
 conversely the subordinate could get that info from the aggregator, in
which case being logstash specific would be fine.

-w

-- 
---------------
D. Whit Morriss
Developer, Juju Ecosystem
Canonical USA