15:01:21 <n0ano> #startmeeting gantt 15:01:22 <openstack> Meeting started Tue Aug 12 15:01:21 2014 UTC and is due to finish in 60 minutes. The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:25 <openstack> The meeting name has been set to 'gantt' 15:01:30 <bauzas> \o 15:01:30 <n0ano> anyone here to talk about the scheduler? 15:01:38 <mspreitz> o/ 15:01:45 <tianst> o/ 15:02:50 * n0ano refuses to jinx things by saying we have a short agenda 15:02:57 <n0ano> #topic forklift status 15:02:58 <bauzas> some people are most probably on PTO this week 15:03:17 <n0ano> bauzas, good point, it's Aug., why aren't you on vacation? 15:03:26 <bauzas> n0ano: baby exception 15:03:30 <n0ano> :-) 15:03:48 <n0ano> Anyway, couple of things on the forklift, client library 15:03:52 <bauzas> and August is rainy here so was a good choice anyway... 15:03:55 <bauzas> sure thing 15:04:06 <bauzas> so 15:04:08 <n0ano> bauzas, looks like you've been rebasing a lot, what are the odds this is the last patch set 15:04:29 <bauzas> about sched-lib, was based on ERT patch which was merged 15:04:44 <bauzas> Jenkins is poorly handling conflicts 15:04:56 <bauzas> and here we were having one 15:05:44 <bauzas> but the code is 99.99% identical, except an unittest which needed to mock the call to ERT 15:05:45 <n0ano> looks like it's all +1 so, hopefully, it's good to go 15:05:51 <bauzas> think so 15:06:05 <bauzas> so now we need reviewers :) 15:06:18 <n0ano> my +1 is there :-) 15:06:38 <bauzas> unless ERT is reverted back again (but will discuss about it later... :) ) 15:06:44 <n0ano> I believe we have all 3 patches for isolating the DB posted, my bad I intend to review them today 15:07:09 <bauzas> n0ano: so about isolate-sched-db, the proposal is still needing a second +2 15:07:24 <n0ano> I wanted to ask, did you ping dipanov? 15:07:29 <bauzas> the real problem is that it sounds not sexy at all 15:07:42 <bauzas> n0ano: indeed 15:07:51 <bauzas> n0ano: ndipanov is not core on specs 15:08:02 <bauzas> n0ano: but he was sponsor 15:08:10 <n0ano> but he sponsored the exception, that wan't enough? 15:08:12 <bauzas> n0ano: so his main concern is about the use of ERT 15:08:44 <n0ano> what's the concern, ERT is merged so, technically, we should use it 15:08:48 <bauzas> his concerns about ERT are in this thread 15:09:08 <bauzas> http://lists.openstack.org/pipermail/openstack-dev/2014-August/042709.html ERT revert or not ? 15:09:38 <bauzas> n0ano: ERT code is not merged for scheduler consumes 15:09:41 <bauzas> consumers... 15:09:47 <ndipanov> bauzas, sponsoring at that point meant tha tI will review the code as a core reviewer 15:10:27 <ndipanov> but yeah - I'd prefer not to depend on the current implementation of the ERT 15:10:32 <bauzas> ndipanov: agreed, I was just mentioning why we discussed about you 15:10:57 <ndipanov> but that's just like... my opinion maaan 15:10:59 <bauzas> because most of the people probably don't know why we mentioned you :) 15:11:37 <bauzas> anyway, as I said, folks, please take time for reading this email and replying if willing 15:12:24 <n0ano> but wouldn't reverting ERT cause lots of problems? 15:12:25 <bauzas> ndipanov: yeah, that's why we probably need to think about a plan B 15:12:36 <Yathi> regarding ndipanov's concern, anything like ERT, will involve users feeding a lot of info while scheduling an instance.. 15:13:05 <bauzas> n0ano: my main concern is that the scheduler side of ERT is not pushed yet 15:13:09 <Yathi> so that is more like a we have to make it simpler from a scheduler perspective I guess.. if I got the concern correctly 15:13:49 <bauzas> Yathi: the current problem is about how we ensure that compute nodes can safely deny a request if scheduler made a wrong decision 15:14:09 <ndipanov> Yathi, the concern is that we are basing a plugin system on a bad/broken internal API (RT and Claims) that we are de facto making public 15:14:35 <ndipanov> the reason for badness is that there is no reasonable way to incorporate user supplied data into it at present 15:14:35 <bauzas> ndipanov: by public, you mean entrypoints ? 15:14:40 <ndipanov> yes 15:15:09 <bauzas> ndipanov: agreed, but that sounds to me a plain RT problem, not ERT 15:15:09 <Yathi> ok 15:15:17 <ndipanov> we don't really have a polcy for stability of those 15:15:27 <ndipanov> but if we are going to be breaking them 15:15:37 <ndipanov> I question the usefulness of the whole thing 15:15:40 <bauzas> I'm more concerned about the timings and wrt ERT, if it's good or no to depend on a patch which could probably not land by Juno 15:15:44 <ndipanov> them = 3rd party plugins 15:16:35 <bauzas> ndipanov: ok, then I see why you dislike ERT 15:17:10 <ndipanov> on top of the whole blobs thing that I didn't mention in the email 15:17:16 <bauzas> ndipanov: I just think we need to identify what's needed for the host to make decisions 15:17:30 <bauzas> ndipanov: replies are made for adding stuff you forget :) 15:17:45 <Yathi> I agree the internal APIs might need fixing.. but should that block this feature for now? 15:17:47 <bauzas> (says the one who forgot to add 2 links...) 15:18:01 <ndipanov> Yathi, which feature? 15:18:05 <ndipanov> ERT? 15:18:26 <Yathi> ndipanov: ERT, Gantt related patches 15:18:33 <ndipanov> well 15:18:35 <ndipanov> I am not sure 15:18:55 <ndipanov> I am being defensive in saying - if we leave it like that - we will have to let bad code in too 15:18:57 <Yathi> ndipanov: also Jay pipes has some proposal for rewriting claims 15:19:09 <ndipanov> that is not the only way forward of course 15:19:12 <Yathi> we agreed in the nova mid-cycle meetup to revisit after gantt 15:19:29 <ndipanov> but the fact that this is something you can write 3rd party pluggins against 15:19:36 <ndipanov> and we will need to break them 15:19:51 <ndipanov> makes me think about the whole point of ERT 15:19:57 <ndipanov> and that it may need to sit a while 15:20:07 <bauzas> Yathi: I can just propose another alternative without ERT 15:20:23 <bauzas> Yathi: we don't have too much dependency with ERT 15:20:34 <n0ano> bauzas, I was just going to ask how hard it would be to do that 15:20:45 <bauzas> Yathi: the real cool stuff of ERT for the isolate-sched-db are : 15:20:46 <Yathi> bauzas: I saw it is only the recent patches you got it.. to use ERT way of getting instances, flavors etc 15:21:07 <bauzas> #1 : possibility to add/remove plugins in a conf style 15:21:21 <bauzas> ie. only provide stats for what operator wants 15:21:53 <bauzas> #2 : interfaces in RT have already been written (and unittests too) so that's really a quick addition to do 15:22:28 <bauzas> n0ano: so if we say we go without ERT, I just need to write an helper class for doing this (plus tests) 15:22:44 <bauzas> I don't think it's huge thing 15:22:59 <bauzas> well, as ndipanov said, that's just matter of adding blobs into blobs... 15:23:04 <Yathi> bauzas: let's probably wait for it.. to see if ERT will stay or not 15:23:20 <bauzas> Yathi: I disagree with you 15:23:24 <n0ano> hmm, the tests would probably be close to the current RT tests so that shouldnt' be that big a deal, I think I like this as a plan B, even if it's more work for us 15:23:30 <bauzas> Yathi: Juno-3 is in less than one month 15:23:44 <bauzas> n0ano: +1 15:23:55 <Yathi> bauzas: oh sure.. I see the time crunch.. 15:23:58 <bauzas> n0ano: that's just removing the user-facing stuff (and plugins) 15:24:03 <n0ano> I agress with bauzas , the schedule is tight, waiting is not a good option 15:24:44 <bauzas> the proposal won't probably include #1 (configurability of plugins) 15:24:58 <bauzas> ie. instances and flavors will be provided 15:25:05 <n0ano> bauzas, I don't see that as a problem, that's a future enhancement 15:25:20 <bauzas> n0ano: it was my next phrase, stop reading in minds 15:25:50 * n0ano fightening, we're beginning to sound like an old married couple :-) 15:26:06 <bauzas> about planning, I freed up my tasks because I delivered both plugins (except aggs but tianst is handing it) 15:26:14 <bauzas> so I can handle that 15:26:31 <bauzas> I'll just be on PTO Thurs->Mon 15:26:45 <n0ano> sounds like a plan, just do it 15:26:56 <bauzas> but that just means less time to work, not nothing :D 15:27:29 <n0ano> still the question of the final +2 for the spec, should we ping jogo or someone? 15:27:39 <Yathi> you can work in your PTO no ? bauzas :) 15:27:40 <bauzas> n0ano: feel free to do so 15:28:00 <bauzas> n0ano: my karma (and my politics skills) are not that good these days :p 15:28:07 <n0ano> OK, I'll see if I can get his attention 15:28:18 <bauzas> n0ano: anyway, most of the cores are US based 15:28:27 <bauzas> n0ano: so that sounds a better option 15:28:43 <bauzas> n0ano: provided you feel enough comfortable for answering questions :) 15:28:58 <n0ano> bauzas, we'll find out 15:29:03 <bauzas> sweet 15:29:24 <n0ano> OK, I think we know what we're doing here... 15:29:29 <bauzas> indeed 15:29:32 <n0ano> #topic opens 15:29:37 <bauzas> about aggregates, I saw tianst patch 15:29:40 <n0ano> anyone have anything new 15:29:57 <bauzas> I just advice him to wait for the new helper class 15:30:06 <bauzas> that's it, opens for me 15:30:15 <n0ano> bauzas, send him an email, should be OK 15:30:26 <tianst> bauzas: i am here :) 15:30:41 <n0ano> or talk to him now on IRC :-) 15:30:48 <bauzas> tianst: cool, we just agreed to implement a new helper class instead of basing on ERT 15:30:48 <tianst> some issue on my network:) 15:31:04 <bauzas> tianst: so I was saying that you just wait until I provide this class 15:31:09 <bauzas> shouldn't be so long 15:31:14 <tianst> bauzas: ok, I wiil wait you 15:31:42 <n0ano> as agreed at the meetup, I'm sending an emal to all the PTLs letting know about Gantt and making sure they won't be surprised about it 15:31:44 <bauzas> on opens, I just saw that you n0ano sent an email :) 15:31:51 <bauzas> (stop reading minds !) 15:32:18 <bauzas> we just had Swift's answer \o/ 15:32:25 <Yathi> n0ano: that was a good email you sent today.. 15:32:26 <n0ano> it finally went through? (I had too many CC addresses, it needed manual approval) 15:32:44 <n0ano> Yathi, story of my life, good emails (bad code :-) 15:33:13 <Yathi> we need Cinder PTL to approve the story.. neutron has given us verbal vote already 15:33:13 <bauzas> emailing is more complicated than writing code... 15:33:51 <bauzas> code is logical, email replies are not 15:34:01 <n0ano> Yathi, +1, I think cinder has the closest requirements to Nova so they're a perfect test case 15:34:04 <bauzas> Swift sounds interested in 15:34:08 <Yathi> bauzas: +1 emails that need to influence people to agree with you 15:34:27 <bauzas> provided we clear out what will be Gantt on a Program basis 15:35:14 <n0ano> also, again per the meetup, we need to come up with a rough roadmap for where we want Gantt to go post the split, everyone start thinking about that. 15:35:52 <Yathi> n0ano: make Gantt the smartest thing on earth :) 15:35:54 <bauzas> n0ano: I would love to see some people looking at other projects 15:36:10 <bauzas> n0ano: by "some people", I don't exclude myself 15:36:21 <n0ano> Yathi, I just call that world domination 15:36:37 <bauzas> n0ano: meaning that as other Shared Services projects, we need to know how other projects schedule their own bits 15:36:38 <Yathi> :) 15:36:39 <notmyname> bauzas: it was more of a question than saying we want swift to use it at this point (just to be clear) 15:36:42 <n0ano> bauzas, yes, cross project support is hard but crucial 15:36:54 <bauzas> notmyname: my bad 15:37:10 <bauzas> n0ano: so my question was 15:37:16 <n0ano> notmyname, that's cool, I'm hoping that no one has a violent objection first 15:37:36 <bauzas> n0ano: before doing roadmap and saying what we should do, should we take time to see where we should go ? 15:38:18 <bauzas> by where I mean at least looking at Neutron node and probably Cinder 15:38:22 <n0ano> bauzas, I would say that's part of the process, let's all think about it for now 15:38:24 <bauzas> s/node/code 15:38:47 <Yathi> replacing Cinder scheduler should be easy I hope.. as they use similar constructs 15:39:08 <bauzas> Yathi: indeed, as Cinder just forked 4 or 5 releases ago 15:39:10 <Yathi> but may need efforts similar to what is being done for Nova now 15:39:18 <n0ano> we don't have to have a roadmap immediately, we might not create it until after Paris, but we can start thinking/looking at code now 15:39:26 <bauzas> Yathi: but I'm really unsure that Neutron has a ResourceTracker for example :p 15:39:45 <bauzas> n0ano: that sounds a good plan 15:39:50 <Yathi> bauzas: need to spend time looking at the projects 15:40:01 <bauzas> Yathi: I already did :) 15:40:30 <Yathi> bauzas: awesome!.. also I think we need to watch for the policy related projects.. 15:40:33 <bauzas> anyway, I think we need to take time to think about the abstractions we have 15:40:42 <Yathi> creating quite a buzz everywhere.. including neutron.. 15:40:52 <bauzas> Yathi: Congress sounds a good fit, but it's not yet incubated 15:41:01 <bauzas> (already reviewed Congress too...) 15:41:23 <n0ano> one administrivia, I'm at a conference next week, can I tag you bauzas to run the meeting 15:41:23 <bauzas> and some bits of code are still needing refactoring before that IMHO 15:41:32 <bauzas> n0ano: for sure 15:41:42 <Yathi> bauzas: I have watched Congress too closely.. but inside the nova community there have been several policy related BPs 15:41:43 <bauzas> n0ano: just mail me your thoughts 15:41:47 <Yathi> need to revisit them too 15:42:07 <n0ano> #action bauzas to chair meeting on 8/19 15:42:13 <bauzas> Yathi: my personal opinion is that we need an iterative approach 15:42:25 <Yathi> bauzas: +100 15:42:33 <n0ano> bauzas, no mail needed, we read our minds, remember :-) 15:43:07 <bauzas> n0ano: cool, new discovery in science 15:43:39 <n0ano> OK, silly time, unless someone has somethin substantive 15:44:31 <n0ano> then I'll thank everyone and we'll talk again next week (minus me) 15:44:42 <n0ano> #endmeeting