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

Gustavo Niemeyer gustavo at niemeyer.net
Sat May 25 18:09:44 UTC 2013


On Sat, May 25, 2013 at 2:30 PM, Kapil Thangavelu
<kapil.thangavelu at canonical.com> wrote:
> On Sat, May 25, 2013 at 12:55 PM, Gustavo Niemeyer <gustavo at niemeyer.net>
> wrote:
>>
>> On Sat, May 25, 2013 at 1:45 PM, Kapil Thangavelu
>> <kapil.thangavelu at canonical.com> wrote:
>> > Build in this context is charm assembly, ie turn network downloads from
>> > deployment runtime activities into pre-deployment activities that flush
>> > out
>> > charm contents.
>>
>> "install" means "do whatever it takes to install the charm". If you
>> want to download content as part of that, sounds fine.
>>
>> > The goal being robust deployment of units minimizing
>> > environment external dependencies.
>>
>> I'm missing the connection between that and splitting a hook.
>
> I'm not sure i would even call it a hook as its pre-deployment (ie sans
> units or a service), but this usage of a build command is quite common
> already in ops deployed charms, ie. no runtime network install dependencies
> that are not under org control or available from the environment
> infrastructure (s3, swift, etc), bundling the dep in the charm as
> pre-deployment step is an easy solution that avoids issues of 3rd party
(...)

That seems to imply something completely different from what Mark R.
described. You're suggesting there would be a build step to create the
charm in the first place.

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.


gustavo @ http://niemeyer.net



More information about the Juju mailing list