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 <[email protected]>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. >
