14:00:28 #startmeeting nova-scheduler 14:00:34 Meeting started Mon Aug 24 14:00:28 2015 UTC and is due to finish in 60 minutes. The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:38 The meeting name has been set to 'nova_scheduler' 14:00:50 o/ 14:00:53 anyone here to talk about the scheduler? 14:02:15 * johnthetubaguy lurks 14:02:20 bauzas, was on #nova, I don't see jay though 14:03:25 \o 14:03:38 * bauzas is still a bit jetlagged 14:03:47 lxsli, is the only other regular missing 14:03:57 let's get started anyway 14:04:10 #topic liberty patches 14:04:25 sooo 14:04:35 bauzas, I see you got jenkins happy with your API patch, are you all done now :-) 14:04:49 API patch ? :) 14:04:56 n0ano: you mean https://review.openstack.org/145528 ? 14:05:11 https://review.openstack.org/199205 14:05:47 n0ano: ah that 14:06:26 n0ano: well, the whole chain is done - some stuff still needs to be done on the conductor side, but all the interfaces should ideally be merged by Lib 14:07:00 that's very good, now all we need is to review everything 14:07:11 n0ano: I mean that some helpers can go to hell, but that can be done in Mitaka, since all the APIs would be now using a Spec object 14:07:22 n0ano: yeah, that's the plan 14:07:40 the first one was good enough for alaski and dansmith :) 14:07:53 excellent 14:08:05 I also have a 2nd series https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/allocation-ratio-to-resource-tracker,n,z 14:08:22 which is nearly done, just needing the RT update to DB 14:08:34 and the Scheduler addition 14:08:39 is that on the priorities page, I don't see it 14:08:45 n0ano: nope, not yet 14:08:47 oh 14:08:48 sec 14:09:13 n0ano: it is 14:09:21 https://etherpad.openstack.org/p/liberty-nova-priorities-tracking L57 14:10:02 ah, I see it now, so is that your top priority patch series now? 14:10:15 my top prio is the Spec objectification 14:10:25 that's my 2nd top prio :) 14:10:48 I mean, it's not really useful for cleaning the APIs, but that's also good enough for the scheduler 14:11:12 so, my status here, ready for the review limbo dance of rebasing 14:11:39 the priority going to the Spec stuff, but I'd be happy to see https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/allocation-ratio-to-resource-tracker,n,z merged too 14:11:41 that's actually very cool, frustrating for you but at least the implementation is done 14:12:00 n0ano: well, I'm not frustrated, I have very good feedback 14:12:44 n0ano: it just takes time to agree on some particular bits, in particular when you review a NovaObject because of the fields 14:12:46 I would imagine the rebase feedback loop could get tiresome but, it you're happy with that, great :-) 14:13:01 n0ano: well, it's a matter of getting things done 14:13:15 n0ano: changing a field or removing it is just painful when the code is merged 14:13:28 n0ano: because you can't just pretend it never existed 14:13:39 indeed 14:14:00 so we had some good talks about using a Flavor object or not 14:14:06 that was necessary 14:14:17 (I mean the convo was necessary) 14:14:53 who's we and did you reach a conclusion? 14:14:59 and the consensus was to leave the Flavor object because of silly filters using it, and then work later on changing those filters to not keep that Flavor object which is painful 14:15:21 who: alaski, dansmith and I 14:15:29 n0ano: we want to eventually limit flavors to the API layer only 14:15:58 n0ano: I was btw. a bit surprised to see a spec of you, made in June :p 14:15:59 I wanted to have a session at Mitaka about that but it looks like maybe we've resolved the issue already 14:16:26 bauzas, it got delayed and i was intending to retry it for Mitaka 14:16:32 I don't want a flavor on the spec object, but for now it's mostly an implementation detail and the individual components are exposed on the object as well 14:16:53 so, the most boring stuff was https://github.com/openstack/nova/blob/master/nova/scheduler/filters/type_filter.py#L35 14:17:40 or even https://github.com/openstack/nova/blob/master/nova/scheduler/filters/type_filter.py#L58 14:19:11 that's an interesting filter, do people really use that? 14:20:07 n0ano: well, that's a good question, but since it's shipped, we have to keep at least a compatibility 14:20:23 I mean a compatible behaviour 14:20:34 if every there was a filter ripe for deprecation I think that would be it 14:20:55 yeah, we haven't yet deprecated a filter 14:21:05 and that would be an interesting talk 14:21:13 I have 3 of those in my target 14:21:27 ComputeFilter, TrustedFilter and those flavor filters 14:21:49 but those flavor filters are by far less silly than the 2 above I mentioned 14:22:23 potentially an interesting session in Tokyo 14:22:29 so, we can leave a room for a discussion about any deprecation rules in Mitaka, would be glad to kick that off 14:22:56 well, maybe not a session, but surely a bullet point in the sched area 14:23:05 bauzas, +1 14:23:20 moving on ? 14:23:25 WFM 14:23:33 anything else on patches? 14:23:38 I don't have any status for jay 14:23:53 I know that he had made good stuff with the pci broken things 14:23:59 I'm mostly reviewing 14:24:08 sounds good 14:24:09 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:pci-cleanup,n,z 14:24:22 in that case 14:24:27 #topic opens 14:24:34 anything new for today? 14:24:39 which is a prereq for https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:resource-objects,n,z 14:25:01 so, yeah, folks have plenty of changes to reviews 14:25:46 so, opens ? 14:25:59 that's the topic, not hearing anything 14:26:25 nothing from me 14:26:55 OK, then time to do our reviews (unless you're me which means it's time for my next meeting :-( 14:27:13 tnx everyone, we'll talk next week. 14:27:13 fair enough 14:27:22 #endmeeting