Questions about the integration of the Outscale cloud provider into juju-core
Nate Finch
nate.finch at canonical.com
Wed May 7 17:11:14 UTC 2014
Two things:
1.) There's no inheritance in Go (though you can still reuse functionality
in a number of ways).
2.) Juju is open source. There's no reason why the Outscale provider can't
use the ec2 implementation from an external repo.
Being in core grants the provider code no special benefits other than
ensuring that the code gets compiled and tested with the rest of the code.
If we start having providers external to core, we'd work more carefully to
keep the provider interface stable, or at least backwards compatible.
On Wed, May 7, 2014 at 1:01 PM, Benoît Canet <benoit.canet at irqsave.net>wrote:
> The Wednesday 07 May 2014 à 11:05:35 (-0400), Nate Finch wrote :
> > There seems to be no compelling reason why we can't distribute more than
> > just juju and jujud. However, I don't think there's anything to gain by
> > splitting out the providers we already have in core. Adding code that
> > enables pluggable providers seems like a no-brainer to let people provide
> > their own interface for their own cloud (whether it's a private cloud or
> > simply one of the public ones we don't yet support).
>
> Would not it be better for the Outscale provider to be in core so it can
> inherit from the EC2 driver and only implement the differences ?
>
> Best regards
>
> Benoît
>
> >
> > Yes, the manual provider sort of works now, but it is so incredibly
> > *manual *that I hesitate to even call it a solution for all but the most
> > limited of use cases.
> >
> >
> > On Wed, May 7, 2014 at 9:20 AM, Curtis Hovey-Canonical <
> curtis at canonical.com
> > > wrote:
> >
> > > On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins
> > > <andrew.wilkins at canonical.com> wrote:
> > > > 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.
> > >
> > > Oh. I think we already have this problem. Windows users cannot
> > > backup, restore or generate metadata because they only have the juju
> > > CLI binary installed.
> > >
> > > OSX users may have the current plugins since juju was built by brew,
> > > but I have not tested they work.
> > >
> > > --
> > > Curtis Hovey
> > > Canonical Cloud Development and Operations
> > > http://launchpad.net/~sinzui
> > >
> > > --
> > > Juju mailing list
> > > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140507/30ba1cd8/attachment.html>
More information about the Juju
mailing list