The Wednesday 07 May 2014 à 23:05:00 (+0400), John Meinel wrote : > 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.
Thanks for the great explanation. I'll start writing code tomorow and combine your approach with Tim http storage worker idea. Best regards Benoît > > John > =:-> > > > On Wed, May 7, 2014 at 9:23 PM, Benoît Canet <benoit.ca...@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.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 > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
