Questions about the integration of the Outscale cloud provider into juju-core

Tim Penhey tim.penhey at canonical.com
Tue May 6 22:38:44 UTC 2014


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 (next six months) one of
the main tasks is to remove the need for cloud local storage.  This is
on my list of things, and needs some more thought and breakdown for the
non-charm bits.  We use local storage for a few extra cache points:
bootstrap notification, api end points, tool caching, as well as keeping
the charms.

One thing that you can use to get started, is to do what the local and
manual provider use, which is an http storage worker. Effectively the
bootstrap node acts as a storage provider and is just backed by the
local file system. A big caveat here is that this means it is not highly
available - however it would allow the provider to work, and as we move
the local storage requirements, the provider could change too, just as
we will for the local and manual providers.

Cheers,
Tim

On 07/05/14 05:59, Nate Finch wrote:
> 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 <john at arbash-meinel.com
> <mailto:john at 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
>     =:->
> 
> 
>     On Tue, May 6, 2014 at 8:33 AM, John Meinel <john at arbash-meinel.com
>     <mailto:john at 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.canet at irqsave.net <mailto:benoit.canet at 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.canet at irqsave.net
>             <mailto:benoit.canet at 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 at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>             > > Modify settings or unsubscribe at:
>             > > https://lists.ubuntu.com/mailman/listinfo/juju
>             > >
> 
>             --
>             Juju mailing list
>             Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>             Modify settings or unsubscribe at:
>             https://lists.ubuntu.com/mailman/listinfo/juju
> 
> 
> 
> 
>     --
>     Juju mailing list
>     Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju
> 
> 
> 
> 




More information about the Juju mailing list