15:02:51 <n0ano> #startmeeting scheduler
15:02:52 <openstack> Meeting started Tue Sep  3 15:02:51 2013 UTC and is due to finish in 60 minutes.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:56 <openstack> The meeting name has been set to 'scheduler'
15:03:09 <n0ano> we can start the meeting, just on the off chance some others arrive
15:03:16 <PhilDay> Sure
15:04:27 <garyk> on the mail list you mentioned you wanted to speak about ideas for sessions at summit
15:05:00 <n0ano> yeah, I thought maybe we should coordinate a little, see what ideas people have
15:05:14 <n0ano> #topic session topics for the Icehouse summit
15:05:26 <glikson> hi
15:05:50 <glikson> 'future of scheduler'? :-)
15:05:55 <garyk> cool. myself and a few colleagues have been discussing extending the image properties filter and would like to expand on this to be able to deploy templates
15:05:56 <n0ano> one thought was should we have a big `futures` session to talk about long term directions
15:06:20 <n0ano> glikson, looks like we're on the same page here
15:06:35 <garyk> that is, have the image properties, couple with host support drive the scheduling decisions
15:07:01 <glikson> another candidate would be around scheduling policies
15:07:04 <PhilDay> Would be good if we can avoid last year's crush of trying to do 11 subjects in one session
15:07:08 <n0ano> garyk, seem like something close to what my group has been calling enhanced platform awareness
15:07:37 <garyk> n0can you please elaborate a little more on ethat
15:07:46 <PhilDay> I think part of the reason it was hard to land soem changes in H was that they didn't really get enough time at the summit
15:07:49 <glikson> PhilDay: agree.. PTL sets the agenda, right?
15:07:58 <n0ano> PhilDay, partly that was due to a lot of late submissions, if we can be more prompt this year it might be better
15:08:28 <garyk> the instance group feature has been in the queue since the beginning of H.
15:08:39 <n0ano> glikson, I would imagine there's also only so many sessions available, hard to fit everything in
15:09:08 <glikson> n0ano: sure, so, it is also a matter of priorities
15:09:11 <garyk> the last summit there were a ton of scheduling sessions. i think that we did well to collaborate on presenting the data.
15:09:22 <garyk> phil was instrumental in getting everyone together before and syncing
15:09:44 <garyk> i hope that this time we will also have a platform to present ideas and discuss them
15:10:04 <glikson> I am not saying anything went wrong in Portland.. Just saying that maybe this time there will be more awareness.
15:10:05 <PhilDay> Feels like we need a session to bottom out the whole "to what extend should the scheduler depend on or just feed into celiometer" issue
15:10:29 <garyk> agreed.
15:10:35 <n0ano> PhilDay, that's an important area that will warrant a separate session I belive
15:10:38 <glikson> PhilDay: yep, metrics, etc
15:10:58 <garyk> but this is certainly something that we would need to try and sync with the ceilometer guys and have a combined session
15:11:22 <glikson> it could be also related to the question of using DB versus RPC versus whatever to keep/deliver metrics..
15:11:34 <debo_os> sorry for joining the chat late - are we trying to use ceil for communicating the "state" that a scheduler can use later on or just for metrics
15:11:54 <n0ano> So I;m seeing at least - future directions, metrics(Ceilometer), image properties&host capabilities - at least 3 sessions so far
15:12:18 <glikson> n0ano: policies
15:12:24 <PhilDay> Does Future directiosn cover teh proposal from Boris et al ?
15:12:38 <n0ano> glikson, oops, that's 4 - DB vs. fanout
15:12:43 <garyk> glikson: yeah, things we want to add to instances
15:12:53 <debo_os> +1
15:13:17 <glikson> also would be good to revisit the topic of scheduling across nova/cinder/etc
15:13:19 <PhilDay> I want to do a session on the pcloud / whole host stuff - only partially related to scheduler though
15:13:38 <garyk> PhilDay: i think that the performance is very important. Not sure if implementation details is where the discussion is at the moment (that is my two cents)
15:14:03 <PhilDay> @garyk - sorry, not sure i follow ?
15:15:08 <garyk> PhilDay: in the few times we have spoken about boris's proposal the discussion seems to be drawn into the implementaion details. i think that there are design issues that we need to address first.
15:15:53 <n0ano> well, the big design issues is fanout vs. DB, until we resolve that it hard to go any further
15:16:04 <PhilDay> Ok, yes agreed. a shared view of the design is the key thing we need to come away with
15:16:07 <garyk> n0ano: agreed
15:16:54 <garyk> boris-42: you around?
15:17:08 <boris-42> yes I am here
15:17:11 <boris-42> garyk ^
15:17:20 <boris-42> whats up?
15:17:58 <n0ano> boris-42, we're talking about potential summit sessions, are you planning on doing one on your scheduler proposal
15:18:02 <debo_os> garyk: +1 about hte design comments ....
15:18:02 <garyk> same same. we are talking possible scheduler sessions ad the performance issue arose. i guess we should have a session on that too.
15:18:10 <boris-42> n0ano yeah it will be nhice
15:18:20 <boris-42> n0ano we are going to present real nubmers
15:18:34 <boris-42> n0ano between current and our approaches
15:19:11 <glikson> regarding DB versus fanout.. would it be feasible to keep both? e.g., with a separate HostManager implementation?
15:19:21 <boris-42> there is no fanout
15:19:28 <boris-42> w don't want to use fanaout at all
15:19:41 <doron> guys, isn't the hong-kong sessions voting ended already, or is this for a different scope?
15:19:43 <n0ano> boris-42, one issue is design vs. implementation, we're still lacking concensus on the basic design, how do we achieve that
15:19:54 <boris-42> just another way to store in key value storage all information
15:19:58 <debo_os> boris and I have started merging the 2 documents
15:20:01 <boris-42> n0ano we already achive it
15:20:21 <boris-42> n0ano but we should make some other cleanups
15:20:31 <debo_os> https://docs.google.com/document/d/1cR3Fw9QPDVnqp4pMSusMwqNuB_6t-t_neFqgXA98-Ls/edit# and boris' implementation details into one
15:20:33 <boris-42> n0ano to remove compute_nodes table and compute_nodes update
15:20:33 <n0ano> doron, no, that's for presentations, working sessions are still open
15:20:54 <doron> n0ano: thanks. I'd love to join
15:21:21 <n0ano> boris-42, I'm not sure we have concensus, I think jog0 is still unconvinced at minimum
15:21:40 <boris-42> n0ano we will show numbers from real deployment
15:22:18 <boris-42> n0ano btw here is patch
15:22:19 <boris-42> https://review.openstack.org/#/c/43151/
15:22:29 <boris-42> that improves performance in safe way
15:22:34 <n0ano> numbers are good but they don't trump all other considerations
15:23:08 <n0ano> note that I'm really Devil's Advocate here, I happen to mostly agree with you but I don't think everybody does
15:24:33 <garyk> i agree partially but there is a still a lot of cases to be discussed.
15:24:59 <n0ano> which is why I think real resolution will have to happen at the summit
15:25:06 <boris-42> n0ano numbers that could be repeated are not just numbers
15:25:16 <garyk> i think if we have a session at the summit it will be great. number also help, but use cases and understanding the exact tests is also very important
15:25:33 <boris-42> n0ano we are going to add new project Rally (that will be benchmark system for OS)
15:25:50 <n0ano> garyk, +1
15:25:52 <debo_os> can we have a list of requirements for the scheduker improvements from everyone and collate a bunch of approaches
15:26:04 <garyk> debo_os: +1
15:26:20 <boris-42> +1
15:26:27 <boris-42> yes this should be done before session
15:26:30 <debo_os> have a etherpad for now
15:26:37 <debo_os> yeah it needs to be done now
15:26:42 <garyk> that is a good approach
15:26:56 <n0ano> boris-42, curious about Rally, would like more info on that (but later)
15:27:03 <garyk> coming with crystalized ideas will enable us to hash out the details
15:28:07 <debo_os> for example one clear requirement is to make placement decisions based on cinder nova neutron
15:28:23 <debo_os> also scheduler = placement + state machine to shedule
15:29:01 <debo_os> if we can collect simple requirements and then hash out pre summit we might have conclusions by nov 8
15:29:44 <n0ano> debo_os, I think you're a little optmistic, if we can just get the requirements out before then I'd be happy (conclusions come later)
15:30:00 <PhilDay> +1 to setting up either pads now for the set of sessions that non captures from this session (or maybe one pad to plan the sessions?)     If we can offer Russell a list of 4-5 scheduler session we want to have that might be a good way to avoid last year's problems
15:30:02 <debo_os> n0ano: optimism is cheap ;)
15:30:25 <garyk> PhilDay: +1
15:30:50 <n0ano> PhilDay, I like the idea of 1 etherpad for planning, does someone want to signup for creating/maintaing that pad?
15:31:14 <garyk> one a practical level it would also be nice if we can get core reviewers to look at the various scheduling changes (some have been around for longer than forever)
15:31:29 * n0ano would sing up but I'm on vacation for the next 2 months (eat your hearts out :-)
15:31:45 <PhilDay> Sure - I can set up the pad
15:32:00 <garyk> PhilDay: i am happy to help out to
15:32:09 <n0ano> #action PhilDay to setup up scheduler planning etherpad for the Icehouse summit
15:32:31 <PhilDay> Thanks Gary
15:32:33 <n0ano> #action `everyone` to maintain the planning pad
15:33:49 <n0ano> let's move on a little bit
15:33:58 <n0ano> #topic multiple-scheduler-drivers
15:34:21 <n0ano> glikson, I believe there is some controvery on the mailing list about this, is there anything that can be done to resolve things?
15:34:30 <garyk> i like the idea :)
15:34:55 <glikson> So, almost nothing left from the original idea -- but we did submit several small incremental patches which should not be controversial..
15:35:27 <glikson> at least based on my discussion with jog0 the other day
15:35:44 <n0ano> so does that mean the ultimate design goal has changed?
15:36:17 <glikson> basically improving the existing AggregateCoreFilter and AggregateRamFilter -- making the overriding mechanism generic, and then extending to additional filters/option types
15:36:55 <glikson> well, the ultimate goal has not changed -- but the goal for Havana has
15:36:59 <n0ano> so kind of a step wise progression, which doesn't sound all that bad, just takes a little longer
15:37:06 <glikson> the rest requires discussion at the summit
15:37:14 <glikson> yep
15:37:34 <glikson> much longer :-)
15:37:38 <n0ano> glikson, refer back to the last action item, update the planning etherpad :-)
15:37:50 <glikson> yep, will certianly contribute to that
15:38:08 <n0ano> OK, onward
15:38:21 <n0ano> #topic temporary moderator
15:38:30 <glikson> as a general thought.. I think it would be very helpful to engage people from core early.
15:38:38 <debo_os> +1
15:38:53 <n0ano> Note this is my last meeting for 2 months, is there anyone willing to moderate this meeting while I'm gone?
15:39:56 <glikson> even not having someone from core in this forum is not a good sign..
15:40:40 <n0ano> glikson, just incentive for all of us here to become core members :-)
15:41:15 <n0ano> anyway, I don't need an answer right now, think about moderating this meeting, it's not that hard.
15:41:22 <n0ano> #topic opens
15:41:37 <n0ano> Anyone have anything new they want to bring up today?
15:42:25 <garyk> n0ano: i can moderate whilst you are away
15:42:39 <n0ano> garyk, excellent, tnx much
15:42:52 <garyk> n0ano: ok. from next week?
15:43:09 <n0ano> #action garyk to moderate this meeting for the next 2 months, start on 9/10
15:43:51 <n0ano> OK, hearing nothing else, let's close for today
15:44:11 <n0ano> tnx everyone, hopefully I'll see you all at the summit
15:44:17 <n0ano> #endmeeting