The HostFilter stuff is going on in here: https://code.launchpad.net/~sandy-walsh/nova/dist-sched-2a
I see your point about making it easy for the user to request an instance based on a pre-defined type. I don't know how the process would go for determining what goes in the db and what stayed external? Most of the capabilities are ephemeral (coming from compute, network, volume) or static (general zone/host info). There was discussion at the summit about how we can discover which capabilities are available for requesting instances. That's something we need to come up with, but I think the answers already reside in the ZoneManager. Should be easy to create a method to answer that. I don't think it needs to live in the db. Hmm -S ________________________________________ From: Lorin Hochstein [[email protected]] Sent: Friday, May 13, 2011 3:22 PM To: Sandy Walsh Cc: [email protected]; Openstack Subject: Re: dist-scheduler-1 merge On May 13, 2011, at 12:31 PM, Sandy Walsh wrote: > (opening this thread up to the mailing list as it's a good conversation) > > Yes, if you look at HostFilter there is a helper method in all drivers to map > from InstanceType to whatever type of query format the driver expects. The > weights will need a standardized format I suspect. > How does the HostFilter fit in with the ZoneAwareScheduler.filter_hosts method? Naively, I would like to do something like this: class ZoneAwareScheduler(driver.Scheduler): ... def filter_hosts(self, num, specs): driver = host_filter.FlavorFilter() name, cooked = driver.instance_type_to_filter(???) # Need instance_type, have specs instead return driver.filter_hosts(self.zone_manager, cooked) But that doesn't work, because the FlavorFilter expects instance types, and the ZoneAwareScheduler expects specs. > I'm open to suggestions here, but I thought the specs (aka host query) would > be an optional argument on the POST /server command (boot) ... if present it > would do the more advanced scheduler. Otherwise, it would fall back to the > most-common-denominator InstanceType format: ram, disk, bandwidth. > In our use case, we would like to avoid requiring the end-users to send optional arguments when requesting instances. Instead, we'd prefer to create new instance types that have additional specs. From the user's point of view, they're still just specifying an instance type, but now the scheduler is taking additional info into account (e.g., cpu architecture, presence of GPU) if a certain instance type is requested. We will still have to write our own custom scheduler code (unless we use the JSON host filter or use the constraint-based scheduler and specify specs using constraints). > Specs are qualifications of capabilities (ram > 5G, disk > 500G, etc) > > We're hoping to keep capabilities as Key Value pairs since so many users want > so many different things. If there is agreement we could move some > capabilities into the InstanceType table. > Key Value pairs sounds good to me, I was asking more to know about where they will reside. Since instance types are stored in the database (rather than, say, specified in the config file and residing in memory) , will their corresponding specs reside in the database as well? Can we have a separate InstanceTypeSpecs table that has fields like (instance_type_id, key, value) that allows users to specify arbitrary specs associated with site-specific instance types? > PS> Side note: we really need to clean up the parameter lists coming from > nova.compute.api:create() into the schedulers ... it's *args/**kwargs hell > right now. > It would be helpful for the reader less familiar with the code if these interfaces were firmed up a little. :) Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin > ________________________________________ > From: Lorin Hochstein [[email protected]] > Sent: Friday, May 13, 2011 11:50 AM > To: Sandy Walsh > Cc: [email protected]; Rick Harris > Subject: Re: dist-scheduler-1 > > Sandy: > > Cool... > > On the spec* vs. InstanceType topic, I assume that somewhere along the line, > the code will need to do a mapping from instance type to spec. Where are you > thinking of encoding the information about capabilities required for each > instance type? For example, are you planning on adding something like an > InstanceTypeSpecs table that maps types to the capabilities required? > > * Is "spec" short for "specification"? I assume from code context that it > refers to the capabilities that are needed to satisfy a request to run an > instance, but wasn't 100% sure. > > Lorin > -- > Lorin Hochstein, Computer Scientist > USC Information Sciences Institute > 703.812.3710 > http://www.east.isi.edu/~lorin > > On May 13, 2011, at 9:43 AM, Sandy Walsh wrote: > >> I've fixed those things in my branch. Rick will pull before merge-prop'ing. >> >> Thanks again! >> -S >> >> >> ________________________________________ >> From: Sandy Walsh >> Sent: Friday, May 13, 2011 9:33 AM >> To: Lorin Hochstein >> Cc: [email protected]; Rick Harris >> Subject: RE: dist-scheduler-1 >> >> Nice! All correct Lorin. >> >> Rick just added some more tests. We'll fix that up before issuing the merge >> prop today. >> >> The whole spec vs. InstanceType thing is something we're still working >> through. We don't want to bust existing stuff but still need to add the, >> more flexible, query mechanism. That'll all emerge over the next couple of >> branches. >> >> Our next step will be getting HostFilter and Rick's CostScheduler tied in >> (via two parallel merge props) >> >> Great to have your input on this! >> >> -S >> ________________________________________ >> From: Lorin Hochstein [[email protected]] >> Sent: Friday, May 13, 2011 1:12 AM >> To: Sandy Walsh >> Cc: [email protected] >> Subject: dist-scheduler-1 >> >> Sandy: >> >> I've been playing with your dist-scheduler-1 branch, to see if I can use >> what's there to do a quick proof-of-concept of heterogeneous nodes using it. >> (I'm starting off by seeing if I can just get a dead-simple zone scheduler >> working). >> >> I realize it's still in active development, but I wanted to let you know >> about the following issues I saw in the code that didn't have TODO >> associated: >> >> 1.In zone_aware_scheduler.py: >> >> ZoneAwareScheduler.schedule_run_instance takes specs=None as the default, >> but this will barf when it hits the "if 'blob' in specs" in the method >> body. Maybe specs={} instead? >> >> 2. ZoneAwareScheduler.weigh_hosts has the following docstring: >> >> """Derived classes must override this method and return >> a lists of hosts in [(weight, hostname)] format.""" >> >> However, based on other parts of the code, it seems thatthis function should >> return a list of dicts [{'weight': w, 'hostname':h}] instead of a list of >> pairs. >> >> I created a branch at lp:~lorinh/nova/dist-sched-1 that I'm hacking away at. >> >> Lorin >> -- >> Lorin Hochstein, Computer Scientist >> USC Information Sciences Institute >> 703.812.3710 >> http://www.east.isi.edu/~lorin >> > > Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at [email protected], and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
