Open Stack

On Thu, Apr 30, 2015 at 11:21:26AM +1000, Blair Bethwaite wrote:
> Thanks Daniel,
> 
> I'll fix that, need to try my hand at doc patches.

I've actually sent a patch for that late last night already

   https://review.openstack.org/#/c/178773/


> Whilst I've got your attention, any comment on my aside about it
> seeming odd from userland perspective that these (and similar
> tunables) are controlled through flavor/image extra specs?
> "Does anyone else find it strange that all these options are designed
> to be flavor and/or image extra specs rather than providing a
> mechanism to set them on instance boot (e.g. hints). I think the
> relationship between flavors or images and such tunables is tenuous at
> best, why should I need multiple versions of what is otherwise the
> same image or flavor in order to ask for e.g. CPU pinning or Qemu
> Guest Agent, these are per instance tunables/variables."

Ok, so first of all, NUMA, strict cpu pinning and huge page
configuration policies have a direct impact on compute host
utilization. The cloud admin has to setup host aggregates to
make proper use of dedicated cpu pinning & huge pages, and
these imply no use of over commit. Given that CPU & RAM Is
a finite resource, the cloud admin must retain a way to
prevent users from accessing cpu pinning & huge pages features.

The only mechanism to prevent such usage is to set properties
on the flavour - the flavours are the core access control
mechanism in Nova for resource usage. So the cloud admin can
setup flavours which allow or deny use of these features.
This is what I'd expect to be the usage pattern for public
cloud where permissioning is very important.

To make it more useful for private cloud though, we allow
all the properties to be set at the image level, /provided/
they don't conflict with anything set at the flavour level.
ie the flavour settings always take priority, to prevent
tenants violating cloud admin's controls.

That is how things stand today. There *is* however a more
general goal to enhance the Nova boot API, so that any
image property can also be specified at time you boot the
instance. This will apply not just for NUMA/CPU/hugepags
things, but for absolutely any setting that is currently
valid against the image.

Before we can do that though, Nova people wanted us to
better specify exactly what we support for image properties
To that end I've actually been working on a change to make
a formally defined object listing all known image properties:

  https://review.openstack.org/#/c/76234/28/nova/objects/image_meta_props.py

Once we get this approved, then we can look at the enhancement
for the nova boot API. I'm not going to promise this will happen
in Liberty release cycle, but it /is/ something we want to get
done for Nova.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|