Open Stack

In re: Different architectures.

I'm not saying we should create architecture specific definitions in our APIs.  I like the idea of capabilities being exposed as arbitrary strings like "AES" or "AltiVec".  An Intel user would be providing an IA architecture image and should know that it makes no sense to request "AltiVec" capabilities (and that request would correctly fail as either the image wouldn't run on the selected host or no host would be selected).

I'm looking for Nova to provide a common way of exposing and requesting host capabilities and you just use appropriate architecture specific strings when using these common interfaces.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Tony Breeds [mailto:tony at bakeyournoodle.com] 
Sent: Sunday, August 9, 2015 8:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] How should we expose host capabilities to the scheduler

On Mon, Aug 03, 2015 at 04:49:59PM +0100, Alexis Lee wrote:
> Dugger, Donald D said on Mon, Aug 03, 2015 at 05:39:49AM +0000:
> > Also note that, although many capabilities can be represented by 
> > simple key/value pairs (e.g. the presence of a specific special
> > instruction) that is not true for all capabilities (e.g. Numa 
> > topology doesn't really fit into this model) and even the need to 
> > specify ranges of values (more that x byes of RAM, less than y 
> > bandwidth
> > utilization) makes things more complex.
> 
> I'm glad you brought up ranges. I don't want to get too exotic 
> prematurely but these certainly seem useful.
> 
> > Without going into the solution space the first thing we need to do 
> > is make sure we know what the requirements are for exposing host 
> > capabilities.  At a minimum we need to:
> > 
> > 1)      Enumerate the capabilities.  This will involve both
> > quantitative values (amount of RAM, amount of disk, ...) and Boolean 
> > (magic instructions present).  Also, there will be static 
> > capabilities that are discovered at boot time and don't change 
> > afterwards and dynamic capabilities that vary during node operation.
> > 
> > 2)      Expose the capabilities to both users and operators.
> 
> As discussed at the midcycle, part of this is presenting a 
> somewhat-uniform API. I was fairly sleepy but I seem to recall PowerVM 
> does not publish an exhaustive list of its capabilities? Do we need a 
> facade which lists implicit capabilities for newer CPUs?
> 
> We might also want to abstract over similar capabilities in Intel and 
> PowerVM?

So just for clarity POWER CPUs do expose this information but it isn't exposed via the CPU flags the way intel does.

A /proc/cpuinfo for a current POWER box looks like:
---
<snip>

processor   : 152
cpu         : POWER8E (raw), altivec supported
clock       : 3690.000000MHz
revision    : 2.1 (pvr 004b 0201)

timebase    : 512000000
platform    : PowerNV
model       : 8247-22L
machine     : PowerNV 8247-22L
firmware    : OPAL v3
---

Between the firmware version and the pvr value you can work out which feature the CPU supports.  Asking for "SSE" clearly only makes sense on intel and mapping that to anything on POWER would be "strange" at best.


IIRC a primary motivator for this is to say this os image has been built with SSE so only boot it on a compute host with that support.  As that's an image feature it dosn't make sense to run that on POWER
 
Yours Tony.