<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 4:05 PM, Matt Bruzek <span dir="ltr"><<a href="mailto:matthew.bruzek@canonical.com" target="_blank">matthew.bruzek@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Thanks Jorge,<br><br></div><div>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.<br>
</div><br></div>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.<br>
</div>2) Download the necessary packages from system that has access.<br>3) Upload the packages to the locked down system, copying the packages to a directory on the local charm.<br></div><div>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).<br>
<br></div><div>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.<br>
</div><div><br></div><div>However this creates an interesting problem that I have not figured out a good way to resolve yet (your feedback requested). <br><br>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. <br>
<br></div><div class="gmail_extra">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?<br>
<br clear="all"><div><div dir="ltr"> - Matthew Bruzek <<a href="mailto:matthew.bruzek@canonical.com" target="_blank">matthew.bruzek@canonical.com</a>><br></div></div>
<br><br><div class="gmail_quote"><div class="">On Tue, Apr 1, 2014 at 2:07 PM, Jorge O. Castro <span dir="ltr"><<a href="mailto:jorge@ubuntu.com" target="_blank">jorge@ubuntu.com</a>></span> wrote:<br></div><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<br>
Matt Bruzek and I have been doing some charm testing on a machine that<br>
does not have general access to the internet. So charms that pull from<br>
PPAs, github, etc. do not work.<br>
<br>
We've been able to "fatten" the charms by doing things like creating a<br>
/files directory in the charm itself and putting the<br>
package/tarball/jar file in there, and given the networking issues<br>
that we might face in production environments that we should start<br>
thinking about best practices for having charms with payloads instead<br>
of pulling from a network source.<br>
<br>
Marco has some ideas on how we can generalize this and he will respond<br>
to this thread.<br>
<span><font color="#888888"><br>
--<br>
Jorge Castro<br>
Canonical Ltd.<br>
<a href="http://juju.ubuntu.com/" target="_blank">http://juju.ubuntu.com/</a> - Automate your Cloud Infrastructure<br>
<br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</font></span></blockquote></div></div></div><br></div></div>
<br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
<br></blockquote></div><br></div>