Declarative Juju

[Clint Byrum]

Excerpts from Bruno Girin's message of 2013-02-04 05:14:30 -0800:
> Hi all,
> 
> At FOSDEM over the weekend, Kevin Krammer presented several uses of QML,
> including some non-UI ones. In particular, he talked about QBS
> (pronounced "cubes") [1] which is a declarative build system like make
> using QML to describe the different targets: so in practice CMake with
> QML syntax and with QML's ability to bind properties and use JavaScript.
> Other benefits are that the QML engine already exists and that
> developers who know QML need very little time to get up to speed.
> 
> Is this something that would make sense in order to implement
> declarative charm support?
> 

My idea for implementing it was discussed at UDS-R, I thought maybe you
were even in that discussion:

https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-juju-charmhelper2

I think the idea stalled as I've changed jobs and haven't had much time
for Juju things.

> Beyond this, I was also wondering if there were any plans to create a
> client side version of a charm (we could call it an enchantment) that
> would define what charms to run and how to link them together in order
> to create an environment, so for example a way to say: in order to bring
> up my test environment, install wordpress, install mysql, link wordpress
> to mysql, populate mysql with test data. You can of course do this
> easily with a simple shell script but making this declarative too would
> make it easier for complex topologies and would be environment
> independent so you could use the same "enchantment" file whether you
> were running the Juju client in Ubuntu, Mac OS-X, Windows (should there
> ever be one of those!) or as a Jenkins plugin.

What you're talking about has been discussed quite a bit as "stacks".