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

[Kapil Thangavelu]

On Sun, May 26, 2013 at 11:02 AM, Mark Canonical Ramm-Christensen <
mark.ramm-christensen at canonical.com> wrote:

> There are multiple inter-related issues that are being discussed here:
>
> * making it easier to write charms in Ruby or PHP when those languages are
> not available in the cloud image by default.
>
> * making it easier to support charms on private clouds that block outgoing
> network access (egress filtering)
>
> * making add-unit work more quickly to handle traffic spikes
>
>
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.
>

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.


>
> 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.
>
> Then we can easily prioritize it up or down, or put it out there with a
> patches accepted label.
>
> Regardless of what we decide, I wholeheartedly agree that discussion will
> only have value if we record the results.
>


Sounds good.

cheers,

Kapil


>
> --Mark Ramm (mobile edition)
>
>
> On Saturday, May 25, 2013, Gustavo Niemeyer wrote:
>
>> On Sat, May 25, 2013 at 7:24 PM, Kapil Thangavelu
>> <kapil.thangavelu at canonical.com> wrote:
>> > At some point there's a charm size limit for what you want to push and
>> > distribute through the charm store or vcs.
>>
>> There is a multitude of ways to store huge files online that doesn't
>> involve making juju more complex. This simply isn't anywhere near a
>> blocker, and it's not even obvious that if/when we do add better
>> support for binaries, this is the shape it should would take.
>>
>> We've just returned from a sprint where we agreed what the actual
>> priorities are. Can we please focus on them?
>>
>>
>> gustavo @ http://niemeyer.net
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130528/6fa2e4de/attachment.html>