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.ca...@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 < > > cur...@canonical.com > > > > wrote: > > > > > > > On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins > > > > <andrew.wilk...@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@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