canonical-ci-engineering team mailing list archive

[Evan Dandrea <evan.dandrea@xxxxxxxxxxxxx>]

So as Chris and Ursula can attest to from yesterday, my cause célèbre
is that we are near the end of the last full week of December, and
then have 2-3 full weeks in January before the sprint. We need to be
focusing our efforts on getting the components implemented and tested
before we spend time on nice to haves.

I love data, but if we're going to invest time in anything like this,
can we please make it Nagios support instead (and Graphite later), and
can we please push it to after we have the components and integration
tests written?

That said, we fortunately have Martin sprinting with us in Bluefin
this week and he made the suggestion that we go with a form of:

> = Option 2 - use a subordinate charm
> write some sort of "statsd" client charm that's subordinate to our services.
> The problem I was seeing was exposing the configuration of the subordinate
> charm to my services. It seemed like I'd need to define some interface like
> "statsd-relation-[joined|changed|removed]" for each charm.

The Ksplice charm
(lp:~canonical-sysadmins/canonical-is-charms/ksplice) would be a good
example here. It has a configuration parameter for the ksplice access
key to use, which it sets in /etc/uptrack/uptrack.conf in
config-changed, and installs the uptrack package in the instal hook.

On config-changed, the subordinate can set data on the relation, which
would then get passed back through the relation with the charm its
subordinate to. So, looking at an example:

The txstatsd-client subordinate has a config.yaml with statsd_host and
statsd_port. It has a metadata.yaml with:

requires:
  statsd-info:
    interface: juju-info
    scope: container

In config-changed, it runs ID=$(relation-ids statsd-info);
relation-set -r$ID statsd-info="{ statsd_host: $host, statsd_port:
$port }"`. The PPA assigner charm then has hooks/statsd-info-changed,
which runs `relation-get statsd-info` and processes that into its own
configuration file.

The nagios charm does something along these lines
(lp:~canonical-losas/canonical-is-charms/nrpe-external-master).

Now, this doesn't deal with the problem that we still need to specify
the subordinate per service. I spoke with James Troup and he said we
do not have a good answer there yet - we need better templating in
juju-deployer. In an ideal world we could specify that all CI
components start with:

- Nagios subordinate
- Statsd client subordinate
- Ksplice
- Landscape client

For now we'll just have to copy and paste around.

> 50% of my charms feel like copy/paste from other charms. ie - you can't just
> import "charm-helpers". Is everyone just doing their own very specific
> thing? Seems like a nightmare for someone like I/S to have to keep up with
> all these copy/paste one-off's rather than a few generally useful things.

If there are patterns, we could factor them out into a library.

We should pull the python-txstatsd dsc from the -cat archive and shove
it in a PPA. It's a public project, so there should be no
sensitivities in doing that.