[Blueprint servercloud-r-juju-charmhelper2] Charm Helper 2 - Declarative Charming

[Antonio Rosales]

Blueprint changed by Antonio Rosales:

Whiteboard changed:
+ --- User Stories ---
+ 
+ --- Risks ---
+ 
+ --- Test Plans ---
+ 
+ --- Release Note ---
+ 
+ --- Blog Post ---
+ 
+ (Needs spec and work item definition) -[a.rosales; 12-DEC-2012]
+ 
+ --- UDS Discussion ---
+ 
  We've learned a lot since the creation of charm helper. Debian packagers  took 7 iterations before boiling all of debhelper's goodness into a  declarative system. We can learn from them, and get there in our second  iteration.
  Discussion:
  Charm-helper is not easily discoverable, poorly documented, and not as awesome as it could be.
  dannf likes to write makefiles
  sources list
  config settings with meaning
  want common things to go in a declarative charm
  get rid of copied lib files/folder
  Maintain charm-helper seperately from juju, calling it at the top of the hook vs included in juju trunk
  What happens during upgrade-charm or if a pakcage gets removed?
  Juju can't help with leader election across units of a service, but charm-helper could)
  Work:
  - describe how to handle lifecycle changes for packages in charm-helper/packages (also thinkof: upgrade-charm)
  - install packages
  - debconf preseeding too
  - templating and/or building config files with dotd/concat partials (erb_template _and_ cheetah_template helpers)?
  - remote_files
  - deploy from {distro,ppa,upstream?} ?
  - Manage config files (dynamic, static, etc)
  - Sanitize relation settings (potential risk of SQL Ejection, highjacking, terror)
  - Plugin based for easy extension of charm-helper
  - leader election (perhaps somewhere other than charmhelper)
  - private files (SSL certs) ... no clue...
  - Collaborate on files that no charm "owns"

-- 
Charm Helper 2 - Declarative Charming
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-juju-charmhelper2