Libcloud supports >50 cloud providers… fallback and use it?

Archives Ansible Project
,
1

Greetings Ansible! - I like your philosophy, although enjoy reinventing the wheel also :wink: as you can see from my [open-source] Fabric-centric DSL.

However I don’t like being one of [the only?] that supports so many clouds. So I’m thinking about contributing to Ansible, but don’t know if you’d be interested.

FYI: Apache Libcloud is an open-source Python library supporting over 50 different cloud providers. Ansible lists 9.

I note you’re aware of it, even utilising it in your Google Compute Engine (GCE) Ansible cloud module.

Without touching your existing cloud modules, if I prepared a PR that took a catch-all fallback approach would you be interested in accepting?

  • So if it’s not AWS, GCE, Azure, Digital Ocean, Docker, linode, OpenStack, Rackspace or vSphere; then check libcloud.

If yes, then I should get some time over Christmas to make the contribution

2

I don’t know about the other clouds, but as far as OpenStack is concerned, the shade library
exists to handle all of the various differences between OpenStack providers (it turns out to be
pretty complex in spots). This is not something libcloud handles. As one of the maintainers
of those modules, I don’t think incorporating libcloud into the OpenStack modules makes
sense at this time.

-Dave

3

Hi Samuel,

I’m not sure what you mean by fallback, but I guess it also depends on how this is implemented.

We would have to look at each cloud and see what the feature gap and if the maintainers are willing to deal with extra complexity.

As for Openstack, one of the maintainers has already responded.

4

By “fallback” I assume you basically mean just a generic libcloud module? My personal experience with the “provider agnostic” aspects of libcloud has not been great, and our current usage of it in the GCE modules is about to go away in favor of Google’s Python API…

That said, if you’re willing to maintain one or more provider-generic libcloud modules that are decently written and can be shown to do useful things with clouds we don’t currently support, I’m sure we’d take them into extras.

-Matt

5

nice Thanks Matt :v:

6

For AWS, all new modules will be written with Boto3 as Boto3 supports all the latest services that AWS produces.

7

Ah maybe I wasn’t clear, the idea is to have libcloud as a fallback for all providers not currently supported by Ansible.

So if it’s not AWS, GCE, Azure, Digital Ocean, Docker, linode, OpenStack, Rackspace or vSphere; then check libcloud.

Matt: Hmm well the idea is to have one ansible/ansible-modules-core/cloud/libcloud folder, and I’ll change your logic elsewhere which tries to import from that ansible-modules-core/cloud module, that on ImportError it’ll check libcloud.compute.providers and import || raise ImportError accordingly.

That’s what I mean by fallback.

Interested? :slight_smile:

8

The modules should not try to import from each other, since they can execute on different machines than the one in which Ansible is installed.

9

If I understand you correctly, I think that would cause a lot of problems and trip-hazards for maintaining the existing cloud modules. Also, to expand on what bcoca said- you can’t assume you’re always running from the control host. Most people run the cloud modules under localhost / local_action, but there’s nothing precluding you from running them on other hosts (and there are sometimes legitimate reasons to do so). The ansiballz module packager will almost certainly not do the right thing in the fallback case you’re describing (again, assuming I understand what you’re doing). Plus, I don’t see how you could do it without touching the import logic in all the existing modules and running extra round-trips to the module exec host.

I don’t think it’s as simple as you make it out to be, and I suspect there are a lot of gotchas that would keep us from shipping it as a feature. That said, nothing stopping you if you want to take a stab at it. :slight_smile:

-Matt