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

**URL:** <https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930>\
**Category:** Ansible Project\
**Tags:** azure, aws\
**Created:** [November 1, 2016, 9:45am UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930 "2016-11-01T09:45:48Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Samuel\_Marks](https://avatars.discourse-cdn.com/v4/letter/s/bbe5ce/32.png) [@Samuel\_Marks](https://forum.ansible.com/u/Samuel_Marks)\
**Post date:** [November 1, 2016, 9:45am UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/1 "2016-11-01T09:45:48Z")

</div>

Greetings Ansible! - I like your philosophy, although enjoy reinventing the wheel also 😉 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](https://github.com/ansible/ansible-modules-core/tree/679a0ae5e9bd53aa0fbe37ea833d7074784ffffd/cloud).

I note [you’re aware](https://groups.google.com/d/topic/ansible-project/B6M3qYZ5-Oo) 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

---

<div class="post-metadata">

**Author:** ![David\_Shrewsbury1](https://avatars.discourse-cdn.com/v4/letter/d/7ab992/32.png) [@David\_Shrewsbury1](https://forum.ansible.com/u/David_Shrewsbury1)\
**Post date:** [November 1, 2016, 4:57pm UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/2 "2016-11-01T16:57:02Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [November 1, 2016, 6:48pm UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/3 "2016-11-01T18:48:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\
**Post date:** [November 1, 2016, 6:57pm UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/4 "2016-11-01T18:57:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Matt\_Jude](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@Matt\_Jude](https://forum.ansible.com/u/Matt_Jude)\
**Post date:** [November 1, 2016, 6:58pm UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/5 "2016-11-01T18:58:37Z")

</div>

nice Thanks Matt ✌

---

<div class="post-metadata">

**Author:** ![Allen\_Sanabria1](https://avatars.discourse-cdn.com/v4/letter/a/85e7bf/32.png) [@Allen\_Sanabria1](https://forum.ansible.com/u/Allen_Sanabria1)\
**Post date:** [November 1, 2016, 8:34pm UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/6 "2016-11-01T20:34:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Samuel\_Marks](https://avatars.discourse-cdn.com/v4/letter/s/bbe5ce/32.png) [@Samuel\_Marks](https://forum.ansible.com/u/Samuel_Marks)\
**Post date:** [November 2, 2016, 12:03am UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/7 "2016-11-02T00:03:59Z")

</div>

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? 🙂

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [November 2, 2016, 12:48am UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/8 "2016-11-02T00:48:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\
**Post date:** [November 3, 2016, 3:36pm UTC](https://forum.ansible.com/t/libcloud-supports-50-cloud-providers-fallback-and-use-it/22930/9 "2016-11-03T15:36:02Z")

</div>

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

-Matt
