incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <tom.e.wh...@gmail.com>
Subject Re: [libcloud] 0.3.x goals
Date Sat, 20 Feb 2010 05:45:20 GMT
Sounds like I should pay more attention to jclouds! Thanks for the
pointers Adrian. It would be good to see what jclouds has done in more
detail in this area and perhaps share code or at least ideas.

Cheers,
Tom

On Fri, Feb 19, 2010 at 1:47 PM, Adrian Cole <ferncam1@gmail.com> wrote:
> good ideas, tom.
>
> We should chat about this stuff during this or next cloudhackers.  In the
> mean time, the implementation plan tom laid out is already a part of jclouds
> and is working pretty well.  There's a tool called pallet [1] that uses
> these hooks to run chef and resize node sets.
>
> FWIW, here's the user docs on how this works.  Happy to discuss
> implementation, as well.
> http://code.google.com/p/jclouds/wiki/ComputeGuide#Advanced_Usage
>
> Cheers,
> -Adrian
> [1] http://github.com/hugoduncan/pallet
>
> On Fri, Feb 19, 2010 at 11:22 AM, Tom White <tom.e.white@gmail.com> wrote:
>
>> On Thu, Feb 18, 2010 at 3:36 AM, Upayavira <uv@odoko.co.uk> wrote:
>> > This is all the exact use-case I had for libcloud.
>>
>> Me too. I like Solomon's idea of providing a runurl service on boot.
>> This is easy to do with EC2 as a user data script
>> (http://alestic.com/2009/06/ec2-user-data-scripts). Rackspace too,
>> with its file injection facility at create time.
>>
>> As Paul notes, there are a few obstacles to doing this on all
>> providers. For example, on Terremark you would have to scp a script
>> (using a known password), then run it (using ssh, again using the
>> known password). The script would probably disable the default account
>> as the first thing it did.
>>
>> I imagine this would be an optional feature. If it couldn't be
>> implemented for a provider, it would be a no op.
>>
>> Another feature I would like to see is the ability to assign roles
>> (groups) to instances. You can then perform operations for all
>> instances in a particular role in one go - e.g. terminate all
>> instances in a given role. This wouldn't necessarily be a core feature
>> - it could be an extension module or something. I do this today using
>> security groups in EC2, metadata in Rackspace, and instance-name
>> encoding in Terremark. I find it useful for an instance to know which
>> roles it is in too (so it can configure itself appropriately) so this
>> would probably tie into the boot time information.
>>
>> Cheers,
>> Tom
>>
>>
>>
>> >
>> > Ideally I could use it to fire up a VM, and tell the host how to
>> > configure itself. I have had such code working against ec2, and now
>> > working against Voxel. I've considered Puppet, but one issue is that it
>> > doesn't handle instance creation. Combine Puppet with something like
>> > libcloud and you end up with a powerful combination.
>> >
>> > Note, for the Voxel API you can provide a script as a parameter at
>> > creation time. That script will be executed on the VM once it has been
>> > instantiated.
>> >
>> > Upayavira
>> >
>> > On Thu, 2010-02-11 at 08:51 -0800, Paul Querna wrote:
>> >> On Thu, Feb 11, 2010 at 2:38 AM, Solomon Hykes <solomon.hykes@gmail.com>
>> wrote:
>> >> > On Thu, Feb 11, 2010 at 3:18 AM, Paul Querna <paul@querna.org>
wrote:
>> >> >
>> >> >> I think an interesting API to provide is the minimum needed to
>> >> >> kickstart any of the above deployment systems.
>> >> >
>> >> > I agree entirely. The less abstraction we can get away with, the
>> better.
>> >> >
>> >> >> For example, if we provided a deploy_node() api, which takes a
>> similar
>> >> >> kwargs to create_node [...]
>> >> >
>> >> > Why not simply add kwargs to create_node? See below.
>> >> >
>> >> >> after the node is booted, SSHes in,
>> >> >> installs a few specific things, copies a small number of files
into
>> >> >> the machine, and starts a service.  The actual actions could be
a
>> >> >> class for each of the above configuration management systems, with
>> the
>> >> >> ability to add your own.
>> >> >
>> >> > I like the process. It seems to me the only abstraction we need here
>> >> > is the ability to run commands on the node, with a "runurl" ability
to
>> >> > pull commands from a remote url.
>> >> >
>> >> > The result would look like this:
>> >> > create_node(runurl="http://somewhere.tld/webserver-bootstrap.sh")
>> >>
>> >> Well, not quite, there are a few barriers:
>> >>  - You need to authenticate into the host.  Depending on the provider,
>> >> this is either done by providing a password, an ssh key, or receiving
>> >> a password after booting, or as Ian mentioned, via an existing ssh
>> >> key.
>> >>  - You would need to install runurl, this most likely means either
>> >> just SCPing it up, but you'll still want to use apt or yum or X to
>> >> install curl or wget etc.
>> >
>> >
>> >
>>
>

Mime
View raw message