canonical-ci-engineering team mailing list archive

[Andy Doan <andy.doan@xxxxxxxxxxxxx>]

I don't know how to articulate this concisely, but I feel like the 
things I keep fighting Juju on must mean I'm missing something.

The ci airlines winds up being several services that are very similar 
from a deployment standpoint. And there's also very little about what we 
are doing that's so unique it shouldn't be generally useful to someone 
else. However, I just hit roadblocks at every step. The easiest way to 
describe my confusion is to describe a problem.

I've been thinking about getting statsd support into our code. Joe's 
data-store problem is actually a bit similar and could almost be a 
subset of this.

A service using statsd needs 2 things:

 1) statsd installed
 2) configuration data. host+port and a namespace

For problem 1 we have a big mess. There's no package for statsd except 
in the cats archive. That archive isn't available out of the box in 
canonistack and isn't available at all outside Canonical. To add to the 
fun its not pip installable on precise.

For problem 2 its a bit annoying to have 3 statsd-* config values in 
every charm we write. ie - your django or restish charm isn't as 
generically useful to people anymore.

So how do we solve this? I've thought through different ideas and 
prototyped a bit and they all seem to really suck.

= Option 1 - do it all in the charm
I don't like this, but it seemed the path of least resistance.

I'd make my charms specific to our needs. Each charm can have these 
optional statsd config options. Not too big a deal, but then it gets 
really annoying copy/pasting the config-changed logic. Plus the install 
logic for txstatsd is becoming a mess. I guess we have to add a 
"extra-ppas" config option to each charm so that they can pull in a PPA 
or cats so that we can install txstatsd.

= 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.

= Option 3 - generic top-level charms specific subordinate charms
Currently we have things like a "django" and a "rabbitmq-worker" charm. 
In those charms I try to set up the code that should run. Maybe each 
service should have a tiny subordinate charm that extracts it code and 
special dependencies. This might be smart in the long run, but you still 
have all the copy/paste mess I described in option 1.

---

It just seems like writing a generally useful charm shouldn't require 
you to know in advance every single relationship and configuration 
setting your user would want.

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.

Which leads me to thinking - I must be doing it wrong. Maybe someone can 
articulate how we should solve the statsd problem as a learning exercise?

-andy

PS: There was once a Java project called AspectJ[1] that did something 
called cross-cutting concerns. I never really used or bought into it, 
but I wonder if juju needs some sort of cross-cutting functionality?

1: http://eclipse.org/aspectj/