On Tue, May 27, 2014 at 10:45 AM, Michael Nelson <email address hidden>
wrote:

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

The big thing i want todo is drop the ambiguity,  ie no redundancy on
client interface names ('cluster', 'rest', 'website', 'client').. ideally
we'd just have a single simple name 'client'... 'rest' is fine.

It simplifies the documentation and is compatible with extant charms, just
that they need to add/remove relation if they upgrade (to a new charm of a
different series which seems like a good time for us to fix the bad
practices).


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

per above, i'd say drop the others. we can do doc fixes in kibana/indexer
to remove using relation names.


>
> > 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/


thanks,

Kapil


>
>
> -Michael
>
> --
> You received this bug notification because you are a member of charmers,
> which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/822979
>
> Title:
>   Charm needed: Elastic Search
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charms/+bug/822979/+subscriptions
>