Jay, > :( I've brought this up before as well. The term metadata is used > incorrectly to refer to custom key/value attributes of something > instead of referring to data about the data (for instance, the type > and length constraints of a data field).
We could move the cpu_info, xpu_info, and net_info fields off to respective -metadata tables, but that would involve lots of changes to NTT Data's live migration additions with respect to cpu_info. Not sure the USC-ISI team would want to break/own that... I don't think there is much more about a compute node that needs to be added to Instance Types, Compute Nodes, and Instances than cpus, memory, disk, net, accelerators. > Unfortunately, because the OpenStack API uses the actual term > "metadata" in the API, that's what the table was named and that's how > key/value pairs are referred to in the code. > > We have at least three choices here: > > 1) Continue to add fields to the instances table (or compute_nodes > table) for these main attributes like cpu_arch, etc. > 2) Use the custom key/value table (instance_metadata) to store these > attribute names and their values > 3) Do both 1) and 2) > > I would prefer that we use 1) above for fields that are common to all > nodes (and thus can be NOT NULL fields in the database and be properly > indexed. And all other attributes that are not common to all nodes use > the instance_metadata table. > > Thoughts? Agree with 1). Accelerators is the only thing that is somewhat optional, so that column might be sparse. I've been looking for how instance_metadata is being used. Our test deployment has a blank table, but not sure it is currently running. Any recommendation on how to represent the supported values? All I found googling was: https://blueprints.launchpad.net/nova/+spec/extra-data/ >> - Will your capabilities scheduler, constraint scheduler, and/or distributed >> schedulers understand different available hardware resources on compute >> nodes? > > I was assuming they would "understand" different available hardware > resources by querying a database table that housed attributes > pertaining to a single host or a group of hosts (a zone). I see, the goal is to be able to build dynamic REST requests for features based on queries into the metadata service. >> As long as we can inject a "-t cg1.4xlarge" at one end and have that get >> routed to a compute node with GPU hardware on the other end, we're not tied >> to the centralized database implementation. > > I don't see how having the database implementation be centralized or > not affects the above statement. Could you elaborate? Sure, I meant that if the distributed scheduler devolves entirely into posting schedule requests on rabbit-mq and letting each individual compute node be its own zone scheduler, that we still need these shorthand instance type mechanisms to advertise certain configurations both for compatibility with ec2 API and as a marketing tool. Walmart offers 3 kinds of toasters because the cheap one gets you in the door, the expensive one has the most gee-wiz appeal, and the medium one has a profit margin designed to maximize revenue. In this analogy, nodes are toasters :-). >> PS: I sent this to the mailing list a week ago and didn't get a reply, now >> can't even find this in the openstack list archive. Anyone else having >> their posts quietly rejected? > > I saw the original, if you are referring to this one: > > https://lists.launchpad.net/openstack/msg01645.html Nope, that was a different email. Not a big deal. I have 3 accounts and can't keep them straight. Brian _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
