What would you like to see in the virtual Charm School hangouts?

[Kapil Thangavelu]

On Sat, May 25, 2013 at 5:41 PM, Gustavo Niemeyer <gustavo at niemeyer.net>wrote:

> On Sat, May 25, 2013 at 4:03 PM, Kapil Thangavelu
> <kapil.thangavelu at canonical.com> wrote:
> >> I don't see a reason to do that either. If you want something
> >> "pre-deployed" within the charm, simply put that thing within the
> >> charm.
> >>
> >
> > Because charms are code and its painful to version binaries and large
> files
>
> There's no such restriction about having only code inside charms, and
> this isn't the case today already. It's also trivial to have binary
> files within VCS (I do that in multiple cases) and anywhere else if
> you don't want to put them in the charm.
>
>
At some point there's a charm size limit for what you want to push and
distribute through the charm store or vcs.


> > in vcs. Again this is a current paradigm based on working with the tool,
>
> Exactly. As you said, that's what IS does today, which means it's
> already possible, and in fact I believe it is also trivial. I don't
> see a compelling reason to make the core model of building or
> deploying charms any more complex than it already is.
>


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).

cheers,
Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130525/4ae9a6a4/attachment-0001.html>