openstack team mailing list archive

[<masumotok@xxxxxxxxxxxxx>]

Hi, let me say something since this topic touches the feature that we contribute.

> -----Original Message-----
> From: openstack-bounces+masumotok=nttdata.co.jp@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+masumotok=nttdata.co.jp@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Brian Schott
> Sent: Thursday, April 14, 2011 7:14 AM
> To: Jay Pipes
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp