Well, maybe the example wasn't the best and it seems I have request some kind of 'new ssh remote execution' feature.
What I mean is to keep the Deployment module as is, but offering the possibility to use it anytime in the Node lifecycle instead of use it only at creation time. However, I didn't know the fabric project, and I'll check it out to see what it offers! Thanks. On 30 January 2013 21:49, Jayy yV <[email protected]> wrote: > +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 > > >
