Another "FWIW" from me here, ticket #461 spawned a new (very alpha right now) project called 'patchwork' which is intended to be a bunch of fabric-API-using subroutines solving common use cases. When Fabric 2 comes out this project will essentially be that version's "contrib" (though it's a distinct Python project/download/etc).
* https://github.com/fabric/fabric/issues/461 * https://github.com/fabric/patchwork -Jeff On Wed, Jan 30, 2013 at 10:26 AM, Tomaz Muraus <[email protected]> wrote: > 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. > > > > _______________________________________________ > Fab-user mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/fab-user > -- Jeff Forcier Unix sysadmin; Python/Ruby engineer http://bitprophet.org
