15:00:36 #startmeeting gantt 15:00:37 Meeting started Tue Dec 16 15:00:36 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:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:41 The meeting name has been set to 'gantt' 15:00:51 anyone here to talk about the scheduler? 15:00:55 \o 15:00:55 * bauzas waves 15:00:58 \o 15:01:08 o/ 15:01:12 bauzas, you always beat me by about 10 seconds :-) 15:01:37 n0ano: eh, my middle name is Tag Heuer 15:02:06 bauzas, mine is `whenever` :-) 15:02:12 anyway, let's start 15:02:20 #topic code clean up status 15:02:23 hi 15:02:42 I saw you had a long IRC converstation with jaypipes , did you work everything out? 15:02:53 by you, whose you're talking ? :) 15:03:05 * bauzas likes long convos with jaypipes 15:03:21 you == bauzas , I think you were talking about the isolate scheduler DB 15:03:25 s/whose/whom (darn French !) 15:03:39 n0ano: oh 15:03:53 bauzas, sorry, s/whom/who (I can be pedantic about grammar too) 15:04:00 n0ano: well, everything is normal, he doesn't like my proposal, I consequently hassled him 15:04:18 n0ano: nah, enough kidding 15:04:44 n0ano: so, my former proposal was about to persist aggregates information in a separate table held by the Scheduler 15:05:11 n0ano: as I had many reviews saying it was a bad idea, I consequently changed my spec to only provide an in-memory update 15:05:37 n0ano: there are still some concerns about how to populate that cache, so I still expect further feedback 15:05:38 * edleafe is glad he didn't update his spec for table persistence 15:05:47 ahh, that was the memory cache you two were talking about, is that in the updated spec I just saw the notic for? 15:05:57 edleafe: hence my comment to wait the aggregate spec to be at least one +2'd ;) 15:06:09 bauzas: exactly :) 15:06:10 n0ano: correct 15:06:20 with the link, it's better 15:06:22 #link https://review.openstack.org/#/c/89893/ 15:06:54 above is the updated spec taking in account all previous comments 15:07:19 so, definitely reviewable but sounds like you expect at least one more update on it 15:07:25 that's not perfect IMHO, as the Scheduler is still calling the Aggregate API once in its lifetime, but that's a good path till we split the scheduler 15:07:43 n0ano: well, you know that the devil is in the details... 15:08:35 anyway, I'm preparing to request an exception for the freeze if we can't make it for Thursday 15:08:50 that's a very old spec and still necessary for the split 15:09:01 bauzas, good plan, i'm guessing we'll need it but we should be close 15:09:19 n0ano: yeah, the main problem is to define how to do this 15:09:43 n0ano: once we agree on the plan for updating the Scheduler view and all the tradeoffs, then we can quickly iterate 15:09:53 bauzas, how can remove the aggregate api calling when we split scheduler? 15:10:21 pull data instead of push data? 15:10:23 alex_xu: well, that's something which can be discussed 15:10:43 alex_xu: I wrote in the alternatives sections that it's possible to persist the dataz 15:10:59 bauzas, ok, I will read it 15:11:03 alex_xu: but it would require a separate nova scheduler service 15:11:35 bauzas, looks like our api is push data, this won't changed 15:11:37 anyway, that actually comes to the fact that we plan to ship first a library 15:12:00 if we consider a library, that doesn't work well with the concept of having its own DB 15:12:28 anyway, I think it's a bit early for discussing this - at least until this 89893 spec merges 15:12:54 ok, think about it later 15:13:01 because that spec is necessary for thinking about how we can ship the scheduler 15:13:04 bauzas, I agree, get the overall design approved and then work out the details 15:13:42 n0ano: so, that's it for this specific BP 15:13:53 cool, tnx 15:13:56 n0ano: that's good we targeted it for K3 anywauy 15:14:14 because it seems it will probably a couple of weeks still to get it merged 15:14:29 looking at our dashboard, https://wiki.openstack.org/wiki/Gantt/kilo#Tasks 15:15:05 the isolate scheduler DB is open but we have line of sight for approval, 15:15:21 jaypipes, his object model spec is the big open 15:15:24 agreed 15:15:30 +1 too 15:15:42 and I have some concerns about what he's planning to do 15:16:04 unfortunately, he doesn't seem to be responding today 15:16:09 I actually required many review iterations to understand what the spec was doing, so that's my bad if I'm giving -1 so late 15:16:37 bauzas, no worries, that's just part of the process 15:17:12 I'm not a logical person, that means I need sometimes more time to understand some concepts :) 15:17:42 I think I'll try and find jaypipes on IRC later and see if we can get an update on his plans for that spec 15:18:32 of course, I'm kind of avoiding the issue that now we have to implement the specs that have been approved 15:18:40 PaulMurray: did you get updates from jaypipes about his spec ? 15:19:08 PaulMurray: I saw you were discussing about it, even by the big G hangout stuff 15:19:56 sounds like we also lost PaulMurray 15:20:16 yep (I've had network issues in the past myself) 15:20:23 netsplit ? 15:20:37 we'll just have to ping jaypipes later 15:20:48 agreed 15:21:17 we've kind of covered the specs let's move on 15:21:22 #topic opens 15:21:37 anything else we want to discuss today? 15:21:56 nothing really for me 15:22:02 nor me 15:22:13 short meeting works for me 15:22:17 \o/ 15:22:19 nothing from me 15:22:35 we still have reviews so let's all do that 15:22:53 sounds like a plan 15:22:56 BTW, I'll be around next week (big holiday coming up I hear) do we still want a meeting next week? 15:23:05 n0ano: oh good point 15:23:16 I'll be around 15:23:16 lemme check the date 15:23:25 but yeah, a lot of people will be off 15:23:27 sounds feasible 15:23:35 Christmas day is Thurs so Tues is fine by me 15:23:55 * n0ano has all his shopping done for the first time ever 15:24:01 I should be off by end of Tues till 5th Jan 15:24:31 bauzas, NP, enjoy, I'll still run a meeting next week, it could be `very` short 15:24:37 n0ano: ack 15:24:47 bauzas, I was pulled into something by my manager - I can update at the end if you like 15:24:56 PaulMurray, go for it 15:25:22 bauzas, ok 15:25:52 I have a discussion with jaypipes about his spec for resource object models 15:26:04 right 15:26:15 The basic point was making sure that two things are covered that were requirements for ERT 15:26:29 1) ability to select resources for different virt drivers 15:26:47 2) making sure it is easy to develop and contribute new resource objects 15:27:07 I also noted a bug in the resource tracker to do with ironic 15:27:18 PaulMurray, good goals, I approve 15:27:31 Ironic uses resources differently to other virt drivers 15:27:45 and that is not accounted for at the moment 15:27:54 PaulMurray: I agree, I had many troubles with Ironic when implement detach-service 15:28:12 so this is an opportunity to make sure those kind of things are easy to deal with in the future 15:28:30 I can find the link for the bug - hold on 15:28:59 https://bugs.launchpad.net/nova/+bug/1402658 15:29:01 Launchpad bug 1402658 in nova "resource tracking is incorrect for ironic" [Undecided,New] 15:29:43 That can be dealt with as a bug fix, but dealing with resources that behave differently should be inherent in the solution 15:29:59 Anyway - Jay is going to do a revision to day I think 15:30:27 PaulMurray: I was also having some concerns about how he's planning to update the stats 15:31:02 PaulMurray: IIUC, he was planning to update the UsageSpec classes, but not the ComputeNode object 15:31:59 bauzas, I got a little lost on that part - I need to get more familiar with the proposed code 15:32:26 bauzas, as long as you indicate that in your review that should make jaypipes address those issues 15:32:39 PaulMurray: I think that's the main problem I had 15:32:50 PaulMurray: I was a little lost of what was the actual plan 15:33:17 but let's jaypipes clarify that in his spec 15:33:18 bauzas, I know that some of it looks confused because it deals with legacy around the ComputeNode object 15:34:00 PaulMurray: my main problem is that there are many set of classes and I was still having some problems with seeing the relationship with the ComputeNode object 15:34:11 bauzas, I'm not sure its done cleanly enough yet, but the path from legacy to being clean is not quite there for me 15:34:21 PaulMurray: agreed 15:34:24 hence my concerns about ease of use 15:34:38 or rather ease of extension 15:34:45 PaulMurray: yeah, I just want to make sure it's quite understandable and readable by most of us 15:34:50 I'm concerned about timing, even with an extension we don't have much time to get this right 15:35:28 n0ano, yes, I said would make myself available to help get it right 15:35:44 PaulMurray, tnx, anything to help 15:35:46 n0ano, it might need a restricted scope and a statement about where it intends to go 15:36:11 n0ano, can't really say much in jaypipes absense 15:36:29 yeah, understood, we'll try and get him later on IRC 15:36:35 agreed 15:36:52 so, unless there's anything else 15:37:33 I'll thank everyone and we'll talk again next week 15:37:40 sure thing 15:37:42 #endmeeting