You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Jeff Forcier <je...@bitprophet.org> on 2013/01/30 19:57:19 UTC
[dev] Re: [Fab-user] Libcloud and Fabric integration [Was: Re: [dev]
Feature Request: [Compute] Provide a core 'execute' method for Node class]
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 <to...@apache.org> 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 <de...@gmail.com>
> 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
> Fab-user@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/fab-user
>
--
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org
Re: [dev] Re: [Fab-user] Libcloud and Fabric integration [Was: Re:
[dev] Feature Request: [Compute] Provide a core 'execute' method for Node class]
Posted by Jaume Devesa <de...@gmail.com>.
Agree. If fabric is finally integrated into libcloud, it seems the most
natural way to do it, IMHO.
On 31 January 2013 09:33, Jayy yV <ja...@gmail.com> wrote:
> 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 <devesa.lists@gmail.com
> >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 <ja...@gmail.com> 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 <je...@bitprophet.org>
> > > 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 <to...@apache.org>
> > 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 <
> > devesa.lists@gmail.com
> > > >
> > > > > 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
> > > > > Fab-user@nongnu.org
> > > > > https://lists.nongnu.org/mailman/listinfo/fab-user
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Jeff Forcier
> > > > Unix sysadmin; Python/Ruby engineer
> > > > http://bitprophet.org
> > > >
> > >
> >
>
Re: [dev] Re: [Fab-user] Libcloud and Fabric integration [Was: Re:
[dev] Feature Request: [Compute] Provide a core 'execute' method for Node class]
Posted by Jayy yV <ja...@gmail.com>.
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 <de...@gmail.com>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 <ja...@gmail.com> 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 <je...@bitprophet.org>
> > 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 <to...@apache.org>
> 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 <
> devesa.lists@gmail.com
> > >
> > > > 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
> > > > Fab-user@nongnu.org
> > > > https://lists.nongnu.org/mailman/listinfo/fab-user
> > > >
> > >
> > >
> > >
> > > --
> > > Jeff Forcier
> > > Unix sysadmin; Python/Ruby engineer
> > > http://bitprophet.org
> > >
> >
>
Re: [dev] Re: [Fab-user] Libcloud and Fabric integration [Was: Re:
[dev] Feature Request: [Compute] Provide a core 'execute' method for Node class]
Posted by Jaume Devesa <de...@gmail.com>.
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 <ja...@gmail.com> 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 <je...@bitprophet.org>
> 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 <to...@apache.org> 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 <devesa.lists@gmail.com
> >
> > > 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
> > > Fab-user@nongnu.org
> > > https://lists.nongnu.org/mailman/listinfo/fab-user
> > >
> >
> >
> >
> > --
> > Jeff Forcier
> > Unix sysadmin; Python/Ruby engineer
> > http://bitprophet.org
> >
>
Re: [dev] Re: [Fab-user] Libcloud and Fabric integration [Was: Re:
[dev] Feature Request: [Compute] Provide a core 'execute' method for Node class]
Posted by Jayy yV <ja...@gmail.com>.
+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 <je...@bitprophet.org> 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 <to...@apache.org> 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 <de...@gmail.com>
> > 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
> > Fab-user@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/fab-user
> >
>
>
>
> --
> Jeff Forcier
> Unix sysadmin; Python/Ruby engineer
> http://bitprophet.org
>