Questions about the integration of the Outscale cloud provider into juju-core
Benoît Canet
benoit.canet at irqsave.net
Tue May 6 22:56:52 UTC 2014
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 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.
Would this be mergeable ?
Do you have code urls talking about the http storage worker (both server
and client) ?
Best regards
Benoît
>
> 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
> >
> >
> >
> >
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
More information about the Juju
mailing list