On Sun, Feb 28, 2010 at 9:54 PM, Ian Bicking <[email protected]> wrote: > On Sun, Feb 28, 2010 at 11:37 PM, Paul Querna <[email protected]> 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 ( > http://toppcloud.colorstudy.com -- 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 page.
