Comment 33 for bug 822979

On Mon, May 26, 2014 at 6:33 PM, Kapil Thangavelu
<email address hidden> wrote:
> Forgot to say, this i really like the way the ansible charm-helpers stuff
> has come together, this charm looks great. I'm hoping to use it in a charm
> school re how to write ansible charms, it would be nice to toss it into the
> charm-tools ala charm create -t ansible that timS's been working on.

Yes, that would be nice. At the moment I've just got the bootstrap
[1], which could probably be used for the template.

[1] https://github.com/absoludity/charm-bootstrap-ansible

> i'm a bit torn on whether their actually not needed. i've been dealing with
> this in my etcd and influxdb charms, and it does feel more correct to label
> the http traffic per the expected client consumption usage interface rather
> than generically via transport. It makes connecting the pieces in the gui
> much saner, and with systems like es (or those others) the software
> internally routes to the correct location obviating the need for additional
> infrastructure like haproxy that could play (albeit poorly) via the extant
> http interface.
>
> iotw. i'd rather drop the website/http interface for connecting to clients
> (minus ui admin components), and rely on something like 'elasticsearch' for
> a client interface, what i find distasteful in the extant store charm is
> the use of two named relations using the same interface with zero
> distinction creating needless ambiguity for users. unfortunately ic that
> same ambiguity throughout the previous monitoring stack charms, and sad
> they got into the store with such conventions.

So based on those comments, I've removed the 'website' relation and
instead promoted the 'rest' relation as the client interface, so that
it's just the 'cluster' relation that is now creating the ambiguity
(and it's commented). The other option would have been to add an
'elasticsearch' or 'client' relation but then have 3 using the same
interface without distinction.

Let me know if that's not what you want. And btw, dropping the website
interface shouldn't be an issue here as it's not yet in the charm
store.

>
> well the rest name is internal to elasticsearch, i'd be just as happy
> renaming them to 'client' but renaming relation names is quite tricky
> against extant systems.

If you think we should add the 'client' relation now for going
forward, happy to do that, but it'd mean 3 relations doing the same
thing.

> it requires destroying the relation and re-creating
> on upgrade. it would be nice to have something in core that could help here
> though its a bit unclear on what exactly, some form of declarative upgrade
> mapping on relations perhaps.

Right. In our case that's not really an issue... I want to re-deploy
on trusty anyway.

>
> re matt's comment, it would be nice to support simple file inclusion for
> capturing the dependency on this.. local repositories are a fairly advanced
> usage mode in comparison, with much more cognitive overhead. dropping a
> file into a directory on the charm is about as simple as it can get.

Added that too. So if your charm includes a files/elasticsearch.deb,
it'll be installed instead. Here's an example:

http://paste.ubuntu.com/7529684/

-Michael