15:00:30 #startmeeting gantt 15:00:30 Meeting started Tue Oct 7 15:00:30 2014 UTC and is due to finish in 60 minutes. The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:33 The meeting name has been set to 'gantt' 15:00:39 anyone here to talk about the scheduler? 15:01:03 o/ 15:01:38 o/ 15:01:59 \o 15:02:47 OK, let's get started 15:02:52 #topic forklift status 15:03:28 I reviews patch 110043 but I need to get on 119807, bauzas how are those coming? 15:04:00 n0ano: one sec, finding which changes you're talking :) 15:04:22 they're your patches, I thought they were burned in your brain :-) 15:04:38 n0ano: my changelist is becoming huge so I'm getting lost 15:04:48 so, indeed 15:04:54 https://review.openstack.org/110043 15:05:08 #link https://review.openstack.org/110043 setup_instance_groups is ready for reviews 15:05:15 jaypipes already gave a +2 to it 15:05:20 jaypipes: around ? 15:05:45 so that one is quite a no-brainer 15:06:06 I hope to get some support, and ideally folks are welcome for reviewingi t 15:06:13 bauzas: yes, sorry, still working on blueprints... 15:06:25 jaypipes: no worries, was talking about https://review.openstack.org/110043 15:06:31 see https://etherpad.openstack.org/p/kilo-nova-priorities for commentary 15:06:45 it's gotten positive reviews but I don't see a +2 on it 15:06:50 jaypipes: you already gave a +2, ideally it would be good if you could re-review it 15:07:06 bauzas: yes, will re-review shortly. 15:07:12 n0ano: that's due to a change needed for caching the list of fitlers 15:07:26 now, the big piece 15:07:36 aah, a prior version got the +2, nevermind 15:07:36 https://review.openstack.org/119807 15:07:41 fitlers == very aggressive, dominating filters. 15:07:46 :) 15:08:00 so https://review.openstack.org/119807 will be abandoned soon 15:08:36 bauzas: ok, +2 from me on that one 15:08:54 so, I just abandoned 119807 15:09:01 jaypipes: cool thanls 15:09:22 now, the corresponding patch is being split into smaller chunks here 15:09:37 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1357491,n,z 15:10:00 ideally, we need to create a blueprint for this bug 15:10:08 I don't think we need a spec 15:10:21 bauzas, so it'll basically be the same changes just broken out into smaller pieces, right? 15:10:24 the last bits are missing from the series 15:10:28 n0ano: right 15:10:38 n0ano: it still misses 2 or 3 last patches 15:10:53 that's my on-going work 15:11:29 so reviews are welcome too 15:11:55 bauzas: will review later this afternoon, for sure. 15:11:58 given that you have these patches tied to a bug we shouldn't need a separate BP for this work 15:12:55 n0ano: well, that's a tech debt bug, so a blueprint is kinda accepted 15:13:25 seems a little silly since the BP will just be a rewrite of what's in the bug but if that's the mechanism required 15:13:47 n0ano: that's the thing, a bugfix is typically smaller than that 15:14:12 n0ano: tracking patch series is FWIW better with blueprints 15:14:32 anyway 15:14:39 we also have kind of a no-brainer too 15:15:06 https://review.openstack.org/117042 ComputeNode creation at init stage 15:15:18 that one is currently marked as WIP because of a merge issue 15:15:26 bauzas: that ^^ is another "bug" I filed :) 15:15:33 I'll try to find some time to fix it 15:15:51 anyway all the bits are coming in 15:16:05 and another one from PaulMurray should also help us 15:16:08 PaulMurray ? 15:16:24 bauzas, which one are you thinking of 15:16:36 the supported_instances thing 15:16:44 bauzas, nearly there 15:16:52 that's the last piece of work for using the ComputeNode object 15:17:11 bauzas, there's a bit of pci I think? 15:17:39 PaulMurray: really ? I was thinking that PCI was ready for this 15:17:59 bauzas, let me find the patches, hold on 15:18:07 #link https://review.openstack.org/125091 Add supported_instances to ComputeNode 15:18:22 that's the one worked by PaulMurray $ 15:18:25 ^ 15:18:37 https://review.openstack.org/#/c/110739/ 15:18:58 https://review.openstack.org/#/c/76053 15:19:27 I haven't been in touch - this is last I think 15:19:58 I can ping Yunhong about those, he's on holiday this week 15:20:07 n0ano: sure would be nice 15:20:08 n0ano, please do 15:20:14 n0ano: we need to cover those 15:20:39 man, the ComputeNode object will become horrible 15:20:47 they weren't reject per se, just missed the deadline so we can do them in Kilo 15:20:57 because of the backwards compatibility and all these version bumps 15:21:07 n0ano: +1 15:21:28 bauzas, never mind the version bumps - it doesn't really matter 15:21:33 the real world (things like backwards compat) forces a lot of warts, just have to deal with it 15:21:49 PaulMurray: well, think about the lovely rebases you'll have to gezt 15:22:02 PaulMurray: I'm having 4 version bumps in my patch series :) 15:22:17 anyway 15:22:38 so, bottom line, I'm seeing about a half dozen patches we need to get done before we can even consider the split 15:22:53 we can also think about providing a middleground support for objects 15:23:07 n0ano: yeah, that ComputeNode object is kinda messy now 15:23:22 but we can also figure out what bits are missing and workaround them 15:23:40 ie. send to the sched an object plus extra dicts 15:23:49 I'm more concerned about the interfaces to the ComputeNode than the object itself 15:23:50 s/dicts/dict or kwarfs 15:23:57 kwargs 15:24:18 n0ano: the interfaces are there already 15:24:36 n0ano: ie. select_destinations() and update_resource_stats() 15:24:44 as long as the interfaces don't change because we've changed the object, that's my concern 15:25:11 n0ano: here you will pass objects instead of dicts but you won't change the interface 15:25:45 bauzas, I'm hoping you're right (I just worry a lot) 15:25:46 I mean, request_spec and filter_properties will become objectified in order to be sent thru select_destinations 15:26:10 and stats will be also objectified in order to be sent thru update_resource_stats 15:26:37 n0ano: see jaypipes's long monologue in the projects priorities etherpad :) 15:26:48 heh 15:27:01 https://etherpad.openstack.org/p/kilo-nova-priorities 15:27:19 jaypipes: seriously, you beat me up on the length 15:27:20 :) 15:27:36 bauzas: oh, it will be quite a bit longer shortly. 15:27:46 awesome readability 15:27:47 bauzas: was working on dropping a bomb on the TC: https://review.openstack.org/#/c/126582 15:28:01 bauzas: now back to blueprints... 15:28:04 can we perhaps move on and discuss on the Summit talks ? 15:28:18 bauzas, took the words out of my mouth 15:28:24 #topic kilo summit 15:28:47 I saw ttx's proposed schedule and note that gantt doesn't have any specific sessions 15:29:19 do we have to lobby for that or is the assumption that gantt will be discussed in one of the nova sessions? 15:29:26 n0ano: we're not officially an official program 15:29:27 n0ano: it's proposed in a cross-project workshop, and as an "other project" 15:29:44 n0ano: it should go in the cross-project sessions on monday and tuesday, IMO 15:29:50 I would place my bet on "cross-project workshop" 15:30:01 or possibly in the Other Projects track, though I'd prefer not to do that 15:30:02 jaypipes: design sumit starts on Tuesday fwiw :) 15:30:12 ttx: oh, sorry, duh 15:30:36 I was hoping for a cross-project session on tues and a gantt specific slot on wed or thurs 15:30:42 ttx: yeah I mass-filed that one by crossposting to both etherpads 15:31:36 n0ano: we should get a slot by the Nova team I expect 15:32:01 n0ano: this, plus a cross-project session or an other-projects sessions, or both 15:32:20 well, I think the critical one is the cross-project, I'd like to get concensus from other projects on what they want from a scheduler 15:32:29 n0ano: plus I was thinking of doing kinda BoF thing like the NFV team did in ATL 15:32:39 n0ano: +1 15:32:49 n0ano: hence the bet from ttx 15:33:31 n0ano: if we get enough people in the cross-project session, we could raise voice for a BoF event 15:33:38 about Gantt and others 15:33:58 jaypipes: your thoughts on that ? 15:34:13 as a TC member, take your hat 15:34:18 If we don't get a gantt specific on wed/thurs then a BoF would work, I don't think we need both 15:34:37 n0ano: wed/thur are project-specific 15:34:48 bauzas, exactly 15:34:59 n0ano: so the discussion will be around how we do the split 15:35:15 n0ano: not about how we integrate with other projects 15:35:21 we need 2 session, one on cross project issues and one on gantt specific (mainly the split) 15:35:43 I'm personally convinced that we will feed a 3rd session needed :) 15:35:53 feel (dammit!)à 15:36:05 bauzas, what would the 3rd session focus on? 15:36:22 I'm interested in the refactoring scheduler interfaces sessions 15:36:42 but not so much on the gantt-specific session -- just because I know exactly what it will devolve into. 15:36:59 jaypipes: k thanks :) 15:37:30 it will just be a whine-fest about how much NFV and other teams want to tinker with the scheduler to place VMs closer to storage or network devices. 15:37:32 n0ano: I dunno I just remember the 40-min session in ATL and how time passed 15:37:47 and frankly, I already know what folks want to do with a split-out-scheduler 15:38:07 jaypipes: eh, we'll be in France, so it could be a wine fest 15:38:12 and I don't mind those things, but think the refactoring is more important. 15:38:18 jaypipes, my worry is the details, know what you want to do is different from how to achieve it 15:39:22 anyway, time is moving fast, maybe we can talk about this next week ? 15:39:35 my real worry is NFV & Neutron, I think I understand what Cinder/Containers/Ironic need, I'm worried that Neutron will be wildly different 15:39:37 I would like to discuss about bps and the draft from jay 15:39:44 I promise I will have all the refactoring BPs related to RT and scheduler done by then. 15:39:50 promise. 15:40:01 jaypipes: I can help you on this 15:40:03 but yes, we can move on, let's just keep an eye on the summit scheduling 15:40:07 jaypipes: that's in my agenda 15:40:10 jaypipes, is there an early version? 15:40:17 #topic Kilo BPs 15:40:21 PaulMurray: of the blueprints? 15:40:31 jaypipes, of anything 15:40:39 jaypipes, to do with RT 15:40:45 https://etherpad.openstack.org/p/kilo-nova-priorities is a good starting point 15:41:02 PaulMurray: https://etherpad.openstack.org/p/kilo-nova-priorities 15:41:16 jaypipes, yes, saw that 15:42:27 jaypipes, so you are planning on creating a Kilo BP about the RT changes, not just an etherpad rant? 15:42:37 n0ano: yes. 15:42:42 n0ano: they are underway. 15:42:44 * n0ano means rant in the positive way 15:42:52 jaypipes, excellent 15:42:58 n0ano: I just wanted to make sure the refactoring sessions get on the summit schedule 15:43:06 jaypipes, +1 15:43:37 jaypipes: agreed 15:44:56 so I'm seeing only 2 BPs for Kilo, RT refactoring and the split, those are the two biggies 15:45:13 n0ano: we need to be more precise 15:45:33 jaypipes: could we just share what you're about to send before submitting it ? 15:45:45 n0ano: here, we need to consider 15:45:59 A/ ComputeNode object tech debt effort 15:46:02 n0ano: I have 5 blueprints for Kilo involving refactoring. 15:46:26 B/ request_spec and filter_properties objectification 15:46:32 jaypipes, all related to RT or about different areas 15:46:50 C/ stats objectification 15:46:51 n0ano: about RT, instance group and scheduler interfaces 15:46:56 D/ use of Claims within RT 15:47:12 oops, s/RT/scheduler 15:47:24 bauzas: yes, and I even have B/ split into 2 blueprints... 15:47:36 jaypipes: I really like your proposal of sending a claim to the compute with a RPC abort method 15:47:52 what are the realistic odds that we can get ~10 different BPs approved and integrated in the Kilo timeframe 15:48:38 n0ano: I turn the question into what are the realistic odds if we don't do that ? :( 15:49:00 n0ano: IMO, it's more realistic to get 10 slimly-defined BPs approved than 3 widely-defined BPs approved. 15:49:07 n0ano: which is why I'm taking this tack. 15:49:10 jaypipes: +1 15:49:30 we'll see (see above, I worry a lot) 15:49:54 n0ano: whatever the effort could be, we'll still have to figure out how to get core support 15:50:14 and that's not really related to our coding bandwidth 15:50:19 n0ano: worrywart. 15:50:39 jaypipes, somebody's has to be the Nanny :-) 15:50:50 bauzas: ftr, you will have ndipanov_gone and myself as core support for all of these refactoring BPs... 15:51:06 bauzas: and likely danpd's support on many of them. 15:51:25 jaypipes: good to hear 15:51:29 that will be good 15:52:02 OK, I think we know what we're doing here 15:52:08 #topic opens 15:52:15 jaypipes: I'm again emphasizing my wishes for seeing the bps before they're proposed, if possible :) 15:52:47 (Re-)Introducing myself: I worked on scheduler years ago, and am looking to get back into things with gantt. 15:52:54 I'm looking for some guidance as to where I can start contributing now. 15:53:01 jaypipes: because I'll probably be the worker ant behind that 15:53:16 bauzas: I would like to be a worker ant as well :) 15:53:26 edleafe, you can start by reviewing the patches we talked about early today, that would be a good way to get your feet wet 15:53:36 bauzas: but yes, will put each on etherpad for you to comment/review/change before proposing. 15:53:44 n0ano: will do 15:53:45 jaypipes: cool 15:53:55 edleafe: yeah, take time in reviewing all the scheduler changes 15:54:10 edleafe: try to get knowledge of the non-verbal things 15:54:19 edleafe, as we create the BPs we talked about some tasks will come up that you can take 15:54:35 bauzas: any existing reference material? 15:54:40 edleafe: Gerrit :) 15:54:46 bauzas: :) 15:54:54 Just didn't want to re-invent any wheels 15:54:58 edleafe, documentation - you silly person :-) 15:55:09 Yeah - what a concept 15:55:14 ;-) 15:55:27 edleafe: you having time ? 15:55:31 google openstack+scheduler and you'll find some stuff 15:55:40 n0ano: man, this info is pretty old 15:55:49 bauzas: Yes - I'm now tasked full time on OpenStack dev work 15:56:02 n0ano: I googled once in a time, and all the internal docs are quite old (2012 or so) 15:56:05 bauzas, I was going to caution about that but yes, it's old but gives an idea 15:56:07 And scheduler is where I worked most in the past 15:56:26 edleafe: well, atm, scheduler is not the real problem 15:56:32 I did the google approach, and yeah, things were old 15:56:42 edleafe: you probably understood that we need to work on cleaning up the interfaces 15:56:48 bauzas: exactly 15:57:05 edleafe: so, not really coding on the scheduler itself, but more likely on what we send to it 15:57:18 and those I/Fs are rather poorly documented unfortunately 15:57:33 edleafe: TBH, the FilterScheduler is kinda robust, so we won't reinvent the wheel 15:57:47 bauzas: how to separate it, and how to define the interfaces - that's what I'm looking at 15:57:52 n0ano: nope, the best way is to pdb them :) 15:58:17 bauzas, ignoring proposals like holistic scheduling which kind wants to replace the guts of the scheduler 15:58:27 s/kind/kind of 15:58:45 anyway, we're approaching the top of the hour and I have to run 15:58:46 edleafe: https://review.openstack.org/117042 15:58:52 n0ano: With a clean interface, they could do that 15:59:06 edleafe: you can maybe begin on that one 15:59:19 bauzas: sure. I 15:59:22 ugh 15:59:23 edleafe: all the stuff is already there, I'm just having an issue 15:59:26 edleafe, you can do it right now, the filter scheduler is pluggable, but do you really want to 15:59:30 I'll probably ping you with questions 15:59:35 edleafe: sure of course 15:59:42 edleafe, feel free, always willing to help 15:59:44 bauzas: just let me know if I get annoying ;-) 15:59:49 eh 16:00:00 tnx everyone, talk to you next week 16:00:03 #endmeeting