Re: [Fab-user] Libcloud and Fabric integration [Was: Re: [dev] Feature Request: [Compute] Provide a core 'execute' method for Node class]

[Jeff Forcier]

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 <address@hidden> 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 <address@hidden>
> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fab-user
>



-- 
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org