About immutable configuration parameters. IMHO it'd make a better user
experience if juju added support for them.
It's understandable that the desire is for juju to be a full 'life-cycle'
management interface for the services it deploys, from deployment to operations
and all the way to termination.
The reality though is that many of the services that juju deploys already have
their 'well established' management/operations interfaces that are 'naturally'
used to manage them after deployment.
The existence of such interfaces, and the fact that some people that interact
with the service might prefer them over juju, will make the task of writing
well-behaved 'config-changed' hooks challenging. For those that are not up to
such a challenge, or don't really see the need to, it makes much more sense to
give them the option of immutable configuration parameters.
IMHO such an option will, at the very least, make it easier for charm users and
consumers to identify if a parameter can be changed or not without having to go
and read the source code (assuming they understand the language!).
Regards,
________________________________
From: Matt Bruzek <matthew.bru...@canonical.com>
To: Juju email list <juju@lists.ubuntu.com>
Sent: Wednesday, August 27, 2014 9:10 AM
Subject: [Review Queue] hpcc charm
During my review
queue time I had the opportunity to review the new hpcc charm. The
hpcc charm deploys an instance of HPCC (High Performance Computing
Cluster) Community Edition that is a Big Data platform alternate to
Hadoop. http://hpccsystems.com/products-and-services/products/community-edition
The charm is
available in the personal name space here:
http://manage.jujucharms.com/~xwang2713/precise/hpcc
First and most
importantly the hpcc charm deploys according to the readme file! I
had to increase the memory constraints on the HP-cloud to 4GB per
machine (juju set-constraints mem=4GB) so all the services had enough
memory to start up. After that I was able to cluster by adding units
of hpcc.
In the end the charm
was unable to pass review because some of the configuration options
were immutable, meaning the values did not change after the charm was
created. When I changed some configuration values, they were not
acted upon by the charm and that breaks the Juju user experience.
When a user changes a configuration value they expect the charm to
act upon those changes.
I bring this up so
future charm authors know to avoid immutable configuration when
creating a charm. There are exceptions to every rule, but immutable
configuration are only in extreme cases of data integrity where there
are no other options. A good way to avoid immutable configuration is
to have the configuration options are processed by the config-changed
hook.
We did not have very
good documentation about immutable configuration so I opened a pull
request against the Juju docs with more detail about this problem.
The change was merged and will show up on the Best Practices page
when the documentation processing completes.
https://juju.ubuntu.com/docs/authors-charm-best-practice.html
- Matt Bruzek <matthew.bru...@canonical.com>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
