Charm configuration in config.yaml allows integer, boolean and string datatypes. Some charms require more complex data structures for their configuration, for example a list of (database_name, user_name, access_type) tuples or charm-helper's install_sources and install_keys lists.
One current work around, used by charm-helpers, is to use the 'string' type and allow the user to embed a fragment of yaml. This works, but requires the yaml fragment to be quoted as a string and does not have basic validation.
Other more common work arounds are comma separated lists, space separated lists, base64 and other arbitrary, inconsistent and ad-hoc methods.
It would be lovely if 'yaml' could be specified as a config item datatype, allowing an arbitrary yaml data structure to be embedded as configuration. This would bring consistency, and reduce bugs in charms custom serialization routines.
Charm configuration in config.yaml allows integer, boolean and string datatypes. Some charms require more complex data structures for their configuration, for example a list of (database_name, user_name, access_type) tuples or charm-helper's install_sources and install_keys lists.
One current work around, used by charm-helpers, is to use the 'string' type and allow the user to embed a fragment of yaml. This works, but requires the yaml fragment to be quoted as a string and does not have basic validation.
Other more common work arounds are comma separated lists, space separated lists, base64 and other arbitrary, inconsistent and ad-hoc methods.
It would be lovely if 'yaml' could be specified as a config item datatype, allowing an arbitrary yaml data structure to be embedded as configuration. This would bring consistency, and reduce bugs in charms custom serialization routines.