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

[Mark Canonical Ramm-Christensen]

I *think* Kapil and I are on the same page.   Perhaps build is the wrong
term, and perhaps this is not a good idea or a good solution to the problem
-- but it was discussed last week (and a couple of times before) and I
think it would be good to get at least the three of us together next week
sometime on a google hangout to get clear on the details of what is being
discussed, and then on both the viability of the idea, and it's relative
priority.

If anybody else wants in on the meeting, let me know before Monday, and
I'll setup a meeting and get you on the invite list.

-- Mark Ramm


On Sat, May 25, 2013 at 2:03 PM, Kapil Thangavelu <
kapil.thangavelu at canonical.com> wrote:

>
>
>
> On Sat, May 25, 2013 at 2:09 PM, Gustavo Niemeyer <gustavo at niemeyer.net>wrote:
>
>> 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.
>>
>
> That's the current practice for the 'build' command and what i had thought
> was part of the discussion that mark r. was alluding to.
>
> 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 in vcs. Again this is a current paradigm based on working with the
> tool, modifying the tool, charm specifying their image achieves the same
> effect while preserving charm distribution.
>
> cheers,
>
> Kapil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130525/55560eda/attachment.html>