Hi, let me say something since this topic touches the feature that we contribute.
> -----Original Message----- > From: openstack-bounces+masumotok=nttdata.co...@lists.launchpad.net > [mailto:openstack-bounces+masumotok=nttdata.co...@lists.launchpad.net] > On Behalf Of Brian Schott > Sent: Thursday, April 14, 2011 7:14 AM > To: Jay Pipes > Cc: openstack@lists.launchpad.net > Subject: Re: [Openstack] distributed and heterogeneous schedulers > > 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/ My understanding is that instance metadata table is necessary and should be (k,v) type since many people wants to add various info to instance table, then a column is NULL except for a specific purpose, therefore we need (k,v) type of declaration. On the other hand, compute nodes table doesn’t have so many column so far. So regarding to compute node table, I also agree with 1). When it comes to adding many columns to compute nodes table(including someone has a plan to do it), it may be better to discuss. Then NTTData team willingly contributes to change live migration code followed by upcoming discussion :) > > >> - 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
