On Mon, May 26, 2014 at 2:18 PM, Kapil Thangavelu
<email address hidden> wrote:
> fwiw, i've been using your es charm as part of a trusty stack, and wanted
> to relay a few findings. first i'm not sure what the hold up is on pushing
> this forward, the extant elasticsearch in the store is pretty broken for
> non-ec2 and is suboptimal by using config to workaround lack of
> implementation of relations.
Great, thanks for the feedback Kapil.
>
> also i realize its inherited (and complete baggage) but its unclear what
> the distinction is between rest and cluster, they both seem to be identical
> forms of provider side access via http. one of them should get dropped, are
> both actually in use.
As per the comment in the metadata.yaml, they're there only to provide
backwards compat. for the existing charms that relate using those, and
are as far as I can tell, both otherwise unnecessary.
At least, I'm not using them at all in our deployments, instead using
the standard website interface. Do you think we should instead
standardise on 'rest' (maybe more descriptive, but in the end, also
just an address/port).
> also you've added a website / http relation isn't
> conveying port which is a required part of that interface communications.
Yes, I was a bit unsure what to do there, given that by default
elasticsearch uses a *range*, 9200-9300.
Given that juju is deploying instances for each unit, it seems sane to
just use 9200 instead of a range and publish that through the
interface? Let me know if you're OK with that at:
On Mon, May 26, 2014 at 2:18 PM, Kapil Thangavelu
<email address hidden> wrote:
> fwiw, i've been using your es charm as part of a trusty stack, and wanted
> to relay a few findings. first i'm not sure what the hold up is on pushing
> this forward, the extant elasticsearch in the store is pretty broken for
> non-ec2 and is suboptimal by using config to workaround lack of
> implementation of relations.
Great, thanks for the feedback Kapil.
>
> also i realize its inherited (and complete baggage) but its unclear what
> the distinction is between rest and cluster, they both seem to be identical
> forms of provider side access via http. one of them should get dropped, are
> both actually in use.
As per the comment in the metadata.yaml, they're there only to provide
backwards compat. for the existing charms that relate using those, and
are as far as I can tell, both otherwise unnecessary.
At least, I'm not using them at all in our deployments, instead using
the standard website interface. Do you think we should instead
standardise on 'rest' (maybe more descriptive, but in the end, also
just an address/port).
> also you've added a website / http relation isn't
> conveying port which is a required part of that interface communications.
Yes, I was a bit unsure what to do there, given that by default
elasticsearch uses a *range*, 9200-9300.
Given that juju is deploying instances for each unit, it seems sane to
just use 9200 instead of a range and publish that through the
interface? Let me know if you're OK with that at:
https:/ /code.launchpad .net/~michael. nelson/ charms/ precise/ elasticsearch/ add-port- to-iface/ +merge/ 220969
> also missing a charm icon (i'd just grab the one off trunk).
I've added lp:charms/elasticsearch/icon.svg to the above MP.
If you agree with those changes, I'll merge them in.
Thanks Kapil.