You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Tomaz Muraus <to...@apache.org> on 2013/01/30 19:26:18 UTC
[dev] Libcloud and Fabric integration [Was: Re: [dev] Feature Request:
[Compute] Provide a core 'execute' method for Node class]
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.
>
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
>
[dev] Re: [Fab-user] Libcloud and Fabric integration [Was: Re: [dev]
Feature Request: [Compute] Provide a core 'execute' method for Node class]
Posted by Jeff Forcier <je...@bitprophet.org>.
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