incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: [libcloud] need feedback on deployment API in trunk!
Date Mon, 01 Mar 2010 05:58:27 GMT
On Sun, Feb 28, 2010 at 9:54 PM, Ian Bicking <> wrote:
> 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.

Yes, exactly, that is my only goal with this API.

Convert various password generated, password assigned, ssh key via
create_node, ssh key via metadata script, or backed in ssh key -> you
install an ssh key of your choice.

Once there, its no longer libcloud's problem imo, and going beyond
just the tools to get a consistent way to get access to the machine is
not something I am interested in doing, so I think we are on the same

View raw message