cf-charmers team mailing list archive

[Cory Johns <cory.johns@xxxxxxxxxxxxx>]

This is another instance where the data and the behavior need to be
better separated.

I think we should refactor the GraphiteRelation out into two separate
classes: CollectorContext and GraphiteRelation (and MuninRelation,
etc).  Only the CollectorContext would go in required_data and it
would override is_ready() to always return True.  It would then have a
list of optional relations, such as the GraphiteRelation, that it
would iterate and test is_ready() on to determine if that relation is
connected and available, when constructing the erb_mapping.

The place where this falls down, currently, is the generation of the
metadata.yaml for the collector charm, so we'd need to refactor
build_metadata to support it (such as by accepting list values for
name and interface, which could be generated from the list of
supported consumer relations).

On Thu, Nov 20, 2014 at 12:24 PM, Whit Morriss
<whit.morriss@xxxxxxxxxxxxx> wrote:
>
> 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
>
> --
> Mailing list: https://launchpad.net/~cf-charmers
> Post to     : cf-charmers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~cf-charmers
> More help   : https://help.launchpad.net/ListHelp
>