<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 25, 2013 at 5:41 PM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo@niemeyer.net" target="_blank">gustavo@niemeyer.net</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 Sat, May 25, 2013 at 4:03 PM, Kapil Thangavelu<br>
<<a href="mailto:kapil.thangavelu@canonical.com">kapil.thangavelu@canonical.com</a>> wrote:<br>
>> I don't see a reason to do that either. If you want something<br>
>> "pre-deployed" within the charm, simply put that thing within the<br>
>> charm.<br>
>><br>
><br>
> Because charms are code and its painful to version binaries and large files<br>
<br>
</div>There's no such restriction about having only code inside charms, and<br>
this isn't the case today already. It's also trivial to have binary<br>
files within VCS (I do that in multiple cases) and anywhere else if<br>
you don't want to put them in the charm.<br>
<div class="im"><br></div></blockquote><div><br></div><div>At some point there's a charm size limit for what you want to push and distribute through the charm store or vcs.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> in vcs. Again this is a current paradigm based on working with the tool,<br>
<br>
</div>Exactly. As you said, that's what IS does today, which means it's<br>
already possible, and in fact I believe it is also trivial. I don't<br>
see a compelling reason to make the core model of building or<br>
deploying charms any more complex than it already is.<br></blockquote><div><br><br></div><div>Its precisely because it breaks the model of distribution and deployment that i'd like to see it either 'blessed' or preferably a better mechanism provided. Charms specifying an image as service constraint provides the underlying feature needed with size impact and is flexible for other use cases as well. The service image constraint specified by the admin facilitate straight forward migration from dev, stage, to prod environments. The complexity boils down to an additional constraint with a user or charm defined value, i think it builds well on what's already available. For charms the constraint value would need to be specified per provider or not run in a  provider with an absent value (unsatisfied constraint).<br>
<br></div><div>cheers,<br></div><div>Kapil<br></div></div></div></div>