[Review Queue] elasticsearch ec2 fix (trusty)
After reviews by Simon and tests by Tim [1] I've just pushed an update to the trusty elasticsearch charm which: * Fixes the firewall configuration so that nodes in the cluster can find each other on ec2 (on ec2 the private-address is a private dns, rather than a private IP expected by ufw) [2] * Enables the firewall to be switched off for easy testing of the admin port [3] -Michael [1] http://reports.vapour.ws/charm-tests/charm-bundle-test-5034-results [2] https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1386664 [3] https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1376396 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [Review Queue] More Trusty Promotions
On Thu, Nov 6, 2014 at 6:03 AM, Charles Butler wrote: > Trusty Promotions > rsyslog-forwarder > gunicorn > dokuwiki > postgresql-psql > joomla > terracotta > > > New icons for services to match jujucharms.com branding: > - hdp-hadoop > - hdp-hive > - hdp-pig > - hdp-tez > - hdp-storm > - hdp-zookeeper > > Bundles were renamed and re-pushed to match jujucharms relaunch branding: > > - hdp-core-batch-processing > - data-analytics-with-sql-like > - data-analytics-with-pig-latin > - realtime-processing-with-storm > - high-performance-batch-processing > I just picked one out at random: https://jujucharms.com/data-analytics-with-pig-latin/1 The README needs updating; still titled with the old name. Cheers, Andrew -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Migrating the python-django charm to Ansible
Hi Patrick,
On Thu, Nov 6, 2014 at 4:22 AM, Patrick Hetu wrote:
> Since the last UDS, I'm trying to make the python-django charm evolve
> to use Ansible for is various tasks instead of using pure Python scripts.
>
> My previous attempt:
>
> lp:~patrick-hetu/charms/precise/python-django/ansible
>
> had some problems so I decided to restart from scratch here (work in
> progress):
>
> lp:~patrick-hetu/charms/precise/python-django/ansible_reboot
>
> Based on the following observations.
>
> Use roles that are not specific to Juju
> ---
>
> If you look at an Ansible role you will probably found a file
> defaults/main.yml or vars/main.yml. For me it was stunning how close
> those are to a charm configuration file.
Specifically, this is not the config.yaml you're talking about, but
the config file which is passed during deployment right? As in,
"myconfig.yaml" in:
juju deploy --config myconfig.yaml mycharm
?
>
> So why not grab this opportunity to use the same file
> (minus the charm name at the top [1]) with both Juju and Ansible
> and make Juju use the same roles that Ansible community are using by
> introducing
> shims in the charm playbook.
This should be possible without needing to re-use the actual file
itself - if I've understood correctly what you mean: any ansible-based
juju charm can reuse any community role for free, by using a shim to
set the roles expected variable names, based on the charm config?
So looking at the examples in your branch, if your charm has a config
option django-settings (and therefore playbook and templates have {{
django_settings }} available via the current helpers), while an
ansible-community django-project role expects a "settings_module"
variable, your example shim.yml does:
set_fact: shim_settings_module="{{ django_settings }}"
and then when you use the role, you pass in the the shim_settings_module:
- role: django-project
tags:
- install
django_settings: "{{ shim_settings_module }}"
But I don't see the need for the shim at all, when you can just pass
the charm config value straight through:
django_settings: "{{ django_settings }}
(or in the general case: django_settings: "{{ whatever_my_charm_config_uses }}")
I'm not sure whether I'm missing something about what you're meaning
(re-using the actual file), or whether you may have missed that all
the config is already available in the playbook/template contexts via
the existing charmhelper ansible support (unlikely, as you've used it
before I think). Let me know what I'm missing.
> [1] Using a configuration file without that charm name at the top
> was working in the past but now doesn't. Maybe this could be
> re-enable without to much negative impact.
That might be worth a juju bug. I assume it's related to the config
file being used generally to store config for multiple services within
your setup, but I don't see any reason why that should mean that if
the config file without the charm (service) name at the top is used
for deploying a single charm, that juju couldn't still accept it as
the config for that service.
>
> Couple the playbook with Juju with a shim
> -
>
> To get the playbook to work with an external role we could use
> a shim file that translate Juju's dynamic configuration
> and relation data to roles variables.
Sounds great to be able to reuse existing external roles, but let me
know what I'm missing about why a shim is needed to do this.
>
> I was thinking using a shim imported in the pre_tasks section of
> the charm's playbook that runs on all tags.
> (see: https://github.com/ansible/ansible/issues/3157)
>
> The shim would do things like:
>
> * Translating Juju variable to role variable
That can be done in the playbook where needed as above.
> * Sanitize variable like: unit_name, relation_name, etc
That *should* be done by the existing charmhelpers (it writes out
/etc/ansible/host_vars/localhost on each hook execution with config,
relations and some other things like unit name, public and private
addresses)
> * Ensure backward compatiblity
>
> Then using tags to dispatch based on the current relation
> to the corresponding roles.
>
> Build role for re-usability
> ---
>
Yes...
> This have the potential to solve the problem of repetition of some
> high level tasks in other charm.
> Like adding ppa,
You can add PPAs with the existing apt_repository module (see the
example there):
http://docs.ansible.com/apt_repository_module.html
> fetching source code, adding ssl certificate,
> configuring backup, etc
>
> A little bit like what charmhelper is doing right now.
Yes! I think making reusable roles for common tasks in juju charms is
really worthwhile [1]. We do have a bunch of public shareable roles
that Simon Davy and I (mainly) are reusing and improving for some
internal services [2]. Please take a look and see if there's things
that could be useful -
[Review Queue] More Trusty Promotions
Trusty Promotions rsyslog-forwarder gunicorn dokuwiki postgresql-psql joomla terracotta New icons for services to match jujucharms.com branding: - hdp-hadoop - hdp-hive - hdp-pig - hdp-tez - hdp-storm - hdp-zookeeper Bundles were renamed and re-pushed to match jujucharms relaunch branding: - hdp-core-batch-processing - data-analytics-with-sql-like - data-analytics-with-pig-latin - realtime-processing-with-storm - high-performance-batch-processing -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[Review Queue] storage (encryption) and nfs (trusty)
I reviewed Chris's addition to the storage charm to add encrypted file-system support. He added tests per Tim's request, which were good, but I had issues running them as we as encountering a few small test breakages in the existing tests. I also reviewed Matt's test additions to get the nfs charm promoted to trusty, but I also ran into a test failure there, as well. [1]: https://launchpad.net/~chris-gondolin/charms/trusty/storage/trunk/+merge/234452 [2]: https://bugs.launchpad.net/charms/+bug/1387460 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[Review Queue] Misc charm cleanup
This morning I reviewed and merged the changes listed below. All of these were minor changes: fixes for tests, typos, and proofing errors. https://code.launchpad.net/~jorge/charms/precise/spip/fix-category/+merge/239378 https://code.launchpad.net/~jorge/charms/precise/couchdb/add-readme/+merge/239386 https://code.launchpad.net/~jorge/charms/precise/mysql/fix-metadata/+merge/239391 https://code.launchpad.net/~jorge/charms/precise/serverdensity/fix-metadata/+merge/239429 https://code.launchpad.net/~jorge/charms/precise/tomcat6/fix-metadata/+merge/239430 https://code.launchpad.net/~jorge/charms/precise/teamspeak3/fix-metadata/+merge/239390 https://code.launchpad.net/~aisrael/charms/precise/musica/charm-proof/+merge/237756 https://code.launchpad.net/~aisrael/charms/precise/nfs/automated-test-fixes/+merge/237590 https://code.launchpad.net/~dannf/charms/trusty/mongodb/typo/+merge/240313 https://code.launchpad.net/~dannf/charms/trusty/mongodb/deploy-test-trusty/+merge/240322 -- Tim -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Migrating the python-django charm to Ansible
Since the last UDS, I'm trying to make the python-django charm evolve to use Ansible for is various tasks instead of using pure Python scripts. My previous attempt: lp:~patrick-hetu/charms/precise/python-django/ansible had some problems so I decided to restart from scratch here (work in progress): lp:~patrick-hetu/charms/precise/python-django/ansible_reboot Based on the following observations. Use roles that are not specific to Juju --- If you look at an Ansible role you will probably found a file defaults/main.yml or vars/main.yml. For me it was stunning how close those are to a charm configuration file. So why not grab this opportunity to use the same file (minus the charm name at the top [1]) with both Juju and Ansible and make Juju use the same roles that Ansible community are using by introducing shims in the charm playbook. [1] Using a configuration file without that charm name at the top was working in the past but now doesn't. Maybe this could be re-enable without to much negative impact. Couple the playbook with Juju with a shim - To get the playbook to work with an external role we could use a shim file that translate Juju's dynamic configuration and relation data to roles variables. I was thinking using a shim imported in the pre_tasks section of the charm's playbook that runs on all tags. (see: https://github.com/ansible/ansible/issues/3157) The shim would do things like: * Translating Juju variable to role variable * Sanitize variable like: unit_name, relation_name, etc * Ensure backward compatiblity Then using tags to dispatch based on the current relation to the corresponding roles. Build role for re-usability --- This have the potential to solve the problem of repetition of some high level tasks in other charm. Like adding ppa, fetching source code, adding ssl certificate, configuring backup, etc A little bit like what charmhelper is doing right now. I might not be clear so don't be afraid to ask clarification. I'm looking forward to receive your feedbacks Patrick -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Unit-get
Hi, I bootstrapped juju stable today on maas stable. When deploying a charm I wrote I noticed unit-get private-address is returning the machine's fqdn. Previously it used to return the ip address (several months ago, can't remember the exact juju/maas versions). Has juju changed behaviour? Or is this not expected, i.e. an issue in my environment? Appreciating your time. Thanks, Sameer-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
