[openstack-dev] [nova] Arbitrary "extra specs" for compute nodes?
jaypipes at gmail.com
Mon Jun 9 17:56:31 UTC 2014
On 06/09/2014 01:38 PM, Joe Cropper wrote:
> On Mon, Jun 9, 2014 at 5:17 AM, Day, Phil <philip.day at hp.com> wrote:
>> Hi Joe,
>> Can you give some examples of what that data would be used for ?
> Sure! For example, in the PowerKVM world, hosts can be dynamically
> configured to run in split-core processor mode. This setting can be
> dynamically changed and it'd be nice to allow the driver to track this
> somehow -- and it probably doesn't warrant its own explicit field in
> compute_node. Likewise, PowerKVM also has a concept of the maximum
> SMT level in which its guests can run (which can also vary dynamically
> based on the split-core setting) and it would also be nice to tie such
> settings to the compute node.
That information is typically stored in the compute_node.cpu_info field.
> Overall, this would give folks writing compute drivers the ability to
> attach the "extra spec" style data to a compute node for a variety of
> purposes -- two simple examples provided above, but there are many
> more. :-)
If it's something that the driver can discover on its own and that the
driver can/should use in determining the capabilities that the
hypervisor offers, then at this point, I believe compute_node.cpu_info
is the place to put that information. It's probably worth renaming the
cpu_info field to just "capabilities" instead, to be more generic and
indicate that it's a place the driver stores discoverable capability
information about the node...
Now, for *user-defined* taxonomies, I'm a big fan of simple string
tagging, as is proposed for the server instance model in this spec:
>> It sounds on the face of it that what you’re looking for is pretty similar
>> to what Extensible Resource Tracker sets out to do
> Thanks for pointing this out. I actually ran across these while I was
> searching the code to see what might already exist in this space.
> Actually, the compute node 'stats' was always a first guess, but these
> are clearly heavily reserved for the resource tracker and wind up
> getting purged/deleted over time since the 'extra specs' I reference
> above aren't necessarily tied to the spawning/deleting of instances.
> In other words, they're not really consumable resources, per-se.
> Unless I'm overlooking a way (perhaps I am) to use this
> extensible-resource-tracker blueprint for arbitrary key-value pairs
> **not** related to instances, I think we need something additional?
> I'd happily create a new blueprint for this as well.
>> From: Joe Cropper [mailto:cropper.joe at gmail.com]
>> Sent: 07 June 2014 07:30
>> To: openstack-dev at lists.openstack.org
>> Subject: [openstack-dev] Arbitrary "extra specs" for compute nodes?
>> Hi Folks,
>> I was wondering if there was any such mechanism in the compute node
>> structure to hold arbitrary key-value pairs, similar to flavors'
>> "extra_specs" concept?
>> It appears there are entries for things like pci_stats, stats and recently
>> added extra_resources -- but these all tend to have more specific usages vs.
>> just arbitrary data that may want to be maintained about the compute node
>> over the course of its lifetime.
>> Unless I'm overlooking an existing construct for this, would this be
>> something that folks would welcome a Juno blueprint for--i.e., adding
>> extra_specs style column with a JSON-formatted string that could be loaded
>> as a dict of key-value pairs?
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev