incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Bicking <>
Subject Re: [libcloud] need feedback on deployment API in trunk!
Date Mon, 01 Mar 2010 05:54:01 GMT
On Sun, Feb 28, 2010 at 11:37 PM, Paul Querna <> wrote:

> > I'm a little wary of paramiko, mostly because of the pycrypto
> > requirement, which itself require compiling stuff.  It's not terrible,
> > but it introduces a potential installation problem that I was hoping
> > to avoid (by using pure Python libraries).  OTOH, I'm on the fence
> > about using Fabric for the same reason, and if libcloud uses paramiko
> > then I'd probably not be on the fence and just start using Fabric too
> > ;)  (Currently I'm using ssh calls via subprocess.)
> I am not aware of any pure python SSH clients, other than Twisted
> Conch, which would mean... porting to twisted (and depending on
> twisted!)

Certainly not what I'm asking for ;)  ssh via subprocess works fine on any
Posixy system, but of course is more tricky on Windows.  (try/except around
the paramiko import would work for me though)

> > Does deploy_node do both a create, and then run the deployment?  What
> > kind of error checking does it have?  E.g., if that apt-get fails,
> > what then?  Does Fabric already accomplish the same things with
> > greater depth?
> It both creates the node, and does the initial connection.  It has
> very little error handling right now. I definitely would like to
> improve this though -- this is just a first draft :-)

Upon further thought, and given the use cases for my tool ( -- soon to be renamed Silver Lining once I
finish up the text substitution), I can't really envision using this code as
an underlying layer.  Once the system is setup and ssh is accessible I think
it should be outside libcloud's scope.  At that point you aren't abstracting
the cloud, you are handling concrete systems, and other abstraction layers
(like Puppet, Fabric, etc) are more appropriate.  What *would* be helpful is
getting that initial ssh connection working, or some kind of abstraction
around that.  Right now on Rackspace Cloud I'm using their files extension
to upload authorized_keys, but I'd have to switch things around some to get
the same process working on EC2.  So... abstracting that difference would be
nice.  But after that, eh.

Ian Bicking  |  |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message