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 Tue, May 6, 2014 at 12:36 AM, John Meinel <[email protected]> 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 > =:-> > > > On Tue, May 6, 2014 at 8:33 AM, John Meinel <[email protected]>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 <[email protected]>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 < >>> [email protected]>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 >>> > > [email protected] >>> > > Modify settings or unsubscribe at: >>> > > https://lists.ubuntu.com/mailman/listinfo/juju >>> > > >>> >>> -- >>> Juju mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> >> > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
