The Wednesday 07 May 2014 à 13:11:14 (-0400), Nate Finch wrote :
> Two things:
> 1.) There's no inheritance in Go (though you can still reuse functionality
> in a number of ways).
> 2.) Juju is open source. There's no reason why the Outscale provider can't
> use the ec2 implementation from an ex
The Wednesday 07 May 2014 à 23:05:00 (+0400), John Meinel wrote :
> We certainly welcome more provider implementations to be part of core.
> We've been working with a couple of other people in doing just that (Joyent
> support was recently contributed by them, and there are a few others being
> wor
We certainly welcome more provider implementations to be part of core.
We've been working with a couple of other people in doing just that (Joyent
support was recently contributed by them, and there are a few others being
worked on today).
Most of the provider implementations we have today are spl
The Wednesday 07 May 2014 à 13:11:14 (-0400), Nate Finch wrote :
> Two things:
> 1.) There's no inheritance in Go (though you can still reuse functionality
> in a number of ways).
> 2.) Juju is open source. There's no reason why the Outscale provider can't
> use the ec2 implementation from an exte
Two things:
1.) There's no inheritance in Go (though you can still reuse functionality
in a number of ways).
2.) Juju is open source. There's no reason why the Outscale provider can't
use the ec2 implementation from an external repo.
Being in core grants the provider code no special benefits othe
The Wednesday 07 May 2014 à 11:05:35 (-0400), Nate Finch wrote :
> There seems to be no compelling reason why we can't distribute more than
> just juju and jujud. However, I don't think there's anything to gain by
> splitting out the providers we already have in core. Adding code that
> enables p
There seems to be no compelling reason why we can't distribute more than
just juju and jujud. However, I don't think there's anything to gain by
splitting out the providers we already have in core. Adding code that
enables pluggable providers seems like a no-brainer to let people provide
their ow
On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins
wrote:
> A bit tangential now, but...
>
> Plugin-style was originally how I thought it would best work, but that
> requires distribution with both jujud *and* the juju CLI. That sounds like a
> nightmare to me. OTOH, having a remote service means you
On Tue, May 6, 2014 at 12:36 PM, John Meinel wrote:
> I'll also note that Tim had some good ideas about how to change the Local
> provider to be more consistent with other providers. (Essentially creating
> a separate process that could implement a "Remote Provider" sort of
> interface.) That cou
The Wednesday 07 May 2014 à 10:38:44 (+1200), Tim Penhey wrote :
> Yeah, unfortunately the remote provider and hence local provider
> improvements that I wanted has been bumped for this cycle. It is
> possible that some work will be done to improve the writing of providers
> but it will be slow an
Yeah, unfortunately the remote provider and hence local provider
improvements that I wanted has been bumped for this cycle. It is
possible that some work will be done to improve the writing of providers
but it will be slow and a non-primary task.
With regard to local storage, yes, this cycle (nex
Yeah, using a command line application to talk to a provider seems like the
best way to go. That's the usual way to make things pluggable in Go, and
fits our use cases quite well. It's definitely something I think we should
do, but I'm not sure it's that high on the priority list right now.
On
I'll also note that Tim had some good ideas about how to change the Local
provider to be more consistent with other providers. (Essentially creating
a separate process that could implement a "Remote Provider" sort of
interface.) That could allow bringing up more 'pluggable' providers that
just talk
There is work being done this cycle to switch from using storage from the
Provider to instead using our own internal storage. I don't know that the
work will be done for another few months, though. I believe Tim Penhey is
going to be leading up that work as part of exposing Resources for charms
to
The Monday 05 May 2014 à 22:36:52 (-0400), Kapil Thangavelu wrote :
> from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix
>
> its a little unclear if outscale implements object storage compatible with
> s3. if so then support in core would probably amount to making the ec2/s3
> ap
its come up before (rpc providers, shell script providers) but it doesn't
quite fit with the upgrade and distribution model in juju-core and go atm.
it is possible to layer on top of manual provider using a client side
plugin to effectively automate machine creation for a given provider, i've
publi
from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix
its a little unclear if outscale implements object storage compatible with
s3. if so then support in core would probably amount to making the ec2/s3
api endpoint url pluggable in the core code, along with userdata support
and clo
Taking the opportunity about this topic, what about making this pluggable,
like providers plugins, not into the core?
Sebas.
2014-05-05 18:44 GMT-03:00 Adam Stokes :
> I'd probably start here:
>
> http://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/provider/
>
> This can give you a
I'd probably start here:
http://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/provider/
This can give you an idea on how the ec2 implementation is done
On Mon, May 5, 2014 at 10:56 AM, Benoît Canet wrote:
>
> Hello,
>
> I am a developper planning to add the support for the Outscale c
19 matches
Mail list logo
