Mailing-List: contact libcloud-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: libcloud@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of ferncam1@gmail.com designates
 209.85.220.212 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=lX8ixfagZZHnU5uKto0dMVEULK0NcIAq2nit7LsUwM+bUrVh5Q6by0FiwWLzH6jHM2
         fnGtuX/3pK5HK2N/r7zsqkBGnKS4h+nqAQRunf/7RVxpucDnOZO1kAm/47PLEEXV5E0m
         iz9efGUiCbECOkb+19JXqUillf3keJziSQZ+o=
MIME-Version: 1.0
In-Reply-To: <4239a4321002282158v325fcfceoe1dd404aa0717bd8@mail.gmail.com>
References: <4239a4321002281715n25fbdc8fn9477b22e52956043@mail.gmail.com>
	 <ac79ea401002281904h787a6507v3fe0d3c05cb67a98@mail.gmail.com>
	 <b654cd2e1002281912t47cb1564kd56728a29959a393@mail.gmail.com>
	 <4239a4321002282137i5e04a78fu25af073d65b73388@mail.gmail.com>
	 <b654cd2e1002282154g1adbe409wbfbfbd8217295b78@mail.gmail.com>
	 <4239a4321002282158v325fcfceoe1dd404aa0717bd8@mail.gmail.com>
Date: Sun, 28 Feb 2010 22:51:21 -0800
Message-ID: <6c6be1ae1002282251m2fd686fcke1bcde1930e42c2f@mail.gmail.com>
From: Adrian Cole <ferncam1@gmail.com>
To: libcloud@incubator.apache.org
Content-Type: multipart/alternative; boundary=00163649918d4f5ea60480b7ad99
Subject: Re: [libcloud] need feedback on deployment API in trunk!

--00163649918d4f5ea60480b7ad99
Content-Type: text/plain; charset=ISO-8859-1

I agree with the implementation as described.  It reflects our cloudhackers
discussion a week or so ago: basically, be able to bootstrap something else
;)

WRT error handling,

+1 Optionally destroy a node who fails to successfully execute bootstrap
commands.
     By default, don't, which implies the user must check to see if the node
state is correct.

Future work could allow custom error handlers to be specified by the user.
For example, one could simply "re-run" the script or whatever.

Anyway, good progress: it looks clean.

-Adrian
founder jclouds/cloudhackers
http://www.meetup.com/cloudhackers-SF

On Sun, Feb 28, 2010 at 9:58 PM, Paul Querna <paul@querna.org> wrote:

> On Sun, Feb 28, 2010 at 9:54 PM, Ian Bicking <ianbicking@gmail.com> wrote:
> > On Sun, Feb 28, 2010 at 11:37 PM, Paul Querna <paul@querna.org> 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.
>

--00163649918d4f5ea60480b7ad99--