Move provider implementations under their related projects.

[John Meinel]

The main issue I see is that Provider is all about interfacing upstream
(maas/ec2/etc) with the Juju abstraction. Which means that "
github.com/lxc/lxd" would end up importing "github.com/juju/juju". Which
from a layering perspective isn't right.

Gomaasapi is a bit unique as we're probably the only consumer. Unless you
actually pushed it all the way into the MaaS upstream, it isn't going to be
actively maintained and stay up-to-date. And since MaaS guys are python
developers, they're unlikely to put the time in maintaining the go bindings
for them, much less the Juju provider using the Go bindings.

I guess my point is, either the upstream guys are actively maintaining the
bindings, in which case they'll do it where the bindings live, or they
aren't. While it might be slightly easier, I'd rather they tracked the go
bindings more than the Provider. It fits more with what they are doing, and
shouldn't have Juju-isms in their code base.

John
=:->


On Fri, Mar 25, 2016 at 1:12 AM, Eric Snow <eric.snow at canonical.com> wrote:

> Perhaps we should move the implementation of some providers over to
> the repos for the projects with which the providers interact (and then
> just import them in providers/all).  Then those providers would be
> more likely to stay up-to-date in the face of changes in the project,
> particularly backward-incompatible ones.  For example:
>
> * provider/maas -> github.com/juju/gomaasapi/maasprovider
> * provider/lxd -> github.com/lxc/lxd/lxdprovider
> * ...
>
> or something like that.  It's not a perfect solution nor a complete
> one, but it should help.
>
> -eric
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160327/f524e733/attachment.html>