Mailing-List: contact libcloud-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: libcloud@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <BANLkTik0fN08BKqpf8U4JCS6XX95X0Ou4w@mail.gmail.com>
References: <BANLkTimX+vrSfneHggSMDb9i2B0tePABJw@mail.gmail.com>
	<BANLkTik0fN08BKqpf8U4JCS6XX95X0Ou4w@mail.gmail.com>
Date: Mon, 18 Apr 2011 13:54:06 -0700
Message-ID: <BANLkTinVZ6ts9x1Fs7y1BqGSyGvPOqbQZg@mail.gmail.com>
From: Justin Donaldson <donaldson@bigml.com>
To: Tomaz Muraus <tomaz@cloudkick.com>
Cc: libcloud@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e6d624f8a597b604a13797bf
Subject: Re: [libcloud] adding i386 and x86_64 architecture flags for NodeSize
 and NodeImage, and utilizing the driver object in NodeSize

--0016e6d624f8a597b604a13797bf
Content-Type: text/plain; charset=ISO-8859-1

The image problem is difficult, I see.  My thought would be just to mark
images as None if it's not possible to detect from a provider field.  My
workflow generally consists of sticking to ubuntu 10.04 for the base image,
and I don't mind sorting out the official image/architecture on a
per-provider basis.  I just want to make sure I can get a consistent node
kernel, for apt-get (sudo aptitude install ia32-libs).

Node/kernel sizes should be able to be determined without a huge amount of
effort... AFAIK most providers offer 64 bit kernels by default, and then
offer 32-bit userland by default (brightbox, for example).  Amazon is a bit
weird in that sense since they offer 32-bit kernels.  Anybody know of anyone
else offering 32-bit?

The key point is that 64-bit kernels should be able to load anything
(64-bit, 32-bit, or None/unknown), whereas 32-bit kernels would need an
explicit 32 bit image.  If you can just nail down the node size
architecture, it's still useful.

Another thought re: specifying node sizes...
Many other providers have a granular ability to specify memory, cpu "size",
and disk size independently.

My thought would be, rather than retrieving a consistent global list of
generic nodes, there should be some ability to query for matching nodes
per-provider.  E.g. instead of the list_nodes() function, a function such
as: query_sizes(min_cpu, min_disk, max_price, etc...) could be specified.
For providers that have static node sizes, the global list is filtered based
on the parameters provided.  For providers that have granular specification,
a list containing a single node is returned.  The single node is tuned to
the query requirements as closely as possible.

Thanks again to the libcloud team, I really appreciate the organizational
efforts behind this project
-Justin

On Mon, Apr 18, 2011 at 3:20 AM, Tomaz Muraus <tomaz@cloudkick.com> wrote:

> In general I am OK with adding "architecture" attribute to the NodeSize and
> NodeImage class.
>
> Before adding it, we would need to research how many providers actually
> expose this attributes through their API.
>
> I know that many providers don't explicitly include architecture attribute
> in the "list images" response so to figure out the actual image architecture
> we would need to parse it from the image name which is less than ideal.
>
>
>
>

-- 
Justin Donaldson, BigML, Inc.
o: 313-31BIGML | c: 919-BUZZJJD

--0016e6d624f8a597b604a13797bf--