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

Wed May 7 19:05:00 UTC 2014

We certainly welcome more provider implementations to be part of core.
We've been working with a couple of other people in doing just that (Joyent
support was recently contributed by them, and there are a few others being
worked on today).

Most of the provider implementations we have today are split into 2 code
bases. 1 provides the basic exposure of a cloud (goamz for EC2, goose for
Openstack, gomaasapi for MaaS), and then the actual Provider implementation
binds our Juju interface into calls to the provider. If Outscale really
does look like EC2, then it could certainly share the goamz library at the
least.

If you want it to be "if you have Juju, you can control an Outscale
environment" then you certainly would want to have the code in core. We
don't yet have a way to have an external provider that looks the same as
everything else. Kapil has done some interesting work in providing a plugin
that looks a lot like the rest, but in the end it does still have to
re-implement some of the commands (so you run 'juju PROVIDER command',
instead of just 'juju command').

As for details on implementation, I would probably look to have another
"provider/outscale" directory that would be the actual implementation of
the bits we need. Where possible, you could pull out shared implementations
from the provider/ec2 implementation, but because of things like not having
s3 storage you'd probably be better off with a fully different provider.

John
=:->

On Wed, May 7, 2014 at 9:23 PM, Benoît Canet <benoit.canet at irqsave.net>wrote:

> 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.
> >
> > 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.
>
> Aside from my fears of bitrot would an external provider be properly
> packaged into Ubuntu ? (I really want the support to be as official as
> possible)
>
> Best regards
>
> Benoît
>
> >
> >
> > 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
> > >
> > >
>
> --
> 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/664d9841/attachment.html>