Best practices for "fat" charms

Kapil Thangavelu kapil.thangavelu at
Tue Apr 1 20:13:17 UTC 2014

just to be clear the https url thing is solvable with the intelligent proxy
thing just a bit more work and  client/library support isn't always great.

On Tue, Apr 1, 2014 at 4:11 PM, Kapil Thangavelu <
kapil.thangavelu at> wrote:

> If your trying to do this in automated fashion, juju supports proxies, and
> possibily with intelligent proxy you could do something a bit more
> automated. else its going to require alot of auditing. you could even skip
> the additional steps of modifying all the charms have the intelligent proxy
> work in offline mode with its cache to serve out the files back when
> deploying in an offline setup. the issue is going to be https url then.
> On Tue, Apr 1, 2014 at 4:05 PM, Matt Bruzek <matthew.bruzek at>wrote:
>> Thanks Jorge,
>> Not sure we want to call them "fat" charms, maybe "enterprise" charms.
>> Here is my approach when making a charm work on the enterprise or limited
>> networks.
>> 1) Find out what hook downloads the packages that we are unable to access
>> (wget, curl, or special ppa repositories).  The enterprise network will
>> block these requests often resulting in a charm hook failing.
>> 2) Download the necessary packages from system that has access.
>> 3) Upload the packages to the locked down system, copying the packages to
>> a directory on the local charm.
>> 4) Edit the local charm hooks to check for the package in the local
>> directory first and if that does not exist, the charm would continue to
>> download the files (using wget, or curl, or custom ppa).
>> I believe we could provide a charm-tools method that does something like
>> this and we could use this in charms to create "enterprise" charms that are
>> able to be used on limited network environments.
>> However this creates an interesting problem that I have not figured out a
>> good way to resolve yet (your feedback requested).
>> If the packages exist within the charm the URL will never be used.  Some
>> charms allow the user to configure the download URL and sha1sum of the
>> package.  Other charms do not allow this level of customization.
>> For charms that have a config option for URL we could change it to also
>> accept a file:// transport and some kind of $CHARM_DIR variable and use
>> http:// or https:// for normal URLs.  But what to do with the charms
>> that do not allow the URLs to be configurable, or the charms that use a
>> custom ppa repository?
>>    - Matthew Bruzek <matthew.bruzek at>
>> On Tue, Apr 1, 2014 at 2:07 PM, Jorge O. Castro <jorge at> wrote:
>>> Hi everyone,
>>> Matt Bruzek and I have been doing some charm testing on a machine that
>>> does not have general access to the internet. So charms that pull from
>>> PPAs, github, etc. do not work.
>>> We've been able to "fatten" the charms by doing things like creating a
>>> /files directory in the charm itself and putting the
>>> package/tarball/jar file in there, and given the networking issues
>>> that we might face in production environments that we should start
>>> thinking about best practices for having charms with payloads instead
>>> of pulling from a network source.
>>> Marco has some ideas on how we can generalize this and he will respond
>>> to this thread.
>>> --
>>> Jorge Castro
>>> Canonical Ltd.
>>> - Automate your Cloud Infrastructure
>>> --
>>> Juju mailing list
>>> Juju at
>>> Modify settings or unsubscribe at:
>> --
>> Juju mailing list
>> Juju at
>> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Juju mailing list