<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 26, 2013 at 11:02 AM, Mark Canonical Ramm-Christensen <span dir="ltr"><<a href="mailto:mark.ramm-christensen@canonical.com" target="_blank">mark.ramm-christensen@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There are multiple inter-related issues that are being discussed here:<div><br></div><div>* making it easier to write charms in Ruby or PHP when those languages are not available in the cloud image by default.</div>
<div><br>
</div><div>* making it easier to support charms on private clouds that block outgoing network access (egress filtering)</div><div><br></div><div>* making add-unit work more quickly to handle traffic spikes</div><div> </div>
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div>
<div>I brought it up in this thread because of the first use case.  We do have to work on item 2 this cycle at least a little bit (but the current plan was to put this into charm tools as a helper which knows how to cache dependencies).  And I think item three might be premature optimization. </div>
</blockquote><div><br>I don't think # 3 is characterized properly. I'd restate as Given murphy's law, a third party network resource will be down or disappeared when adding a unit. If #2 is doing cross-unit caching that's potentially a solution for #3, but my understanding was it was primarily going to be proxy config and egress traffic config.<br>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br></div>So, what's on the table is figuring out if the idea has merit and if it solves case 1 relatively easily, and if it puts us in a better or worse position via items 2 and 3.  <div><br></div><div>Then we can easily prioritize it up or down, or put it out there with a patches accepted label. </div>

<div><br></div><div>Regardless of what we decide, I wholeheartedly agree that discussion will only have value if we record the results. </div></blockquote><div><br><br></div><div>Sounds good.<br><br>cheers,<br><br>Kapil<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div>--Mark R<span></span>amm (mobile edition)</div><div class=""><div class="h5">
<div><br></div>
<div><div><br>On Saturday, May 25, 2013, Gustavo Niemeyer  wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, May 25, 2013 at 7:24 PM, Kapil Thangavelu<br>


<<a>kapil.thangavelu@canonical.com</a>> wrote:<br>
> At some point there's a charm size limit for what you want to push and<br>
> distribute through the charm store or vcs.<br>
<br>
There is a multitude of ways to store huge files online that doesn't<br>
involve making juju more complex. This simply isn't anywhere near a<br>
blocker, and it's not even obvious that if/when we do add better<br>
support for binaries, this is the shape it should would take.<br>
<br>
We've just returned from a sprint where we agreed what the actual<br>
priorities are. Can we please focus on them?<br>
<br>
<br>
gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br>
</blockquote></div></div>
</div></div></blockquote></div><br></div></div>