Writting an upgrade hook should be a breath using pakcages..
I'm more interrested to have a working logstash/elastcisearch/kibana
bundle than anything.
If moving to ansible count me out .. let me know if following that route.
On 09/06/2014 17:46, Cory Johns wrote:
> Nicolas,
>
> Thanks for your change submission. I do agree that this is much cleaner. However I see an issue with a user upgrading from revision 28 to this revision: since there is no upgrade-charm logic to handle the change in the location of the service, config, and possibly data files, a user attempting to upgrade this charm could end up in a state of conflict. Unfortunately, I can't give my +1 for this change unless an upgrade-charm hook is added to handle this.
>
> Additionally, I believe there is an Ansible-based charm also being reviewed, which would be another route for cleaning up the elasticsearch charm. Please take a look at the discussion on https://bugs.launchpad.net/charms/+bug/822979 regarding the charm at https://code.launchpad.net/~michael.nelson/charms/precise/elasticsearch/trunk to see if you might prefer to use your efforts to help with that.
>
--
Best Regards,
Nicolas Thomas Sales Engineer - Canonical http://insights.ubuntu.com/?p=889
GPG FPR: D592 4185 F099 9031 6590 6292 492F C740 F03A 7EB9
Writting an upgrade hook should be a breath using pakcages..
I'm more interrested to have a working logstash/ elastcisearch/ kibana
bundle than anything.
If moving to ansible count me out .. let me know if following that route.
On 09/06/2014 17:46, Cory Johns wrote: /bugs.launchpad .net/charms/ +bug/822979 regarding the charm at https:/ /code.launchpad .net/~michael. nelson/ charms/ precise/ elasticsearch/ trunk to see if you might prefer to use your efforts to help with that.
> Nicolas,
>
> Thanks for your change submission. I do agree that this is much cleaner. However I see an issue with a user upgrading from revision 28 to this revision: since there is no upgrade-charm logic to handle the change in the location of the service, config, and possibly data files, a user attempting to upgrade this charm could end up in a state of conflict. Unfortunately, I can't give my +1 for this change unless an upgrade-charm hook is added to handle this.
>
> Additionally, I believe there is an Ansible-based charm also being reviewed, which would be another route for cleaning up the elasticsearch charm. Please take a look at the discussion on https:/
>
-- insights. ubuntu. com/?p= 889
Best Regards,
Nicolas Thomas Sales Engineer - Canonical
http://
GPG FPR: D592 4185 F099 9031 6590 6292 492F C740 F03A 7EB9