<div dir="ltr">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).<div>
<br></div><div>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.</div>
<div><br></div><div>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'). </div>
<div><br></div><div>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.</div>
<div><br></div><div>John</div><div>=:-></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 7, 2014 at 9:23 PM, Benoît Canet <span dir="ltr"><<a href="mailto:benoit.canet@irqsave.net" target="_blank">benoit.canet@irqsave.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The Wednesday 07 May 2014 à 13:11:14 (-0400), Nate Finch wrote :<br>
<div class="">> Two things:<br>
> 1.) There's no inheritance in Go (though you can still reuse functionality<br>
> in a number of ways).<br>
> 2.) Juju is open source.  There's no reason why the Outscale provider can't<br>
> use the ec2 implementation from an external repo.<br>
><br>
> Being in core grants the provider code no special benefits other than<br>
> ensuring that the code gets compiled and tested with the rest of the code.<br>
>  If we start having providers external to core, we'd work more carefully to<br>
> keep the provider interface stable, or at least backwards compatible.<br>
<br>
</div>Aside from my fears of bitrot would an external provider be properly<br>
packaged into Ubuntu ? (I really want the support to be as official as possible)<br>
<br>
Best regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Benoît<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Wed, May 7, 2014 at 1:01 PM, Benoît Canet <<a href="mailto:benoit.canet@irqsave.net">benoit.canet@irqsave.net</a>>wrote:<br>
><br>
> > The Wednesday 07 May 2014 à 11:05:35 (-0400), Nate Finch wrote :<br>
> > > There seems to be no compelling reason why we can't distribute more than<br>
> > > just juju and jujud.  However, I don't think there's anything to gain by<br>
> > > splitting out the providers we already have in core.  Adding code that<br>
> > > enables pluggable providers seems like a no-brainer to let people provide<br>
> > > their own interface for their own cloud (whether it's a private cloud or<br>
> > > simply one of the public ones we don't yet support).<br>
> ><br>
> > Would not it be better for the Outscale provider to be in core so it can<br>
> > inherit from the EC2 driver and only implement the differences ?<br>
> ><br>
> > Best regards<br>
> ><br>
> > Benoît<br>
> ><br>
> > ><br>
> > > Yes, the manual provider sort of works now, but it is so incredibly<br>
> > > *manual *that I hesitate to even call it a solution for all but the most<br>
> > > limited of use cases.<br>
> > ><br>
> > ><br>
> > > On Wed, May 7, 2014 at 9:20 AM, Curtis Hovey-Canonical <<br>
> > <a href="mailto:curtis@canonical.com">curtis@canonical.com</a><br>
> > > > wrote:<br>
> > ><br>
> > > > On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins<br>
> > > > <<a href="mailto:andrew.wilkins@canonical.com">andrew.wilkins@canonical.com</a>> wrote:<br>
> > > > > A bit tangential now, but...<br>
> > > > ><br>
> > > > > Plugin-style was originally how I thought it would best work, but<br>
> > that<br>
> > > > > requires distribution with both jujud *and* the juju CLI. That sounds<br>
> > > > like a<br>
> > > > > nightmare to me. OTOH, having a remote service means you can just<br>
> > point<br>
> > > > the<br>
> > > > > CLI and jujud at that remote service with nothing to distribute. It<br>
> > does<br>
> > > > > mean having a service, which brings its own set of issues.<br>
> > > > ><br>
> > > > > Of course, the two approaches are not mutually exclusive. As you<br>
> > say, you<br>
> > > > > could easily provide a plugin that talks to a remote service.<br>
> > > ><br>
> > > > Oh.  I think we already have this problem. Windows users cannot<br>
> > > > backup, restore or generate metadata because they only have the juju<br>
> > > > CLI binary installed.<br>
> > > ><br>
> > > > OSX users may have the current plugins since juju was built by brew,<br>
> > > > but I have not tested they work.<br>
> > > ><br>
> > > > --<br>
> > > > Curtis Hovey<br>
> > > > Canonical Cloud Development and Operations<br>
> > > > <a href="http://launchpad.net/~sinzui" target="_blank">http://launchpad.net/~sinzui</a><br>
> > > ><br>
> > > > --<br>
> > > > Juju mailing list<br>
> > > > <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
> > > > Modify settings or unsubscribe at:<br>
> > > > <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
> > > ><br>
> ><br>
> > > --<br>
> > > Juju mailing list<br>
> > > <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
> > > Modify settings or unsubscribe at:<br>
> > <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
> ><br>
> ><br>
<br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</div></div></blockquote></div><br></div>