On Tue, May 6, 2014 at 12:36 PM, John Meinel <j...@arbash-meinel.com> 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 could allow bringing up more 'pluggable' providers that > just talk the same language as the 'local' one would. > I personally would prefer if we used a command line interface (call this > process with these arguments to start an instance), even if the local one > would use the command line to make RPC/socket calls to another process. (If > you think about it, all of them are just sending requests to some other > long-lived process over a socket, but I'd rather not have to run a full > service for every system we want to interact with.) > John > =:-> > 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 can just point the CLI and jujud at that remote service with nothing to distribute. It does mean having a service, which brings its own set of issues. Of course, the two approaches are not mutually exclusive. As you say, you could easily provide a plugin that talks to a remote service. On Tue, May 6, 2014 at 8:33 AM, John Meinel <j...@arbash-meinel.com> wrote: > >> 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 consume. I'm sure he'd be happy to coordinate with someone who wants to >> work on moving us over to having storage internally. >> >> John >> =:-> >> >> >> On Tue, May 6, 2014 at 8:24 AM, Benoît Canet <benoit.ca...@irqsave.net>wrote: >> >>> 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 >>> > api endpoint url pluggable in the core code, along with userdata >>> support >>> > and cloudinit and compatible os images in outscale cloud. >>> >>> From what I know Outscale implement only EC2 compute: no object storage. >>> How could we work around this ? >>> >>> Best regards >>> >>> Benoît >>> >>> > >>> > cheers, >>> > >>> > Kapil >>> > >>> > >>> > On Mon, May 5, 2014 at 11:56 AM, Benoît Canet < >>> benoit.ca...@irqsave.net>wrote: >>> > >>> > > >>> > > Hello, >>> > > >>> > > I am a developper planning to add the support for the Outscale cloud >>> into >>> > > juju-core. >>> > > >>> > > The Outscale cloud implement most of the EC2 API. >>> > > >>> > > Does the Juju maintainer have some guidance on how the support >>> should be >>> > > written ? >>> > > >>> > > Best regards >>> > > >>> > > Benoît Canet >>> > > Nodalink >>> > > >>> > > -- >>> > > Juju mailing list >>> > > Juju@lists.ubuntu.com >>> > > Modify settings or unsubscribe at: >>> > > https://lists.ubuntu.com/mailman/listinfo/juju >>> > > >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
