incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Donaldson <>
Subject Re: [libcloud] adding i386 and x86_64 architecture flags for NodeSize and NodeImage, and utilizing the driver object in NodeSize
Date Mon, 18 Apr 2011 20:54:06 GMT
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

On Mon, Apr 18, 2011 at 3:20 AM, Tomaz Muraus <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message