<br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 1:41 PM, Bruno Girin <span dir="ltr"><<a href="mailto:brunogirin@gmail.com" target="_blank">brunogirin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 04/02/13 19:03, Clint Byrum wrote:<br>
> Excerpts from Bruno Girin's message of 2013-02-04 05:14:30 -0800:<br>
>> Hi all,<br>
>><br>
>> At FOSDEM over the weekend, Kevin Krammer presented several uses of QML,<br>
>> including some non-UI ones. In particular, he talked about QBS<br>
>> (pronounced "cubes") [1] which is a declarative build system like make<br>
>> using QML to describe the different targets: so in practice CMake with<br>
>> QML syntax and with QML's ability to bind properties and use JavaScript.<br>
>> Other benefits are that the QML engine already exists and that<br>
>> developers who know QML need very little time to get up to speed.<br>
>><br>
>> Is this something that would make sense in order to implement<br>
>> declarative charm support?<br>
>><br>
> My idea for implementing it was discussed at UDS-R, I thought maybe you<br>
> were even in that discussion:<br>
><br>
> <a href="https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-juju-charmhelper2" target="_blank">https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-juju-charmhelper2</a><br>
><br>
> I think the idea stalled as I've changed jobs and haven't had much time<br>
> for Juju things.<br>
<br>
</div>Yes I remember that discussion but I didn't know where declarative<br>
support had gone to and seeing Kevin's presentation over the weekend, I<br>
thought QML could be a good way to implement the declarative description.<br>
<div class="im"><br>
<br></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
>> Beyond this, I was also wondering if there were any plans to create a<br>
>> client side version of a charm (we could call it an enchantment) that<br>
>> would define what charms to run and how to link them together in order<br>
>> to create an environment, so for example a way to say: in order to bring<br>
>> up my test environment, install wordpress, install mysql, link wordpress<br>
>> to mysql, populate mysql with test data. You can of course do this<br>
>> easily with a simple shell script but making this declarative too would<br>
>> make it easier for complex topologies and would be environment<br>
>> independent so you could use the same "enchantment" file whether you<br>
>> were running the Juju client in Ubuntu, Mac OS-X, Windows (should there<br>
>> ever be one of those!) or as a Jenkins plugin.<br>
> What you're talking about has been discussed quite a bit as "stacks".<br>
<br>
</div>Yes. I wasn't aware of the "stacks" discussions. I am now :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
Bruno<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div><div><br class="Apple-interchange-newline">There's a form of declarative environment creation in jitsu import/export which serializes an enviornment/services/relation/constraints/unit count to a json file. I tend to distinguish it from the stacks discussion as import/export focused (ie. stacks would be part of the export), where as stacks would be first class entities. </div>
<div><br></div><div>cheers,</div><div><br></div><div>Kapil</div><div> </div></div><div><br></div></div><br>