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

[Benoît Canet]

The Wednesday 07 May 2014 à 13:11:14 (-0400), Nate Finch wrote :


> 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.

Hello,

I saw that names of the types defined by the ec2 implementation where not capitalized.
So I conclude that they are not exported.

How can I reuse the most of EC2 bits in the outscale provider ?

Best regards

Benoît

> 
> 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
> >
> >