Charm Development Tooling

[USER STORIES]

Rodrigo is a new charm writer and needs tools to solve problems other authors have already solved in their charms.

Dora is a seasoned charmer that has common functions she wants to publish and share with other authors

Ricardo has written charms before and wants to know what shared functions are available for charms

Lucy is rewriting several hooks to another language and needs to know what helpers exist in that language

Bruce wants to review what parameters a helper function accepts and what the expected output is

[ASSUMPTIONS]

[RISKS]

- It'll be difficult for some functions to create a comperable cross-language function

[IN SCOPE]

[OUT OF SCOPE]

[USER ACCEPTANCE]

[RELEASE NOTE/BLOG]

[NOTES]
vUDS 1304 Notes: http://pad.ubuntu.com/uds-1305-servercloud-s-juju-charmhelper2
vUDS 1308 Notes: http://pad.ubuntu.com/71pRwCnCCz

--- 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"

---
[notes from cloudsprint 2013-05]
- Wedgewood has “Charm Support” which is used in IS and online services charms
  - Python based library
  - Covers debian packaging
-
  - Command line interface
    - Bash support via argparse
  - Has hook env for handling various hook specific items (nrpe, relation data, etc)
  - Exec.d allows you to pre-seed stuff in to charm prior to deployment to perform “pre-install” tasks
    - Handles items as exec.d/charm-pre-install in various hooks by invoking the matching command
  - “Rudimentary” persistent storage support
  - Charm helpers doesn’t do what they wanted it to. Charm-helpers wasn’t a known until after using charm support.
- OpenStack has “openstack-charm-helpers” which is used by the OpenStack charms for deployment
  - Configuration/relation abstracting for easier python support
  - “Storage” management like charm-support
  - Conditional restart of services, mapping dicts to services to manage restart of services
  - Caching of juju environment data, to speed up hook execution
  - Local file syncs between peers
    - Bi-directional file xfer between peers
  - Didn’t use it because: Primitive, moving too fast, and didn’t achieve anything they needed at the time.
   - Current work: lp:~openstack-charmers/openstack-charm-helpers/ha-helpers

Gary’s Ideas:
 - Python helpers of charm-helpers
  - Three levels of stuff
    - Shelltoolbox
    - Current charm helpers
    - some random lib stuff?
  - utils.py branch/release management
  - backend.py specify repos that a config wants, packages. Does really cool python stuff

TIME TO GET DOWN TO BUSINESS
 - Salt/chef/puppet for potential dropins to research. Configuration management tools and how they solve this
 - Look at openstack for management of shared libraries
 - Python package
   - Sub packages and modules
  - Merge proposals for charms, make libs not txt?

Marco scratch
 machine.py for machine level functionality

Work items:
[marcoceppi] Consolidate existing forks/helper code bases: DONE
Develop repos/organization structure of code base (modularize code): DONE
Define distribution methods: DONE
[marcoceppi] Update charm tools to promote best practices wrt stubbing/libraries WITH TESTS: TODO
[marcoceppi] sync up with james and adam when structuring lp:charm-helpers: DONE
[wedgwood] With help from marcoceppi, bac, adam_g, and james_page get core libraries ready: DONE
[marcoceppi] charm-tools: Do not auto-fill charm description from package in "charm create.": DONE
Shell out language specific commands: DONE