We've talked about a type of capabilities API within nova and across
OpenStack for at least a couple of years (earliest formal session I
remember is a session in BCN).
At the PTG in Denver, I think there was general sentiment that rather
than never do anything because we can't come up with the perfect design
that would satisfy all requirements in all projects, we should just do
our own things in the projects, at least as a start, and as long as
things are well-documented, that's good enough rather than do nothing.
Well I'm not sure why but I was thinking about this problem today and
came up with something simple here:
https://review.openstack.org/#/c/538498/
This builds on the change to pass ironic node traits through the
nova-compute resource tracker and push those into placement on the
compute node resource provider resource. These traits can then be tied
to required traits in a flavor and used for scheduling.
The patch takes the existing ComputeDriver.capabilities dict that is on
all compute drivers, and for the supported capabilities, exposes those
as a CUSTOM_COMPUTE_<capability name> trait on the compute node resource
provider. So for example, a compute node backed by a libvirt driver with
qemu<2.10 would have a CUSTOM_COMPUTE_SUPPORTS_MULTIATTACH trait.
We could then add something to the request spec when booting a server
from a mutltiattach volume to say this request requires a compute node
that has that trait. That's one of the gaps we have with multiattach
support today, which is there is no connection between the request for a
multiattach-volume-backed server and the compute host the scheduler
picks to build that server, which could lead to server create failures
(which aren't rescheduled by the way).
Anyway, it's just an idea and I wanted to see what others thought about
this. Doing it would bake a certain behavior into how things are tied to
the placement REST API, and I'm not sure if that's a good thing or not.
It also opens up the question of whether or not these become standard
traits in the os-traits library.
Alternatively I've always thought we could do something simple like add
a "GET /os-hypervisors/{hypervisor_id}/capabilities" API which either
makes an RPC call to the compute to get the driver capabilities, or we
could store the driver capabilities in the compute_nodes table and the
API could pull them from there. Then we could build on that same type of
idea by doing something like "GET /servers/{server_id}/capabilities"
which would take into account the capabilities based on the compute host
that the instance is running on, it's flavor, etc. That's all a bigger
change though, but it's more direct than just passing things through to
placement. I fear it's also something that might never happen because
it'll get bogged down in a design committee.
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
