Comment 2 for bug 1315428

Darryl, thank you!!! Made me really happy when i sow your review, and
feedback :)

   1. Bad practice of default password:
   I can make a random password, and then set it in the config of the
   charm. Thats possible, right?

Abs,
Sebas.

2014-05-15 17:18 GMT-03:00 Darryl Weaver <email address hidden>:

> Hi Sebastian,
>
> Great work on the charm so far.
> I have reviewed the charm and I have a few comments:
>
> I deployed the bash version of the drupal charm and it failed with the nfs
> relation.
> I deployed with the default drupal charm options (except the admin
> password) and deployed an nfs charm on precise.
> I added the relation to nfs and got the error:
> unit-drupal-0: 2014-05-15 14:00:05 INFO juju-log nfs:14: We've got a mount
> unit-drupal-0: 2014-05-15 14:00:06 INFO nfs-relation-changed cat:
> .deploy-branch: No such file or directory
> unit-drupal-0: 2014-05-15 14:00:06 INFO juju-log nfs:14: Git checkout to
> the master branch.
> unit-drupal-0: 2014-05-15 14:00:06 INFO nfs-relation-changed error:
> pathspec 'master' did not match any file(s) known to git.
> unit-drupal-0: 2014-05-15 14:00:06 ERROR juju.worker.uniter uniter.go:486
> hook failed: exit status 1
>
> My config is using the default options, so deploy-source is
> "drupal.org".
>
> I then changed the tuning option to "bare" and related the database and
> the deployment works OK on amazon EC2.
> I was able to log in and configure the drupal site from there.
>
> It is bad practice to set a default password in the charm config options
> as this would result in deployments with a default password set.
>
> The default should be to include no default password and make the user
> supply one and only run site install when a password has been set, or
> generate an admin password on site install and output it to a file on
> the unit so the administrator can collect the password from the unit
> after installation has run (see nagios charm for an example).
>
> Rather than using a tuning-level configuration option it would be better
> if the charm could detect which relations it has and tune itself
> automatically based on the available relationships, i.e. go from bare to
> single when the nfs relation is joined and to optimised when both the
> caching relation is available and the nfs relation is available. This
> would remove the need for the option.
>
> More details in the readme for deploying an existing site from a git
> repository would be a good addition too, perhaps an example would be
> helpful.
>
> Otherwise, excellent work and I look forward to seeing the next
> iteration.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1315428
>
> Title:
> Review needed: Drupal Charm
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charms/+bug/1315428/+subscriptions
>