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 <j...@arbash-meinel.com > > <mailto: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 > > =:-> > > > > > > On Tue, May 6, 2014 at 8:33 AM, John Meinel <j...@arbash-meinel.com > > <mailto: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 <mailto: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 > > <mailto: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 <mailto:Juju@lists.ubuntu.com> > > > > Modify settings or unsubscribe at: > > > > https://lists.ubuntu.com/mailman/listinfo/juju > > > > > > > > -- > > Juju mailing list > > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju > > > > > > > > > > -- > > Juju mailing list > > Juju@lists.ubuntu.com <mailto: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
