fab-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fab-user] Libcloud and Fabric integration [Was: Re: [dev] Feature Reque


From: Tomaz Muraus
Subject: [Fab-user] Libcloud and Fabric integration [Was: Re: [dev] Feature Request: [Compute] Provide a core 'execute' method for Node class]
Date: Wed, 30 Jan 2013 10:26:18 -0800

I just want to add that I've spent quite a lot of time thinking about adding some kind of similar functionality to Libcloud in the past.

In the end I decided it's probably better to keep this functionality outside of Libcloud and delegate it to a library which primary goal is to do deal with remote and local command execution.

One of the examples of such library is Fabric - one of it's primary goals is remote and local command execution. Imo, instead of duplicating this functionality and building it into Libcloud we should look at ways we can integrate with Fabric and other similar libraries.

I think this has multiple advantages:

- We don't need to reinvent the wheel and maintain potentially a lot of new code

- We can focus our resources on solving our main problem and do we are really good / experienced at (building good APIs and drivers for different cloud services)

- In general I'm a fan of small, single purpose, well defined libraries and programs which you can chain together if you want to achieve a bigger or more complex task (similar to the Unix tool philosophy).

I think small single purpose libraries have many advantages and one of them is forcing developers to write and expose better interfaces / APIs for interfacing with the library. If you have all the functionality in the core you can be lazy and get away with bad abstractions more easily...

I do know that Libcloud already provides some of the remote command execution functionality, but this doesn't necessary mean we need to go down the rabbit hole and built something like Fabric into the Libcloud core :)

If we decided to do it, here are some goals I think we should follow:

- Only use Fabric (or other similar library) public API

- It could potentially and probably should be a separate package - e.g. libcloud-fabric-utils or something

On a related note, for the task you've mentioned you are probably better of with a configuration management tool such as Chef, Puppet or SaltStack if you are looking for a pure Python solution. Salt Cloud SaltStack addon (or whatever the project is called) also offers some basic integration with Libcloud.

P.S. I've also sent this email to the fabric mailing list. I'm also interested in hearing their opinions and ideas on how we could integrate.

On Tue, Jan 29, 2013 at 11:59 PM, Jaume Devesa <address@hidden> wrote:
Hi all,

I send this email cause I would like to discuss a feature request with all
of you.

Current Node's method 'deploy_node' is a powerful feature. I love to have
the ability to create a new node and execute some initial scripts there
like a simple approach of automating tools such as Chef or Puppet, offered
as a core libcloud functionality.

However, I think it is a pity to only have the ability to send remote
commands to my Virtual Machines in creation time. Imagine I have 50
machines in my production environment and a new ssl security flaw has been
discovered. So I have to update all my systems to new *libssl* version. It
would be great to do something more or less like this:

sd = 'apt-get install --only-upgrade libssl'
for node in connection.list_nodes():
    node.execute(sd)

Watching the 'deploy_node' code, I think it would be plausible to offer
this 'execute' feature as a core functionality of the Node class. Maybe it
is as easy as move the logic of 'deploy_node' to the new 'execute' function
(I am sure it is not that simple, but it seems to me that it wouldn't be
hard). This way, the deploy_node would be == create_node + execute.

What do you think?

Regards.

PD: don't trust in my when I have to name methods/classes! The 'execute'
name is just the first name that came to my head.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]