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

[Samuel Marks]

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.

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

[David Shrewsbury]

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

[Brian Coca]

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.

----------

Brian Coca

[Matt Davis]

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

[Matt Jude]

nice Thanks Matt ✌

On 01/11/2016, Matt Davis <mda...@ansible.com> wrote:
> 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
>
> On Tuesday, November 1, 2016 at 6:14:55 AM UTC-7, Samuel Marks wrote:
>>
>> 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
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/20450873-fb2b-4151-bf64-92fb8c6bfa08%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


--
*Matt Jude*
*Mobile: *072 6222 089
*Email: *mmj...@gmail.com
*Facebook:* fb.com/mattjude

[Allen Sanabria]

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

> email to ansible-project+unsubscribe@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/20450873-fb2b-4151-bf64-92fb8c6bfa08%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--
*Matt Jude*
*Mobile: *072 6222 089
*Email: *mmj...@gmail.com
*Facebook:* fb.com/mattjude

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAF3j_1WBjaiDtBU_N%3Ds57QAC8sWPWw70oz8-TM9g_EOxfWLnFA%40mail.gmail.com.

[Samuel Marks]

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? :)

> email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/20450873-fb2b-4151-bf64-92fb8c6bfa08%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--
*Matt Jude*
*Mobile: *072 6222 089
*Email: *mmj...@gmail.com
*Facebook:* fb.com/mattjude

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

[Brian Coca]

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.

----------

Brian Coca

[Matt Davis]

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