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