15:04:27 <n0ano> #startmeeting scheduler
15:04:28 <openstack> Meeting started Tue Apr 30 15:04:27 2013 UTC.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:32 <openstack> The meeting name has been set to 'scheduler'
15:04:46 <n0ano> once more with feeling, show of hands for the scheduler meeting
15:04:47 <n0ano> o/
15:04:54 <rerngvit> i am here
15:05:03 <rerngvit> :)
15:05:08 <garyk> i am here for the scheduling
15:05:34 <rnirmal> I'm new.. wasn't there at the summit but interested in a few topics of scheduler discussions
15:05:41 <glikson> hi
15:05:48 <winston-d> hi
15:05:53 <n0ano> rnirmal, no problem, all are welcome
15:06:01 <rerngvit> the same here, I  am also new.
15:06:08 <winston-d> n0ano: this is zhiteng
15:06:24 <n0ano> winston-d, hi
15:06:37 <winston-d> n0ano: hi Don
15:06:58 <senhuan> Hi guys
15:06:59 <jgallard> hi
15:07:04 <garyk> senhuan: hi
15:07:13 <n0ano> #topic administrivia
15:07:20 <senhuan> Garyk: hi
15:07:43 <glikson> senhuan: hi
15:07:45 <n0ano> Just a little administrivia to start, this is currently scheduled for a weekly meeting, I think we've got enough topics for that now
15:08:10 <n0ano> As things go on, with any luck, we can go to a less frequent schedule
15:08:39 <HenryG> I'm just going to lurk, but I am interested in learning how we might some day take into account "available network bandwidth" when scheduling.
15:08:40 <glikson> ..or more frequent :-)
15:08:57 <n0ano> I've created an agenda based upon the issues from the Havanna summit, feel free to make more suggestions on other items
15:09:13 <n0ano> glikson, good thing you had a smiley on that :-)
15:09:20 <garyk> HenryG: hopefully if and when we get quantum to provide the network proximity we can have the scheduler consume that...
15:09:34 <glikson> n0ano: can you remind where the agenda is?
15:09:57 <n0ano> glikson, I sent out an email to the dev mailing list, I'll try and get better and add it to the wiki page
15:10:01 <garyk> https://wiki.openstack.org/wiki/Meetings/Scheduler
15:10:14 <garyk> n0ano: ^
15:10:28 <rerngvit> http://lists.openstack.org/pipermail/openstack-dev/2013-April/008242.html
15:10:30 <Senhua> Garyk: i have an even wilder idea. Scheduler should be able to use information provided by other parties
15:10:43 <n0ano> garyk, there is the issue of where to get the network data, quantum or ceilometer so this becomes a much wider issue
15:10:46 <rerngvit> 1)  Extending data in host state
15:10:46 <rerngvit> 2)  Utilization based scheduling
15:10:48 <rerngvit> 3)  Whole host allocation capability
15:10:48 <n0ano> Senhua, +1
15:10:49 <rerngvit> 4)  Coexistence of different schedulers
15:10:51 <rerngvit> 5)  Rack aware scheduling
15:10:52 <rerngvit> 6)  List scheduler hints via API
15:10:53 <rerngvit> 7)  Host directory service
15:10:54 <rerngvit> 8)  The future of the scheduler
15:11:10 <glikson> ok, the wiki is empty. np.
15:11:30 <n0ano> glikson, startup issues, I intend to expand it
15:11:41 <garyk> rerngvit: n0ano: ensembles/vclusters is missing from the list
15:12:10 <n0ano> we're not going to get to everything today so adding that on is fine
15:12:25 <n0ano> in fact, why don't we discuss future agenda items a bit
15:12:33 <n0ano> #topic agenda items
15:12:43 <n0ano> So far we need to add:
15:12:59 <glikson> are we going through the items in any particular order? e.g., those for which we already have blueprints, or vice versa?
15:13:05 <n0ano> 1) network bandwidth aware scheduling (and wider aspects)
15:13:14 <n0ano> 2) ensembles/vclusters
15:13:42 <n0ano> glikson, after we come up with issues I'd like to start in the current order
15:14:00 <n0ano> e.g. the issues from the summit (most of which had bps) and then new items.
15:14:17 <rerngvit> #agree
15:15:14 <n0ano> OK, I'm hearing silence on new items (sending email to the dev list is always welcome if we think of things later) so to begin
15:15:24 <n0ano> #topic extending data in host state
15:15:59 <n0ano> I have a BP to address this but there seems to be another almost identical one outstanding so I have to coordinate between the two proposals
15:16:34 <n0ano> I didn't hear any objections to the idea at the summit, is that the consensus on this call, this is a good idea?
15:16:40 <glikson> maybe you can post here the URLs, for reference?
15:16:53 <rerngvit> one main question is should the data be moved to Ceilometer.
15:17:09 <n0ano> They're in the etherpad from the summit, I can scrounge them up
15:17:17 <rerngvit> URLs please
15:17:50 <n0ano> rerngvit, not sure, I'm not sure I want to make the scheduler totally dependent upon ceilometer, I'd rather have ceilometer as an enhancement
15:18:07 <glikson> seems that there is an agreement that it is a generally useful capability -- the question is whether there is a concrete enough proposal on what can/should be done in Havana?
15:18:22 <n0ano> url for the etherpad - https://etherpad.openstack.org/HavanaSchedulerFeatures
15:18:52 <dachary> n0ano: +1 ceilometer is a great source of measure for the scheduler but there is no reason why it should be mandatory
15:19:06 <Senhuang> I agree that we should keep the data in nova for mow.
15:19:16 <rerngvit> ok
15:19:25 <jgallard> dachary, +1
15:20:09 <n0ano> glikson, I know I'm talking about supporting plugins that entend the periodic data that is sent to the scheduler, pretty concrete and easy enough to do I believe.
15:20:27 <winston-d> dachary: +1
15:21:12 <rerngvit> nOano: do you mean the ResourceTracker or other component?
15:21:46 <n0ano> rerngvit, yes, I'm talking about the resource tracker
15:21:55 <glikson> n0ano: how would you maintain it in host manager? key-value pairs? is it complementary to 'stats'?
15:23:06 <n0ano> glikson, yes, basically have a resource dictionary with a set of key/value pairs
15:23:34 <n0ano> plugins could add new key/value pairs and appropriate scheduler filters could utilize those values
15:23:36 <rerngvit> but the 'stats' is already a dictionary
15:24:12 <rerngvit> how it differs?
15:24:20 <n0ano> I think I wanted to leave stats for compatibility purposes and make the new stuff new but I'm open to suggested changes
15:25:03 <n0ano> tell you what, let me coordinate with the other effort and then we can discuss the nitty gritty details at next weeks meeting
15:25:20 <n0ano> I can also send out reference material so we all know what we're talking about
15:25:27 <rerngvit> hmm, I think that's a good idea
15:25:49 <garyk> n0ano: agreed. we need to go ovber the high level details and then see how to address each
15:25:49 <glikson> ok, sounds good
15:26:06 <n0ano> #action n0ano to bring a more detailed proposal to next weeks meeting
15:26:25 <n0ano> tnx everyone, this is very helpful so far
15:26:36 <n0ano> #topic utilization based scheduling
15:26:59 <rerngvit> ok, I can help a bit then.
15:27:16 <glikson> I guess this one is highly related in terms of metrics collection.. using stats.
15:27:19 <rerngvit> for this, as I was working on the blueprint
15:27:38 <rerngvit> yes, exactly
15:27:57 <n0ano> indeed, turns out my BP is in this section when it should be more properly in the prior one
15:28:05 <rerngvit> we were submitting a patch (https://review.openstack.org/#/c/18462/) but was rejected in the end
15:28:22 <rerngvit> the reason was that it was not clear how this should be implemented.
15:28:46 <rerngvit> the way the patch work is separated into two parts.
15:29:05 <rerngvit> The first part collecting utilization, which is extending the 'stats' dictionary in the resource tracker.
15:29:22 <glikson> it might make sense to enable different frquencies of sending updates to the scheduler, or even entirely different mechanisms for static vs dynamic metrics..
15:29:25 <rerngvit> While the second part, in two new filters utilizing those utilization
15:30:01 <glikson> maybe 'stats' could be the way for more dynamic metrics..
15:30:59 <n0ano> I think this is pretty much what I wanted to do with plugins (while not addressing the frequency of update issue)
15:32:30 <garyk> i am not sure of the details but are average, peak and current utilization reported?
15:32:53 <n0ano> garyk, reported by whom?
15:33:07 <glikson> another potential enhancement could be to do some level of aggregation before sending to the scheduler.. anyway, at some point it does make sense to use a more generic metrics collection mechanism, I guess.
15:33:21 <rerngvit> it keep multiple samples, says previous 10 collects.
15:33:27 <glikson> but it seems reasonable to have some that within Nova
15:33:35 <garyk> n0ano: the hosts will need to notify the scheduler. or is this via ceilometer?
15:33:50 <rerngvit> so that derived statistics like average and peak, can be computed afterward
15:34:24 <glikson> maybe it might make sense to introduce a metrics collection API within Nova, and have one implementation using PRC within Nova, and another one using Ceilometer.
15:34:26 <n0ano> rerngvit, who does the computing afterward, the compute node or the scheduler
15:35:30 <n0ano> glikson, we already have communication from compute node to scheduler, isn't that sufficient (no new API needed)
15:35:32 <rerngvit> nOano: I'm 80% sure on this but should be the compute node
15:36:22 <n0ano> n0ano, I agree, better to spread the work out among all the compute nodes.
15:36:38 <glikson> n0ano: the thing is that it doesn't have to be via direct RPC between nova-compute and the scheduler..
15:37:12 <n0ano> glikson, not sure how that would work
15:37:19 <glikson> it could be an abstract API, sith RPC backend and Ceilometer backend
15:37:26 <glikson> *with
15:37:38 <garyk> i think that ceilometer has agents that already do something like this.
15:38:07 <n0ano> glikson, note that I don't think we want the scheduler calling the nodes, we want the compute nodes sending to the scheduler
15:38:53 <glikson> we can decide what semantics to define.. maybe pub-sub.
15:39:17 <rerngvit> I think Pub-sub is a good idea.
15:39:39 <rerngvit> But, as glikson mention, probably, Ceilometer might have something already like this.
15:39:44 <n0ano> I'm not necessarily adverse, just need a lot more detail
15:40:31 <glikson> anyway, I am just saying that it seems pretty clear that more than one implementation might make sense, and we can start by defining an abstract API, with a simple implementation (basically refactoring the existing one), and few incremental enhancements.
15:41:15 <n0ano> glikson, +1 (as long as we keep any refactoring with a mind to the ultimate goal)
15:41:27 <rerngvit> glikson +1
15:42:17 <glikson> we took similar approach with service heartbeat (service group APIs), and it worked well (I think).
15:42:27 <n0ano> winding down on this topic a bit, rerngvit do you want to take to lead to move this forward?
15:42:56 * russellb thought this meeting was 1500 UTC?
15:42:58 <rerngvit> yes.
15:43:28 <n0ano> russellb, according to my clock it is now 15:43 UTC
15:43:28 <rerngvit> However, I simply don't know how. This is my first Opensource project involvement.
15:43:29 <russellb> oh, i just suck at times zones
15:43:48 <n0ano> russellb, welcome to the club
15:43:57 <n0ano> s/club/club :-)
15:44:01 <russellb> also means i have a conflict every week
15:44:05 <rerngvit> hello, russlelib
15:44:16 <n0ano> rerngvit, not problem, we don't bite
15:44:23 <russellb> so i'd like someone to attend the nova meeting on thursdays each week to provide a roll-up summary on what this group is up to
15:44:37 <n0ano> russellb, sorry, this was the best compromise I could come up with
15:44:54 <russellb> no problem, i know not everyone can make it no matter what you pick!
15:44:59 <russellb> just letting you know i'm not ignoring
15:45:00 <n0ano> russellb, depends, what time is the nova meeting
15:45:08 <russellb> 2100 UTC
15:45:34 <garyk> i am unable to make that time
15:45:35 <rerngvit> sorry, it's 10pm in my timezone, not very convenient
15:45:36 <garyk> sorry
15:45:36 <n0ano> that's should be 3PM MDT, I can commit to doing that
15:45:39 <glikson> this would be 2400 UTC in my timezone.. not perfect
15:46:01 <glikson> sorry, just 2400
15:46:22 <n0ano> #action n0ano to attend nova meeting to provide rollup of this meeting
15:46:48 <winston-d> come on, folks, i've got used to 2300/2400 meetings for a year. :)
15:47:24 <n0ano> #action rerngvit to address utilization based scheduling at the next meeting
15:47:30 <rerngvit> ok, then we should try to define the abstract API then.
15:47:39 <rerngvit> oki, do ki
15:47:45 <n0ano> moving right along, I think we have time for one last agenda item today
15:47:56 <n0ano> #topic whole host allocation capability
15:48:33 <n0ano> anyone online who can talk to this (not my area)
15:48:49 <winston-d> is phil here?
15:49:02 <garyk> n0ano: regarding the ensembles/vclusters. Senhua Huang, glikson and I will try and propose an API next week (sorry I am just butting in0
15:49:13 <glikson> russellb: FYI, last thing we discussed was to try defining a new internal API to handle metrics (e.g., pub-sub), and have rpc-backed implementation (similar to what is there today), and potentially maybe also Ceilometer-backed one.
15:49:27 <n0ano> garyk, np, getting prepared is good.
15:50:38 <glikson> n0ano: maybe we should defer phil's topic(s) till next meeting
15:50:44 <n0ano> hearing silence on this topic, I'll keep it for next week
15:50:52 <rerngvit> agree.
15:51:22 <n0ano> note that I don't want things to get out of hand, I'll probably drop agenda items if there's no discussion in 2 consecutive meetings
15:51:43 <glikson> should we move to #4 then?
15:51:46 <n0ano> moving on
15:51:57 <n0ano> #topic coexistence of different schedulers
15:52:15 <glikson> I've jsut created a new bluprint on this: https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers
15:52:58 <n0ano> glikson, do you want to provide an overview or should we do our homework, review your BP and talk about it next week?
15:53:17 <glikson> essentially the idea is to allow overriding the defition of scheduler driver for specific host aggregates
15:53:23 <rerngvit> I can't access the specification.
15:54:28 <n0ano> rerngvit, the link works fine for me
15:54:38 <glikson> rerngvit: strange..
15:54:53 <rerngvit> (Sorry, you don't have permission to access this page or the information in this page is not shared with you.) :(
15:55:05 <rerngvit> it's ok. I can try to solve the issue later
15:55:08 <johnthetubaguy> (so previous whole host scheduler thing, I am interested, just have meeting clashes at the moment, sorry)
15:55:10 <n0ano> my mistake, the BP is fine, the specification is restricted as rerngvit says
15:55:35 <garyk> the link on the BP is problematic
15:55:56 <n0ano> johnthetubaguy, will you be able to talk about this issue next week at this time?
15:55:58 <glikson> you mean, the URL within the bp? it doesn't point anywhere at the moment.
15:56:00 <russellb> for blueprints, make sure you follow the instructions i put in a message last week to get them into the havana roadmap
15:56:52 <johnthetubaguy> n0ano: I can try
15:57:04 <n0ano> johnthetubaguy, that's all we can ask, tnx
15:57:12 <rerngvit> russlelib, could you please provide a link to the message?
15:57:45 <russellb> https://twitter.com/russellbryant/status/327094906994688000
15:57:51 <n0ano> all - aproaching the hour, let's end things here and continue on next week
15:57:59 <russellb> http://lists.openstack.org/pipermail/openstack-dev/2013-April/007788.html
15:58:04 <rerngvit> russelib:thx
15:58:24 <n0ano> I want to thank everyone, talk to you again in a week (if not via email before then)
15:58:33 <garyk> n0ano: thanks!
15:58:33 <n0ano> #endmeeting