+1 for the choice of fabric integration and striving to keep the libcloud core api simple as possible.
I think libcloud already has the ground to start with this. We have Deployment module (what we can call it as a tiny-fabric) that integrates paramiko for SSH. And the fabric does the same, it uses paramiko for SSH and has built a robust scripting API's. - Jayyy V On Thu, Jan 31, 2013 at 12:27 AM, Jeff Forcier <[email protected]> wrote: > 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 >
