Of course. The deployment module should be as is. I tried to relate the way the deployment module is integrated with node driver's deploy_node api, the execution or scripting module shall be integrated with node's run | execute api (what ever be the name is).
Currently the deployment module is designed to make use of available SSH clients like paramiko. I think the same approach shall be used to design a scripting module that depends on engines like fabric. - Jayyy V On Thu, Jan 31, 2013 at 12:19 PM, Jaume Devesa <[email protected]>wrote: > 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 > > > > > >
