brunogirin at gmail.com
Mon Feb 4 19:41:48 UTC 2013
On 04/02/13 19:03, Clint Byrum wrote:
> 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")  which is a declarative build system like make
>> using QML to describe the different targets: so in practice CMake with
>> 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:
> I think the idea stalled as I've changed jobs and haven't had much time
> for Juju things.
Yes I remember that discussion but I didn't know where declarative
support had gone to and seeing Kevin's presentation over the weekend, I
thought QML could be a good way to implement the declarative description.
>> 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".
Yes. I wasn't aware of the "stacks" discussions. I am now :-)
More information about the Juju