15:00:48 #startmeeting nova_scheduler 15:00:48 Meeting started Tue Jun 23 15:00:48 2015 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:52 The meeting name has been set to 'nova_scheduler' 15:01:05 morning folks 15:01:16 (or pick the one you are) 15:01:34 good $time_of_day to you 15:02:13 we should just adopt UGT: http://www.total-knowledge.com/~ilya/mips/ugt.html 15:02:17 waiting the crowd 15:02:46 edleafe: interesting :) 15:02:57 alex_xu_ won't be on - he has a new daughter today 15:03:01 \o/ 15:04:08 we're going to have a long wait if you want a crowd :) 15:04:44 edleafe: well, I should say that Justin Bieber is there 15:05:07 o/ 15:05:10 then I'm outta here 15:05:35 edleafe: do you prefer then ? 15:05:50 much better 15:05:57 (btw. this nick is registered. so awesome) 15:06:06 I couldn't get xi :( 15:06:21 okay enough kidding, we're 3 15:06:51 hello everyone 15:06:58 nihilifer: hi 15:07:04 so, let's start then 15:07:12 #topic Specs process 15:07:34 so, we agreed on putting our review requests in https://etherpad.openstack.org/p/liberty-nova-priorities-tracking 15:07:53 I just stroked the specs which were merged 15:08:24 so, we're in a good shape for working 15:08:54 at least the two main ones (request-spec-object and resource-objects) are approved for Liberty, thanks to jaypipes and lxsli 15:09:26 Still waiting on NoValidHost reporting 15:09:27 so, there are 2 specs requests waiting for approval 15:09:40 https://review.openstack.org/187739 15:09:41 seems like people wanted it to solve every problem instead of just one :) 15:09:53 edleafe: yeah, I saw that 15:10:25 edleafe: I'm going to do another pass by today if I can, so if I'm happy, I could put that one as "given +1 from the subteam" 15:10:45 edleafe: to be clear, I would like to see that spec worked for Liberty 15:10:52 edleafe: My preferred response to such is "that's a great idea you are welcome to propose in a follow-on spec" 15:11:09 bauzas: that actually happened 15:11:09 edleafe: I think you scoped the spec correctly 15:11:27 https://review.openstack.org/194204 15:11:32 * jaypipes on a hangout... 15:11:52 edleafe: I was having some concerns about the scalability on that, so I need a few more time for thinking about that 15:12:19 bauzas: Sure - it went through several scenarios before I settled on this one 15:12:22 edleafe: I got your reply on the IO concern, I'm now still a little concerned about the memory usage 15:12:27 bauzas: most were highly un-scalable 15:12:52 edleafe: agreed, hence why I need some time to review your spec - because I don't want to argue against something previously having a consensus 15:12:55 bauzas: exactly. To reduce memory, I'd have to log every step 15:13:11 bauzas: then that would clutter the logs uselessly 15:13:15 edleafe: okay, lemme give some time to think about it 15:13:29 of course 15:13:34 edleafe: the real question behind that is "does that honestly need a spec ?' 15:14:00 Well, since there are concerns about the effect of the implementation, I'd say 'yes' 15:14:07 edleafe: you're not changing the APIs (neither REST or RPC), you're not persisting something, you're not adding something in a dict etc. 15:14:42 edleafe: okay, I would propose you to put the BP as questionable for the next nova meeting if it deserves a spec 15:15:03 edleafe: because I've seen more controversial BPs getting approved without a spec 15:15:13 bauzas: yeah, I got no feedback on the BP itself 15:15:16 edleafe: I mean, we can still argue about the implementation 15:15:23 so I wrote the spec 15:15:38 edleafe: and discuss on technical details, but that can be done directly in the implementation 15:15:56 edleafe: having no specs doesn't necessarly mean it's trivial :) 15:16:04 well, part of the idea of a spec is to argue *before* time is spent on an implementation 15:16:34 edleafe: agreed, but like I said, I can see a general consensus on the design while some discussion happens on the implementatioon 15:16:53 edleafe: I mean, I saw nobody complaining about logging stuff - rather about detailsd 15:17:12 bauzas: yeah, it's not a clearly defined border between "needs spec" and "no spec required" 15:17:14 edleafe: so maybe it would be worth asking the question in a nova mereting 15:17:19 about the "does that honestly need a spec?" question 15:17:35 edleafe: because we do have a topic for that 15:17:43 some time ago I "resurrected" an old spec, not approved for Juno 15:17:48 edleafe: https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 15:18:05 nihilifer: yup ? 15:18:13 https://review.openstack.org/#/c/181054/ 15:18:24 I had some doubts whether it needs spec or not 15:18:29 since it's a filter 15:18:40 but it also requires new conf option 15:18:45 nihilifer: see my last comment :) 15:18:56 oh, it's you :) 15:19:07 that's what I wanted to ask about 15:19:22 nihilifer: so, there are some examples 15:20:12 nihilifer: see http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#when-is-a-blueprint-needed 15:20:24 nihilifer: given your proposal, I can see it as a self-contained change 15:21:15 bauzas: ok, then I will just begin work on it 15:21:30 bauzas: thanks for clarification 15:21:44 nihilifer: the same as for edleafe, I would recommend you to officially ask in https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 15:22:02 nihilifer: but I'm clearly pro-BP only 15:22:21 nihilifer: in case of a needed spec, just resurrect it 15:22:35 my 2p is I'd like a "trivial specs" process, so in cases like this where someone has taken the trouble to write a spec, we can fast-track it rather than abandoning the spec 15:22:37 bauzas: I prefer the spec discussions myself 15:22:43 nihilifer: hence the formal question 'do I need a spec' during the nova meeting 15:22:48 that's not really a subject for the scheduler meeting though 15:23:17 lxsli: my idea on that is that we can't hardly assume the current spec backlog 15:23:44 lxsli: so, we probably indeed need some way to ask for drafting out a design doc if needed 15:23:50 but only if needed 15:23:57 bauzas: things "too simple to need a spec" naturally make for easy, quick spec reviews though, no? 15:23:59 edleafe: see the examples on the link I provided 15:24:12 bauzas: and this process may reveal it wasn't quite as simple as was initially thought 15:24:20 edleafe: there are 2 examples of filters changes not requiring a sepc 15:24:37 bauzas: agreed 15:24:38 lxsli: agreed, that's an on-going improvment process 15:24:47 I may be biased because I find writing in English quite easy ^^; 15:25:17 lxsli: so I will officially ask johnthetubaguy to ask for specs written in French only 15:25:20 enough kidding 15:25:49 last spec is https://review.openstack.org/#/c/179224/ 15:25:51 #link https://review.openstack.org/#/c/179224/ 15:26:05 still needs some approval, because there is a REST API change 15:26:15 (plus a behavioural change) 15:26:38 so I chatted with jaypipes, let's see if he will obviously kill my idea or support it :) 15:27:04 any specs to mention before we move on ? 15:27:05 doesn't seem obviously crazy 15:27:10 yes 15:27:23 https://review.openstack.org/#/c/84906 15:27:32 lxsli: feel free to review the spec, I could mark it as 'given +1 from a subteam member' accordingly :) 15:27:34 lxsli: emphasis on 'obviously' :) 15:27:37 this got merged for Juno but afaik nothing has happened with it 15:28:00 bauzas: dansmith assigned me a tonne of work to do with no-more-soft-delete, I've been wading through that :( 15:28:14 lxsli: no excuses, you gotta review ! 15:28:16 lxsli: assigned? :P 15:28:23 lxsli: it's much appreciated though 15:28:24 dansmith: suggested ^^ 15:28:34 lxsli: don't you work 24x7 ? 15:28:52 I am strenuously avoiding that! 15:29:00 anyway, so back to 84906 15:29:28 lxsli: that spec would require a refresh for Liberty anyway, so there are litterally very little chances we could work on it for this cycle 15:29:39 yeah, does it seem plausible for Mita ? 15:29:48 lxsli: also, I think some work has to be done before that one 15:30:08 lxsli: don't say the name :p 15:30:23 lxsli: so, even Muppet, I dunno 15:30:24 Sorry, Muppet :) 15:31:01 lxsli: ndipanov is planning to work on something about claims within the scheduler, and also fix the missing gaps with claims for Libertyy 15:31:15 lxsli: sec, giving you the specs 15:31:22 bauzas: awesome, thanks 15:31:31 lxsli: so I would definitely prefer ndipanov's work be done before we persist those 15:31:48 lxsli: and honestly, I would also prefer resource-objects to be landed *before* that 15:31:54 bauzas: that's cool, just getting a sense of where we are 15:31:59 yep definitely 15:32:09 I still need to look at John's scheduler-evolution thing :( 15:32:13 lxsli: so the specs are 15:32:14 https://review.openstack.org/#/c/191226 15:32:31 https://review.openstack.org/#/c/193576/ 15:32:41 lxsli: I still need to provide an update too 15:32:49 lxsli: I basically promised it to johnthetubaguy 15:32:59 bauzas: also https://review.openstack.org/187739 15:33:37 edleafe: your point on that one? thought we discussed about it before ? 15:34:01 bauzas: I thought you were listing outstanding specs needing review 15:34:02 edleafe: that's a no-valid-host spec, did you paste the wrong one? 15:34:03 edleafe: oh, you mean the specs being worked for Liberty ? yeah, we're tracking them 15:34:37 edleafe: no worries, I'm trying to keep the etherpad of doom up-to-date 15:34:44 ok, moving on ? 15:35:07 1 15:35:08 2 15:35:10 ... 15:35:11 3 ? 15:35:18 #topic Open discussion 15:35:39 oh sec 15:35:40 #undo 15:35:41 Removing item from minutes: 15:36:10 #topic new meeting time 15:36:18 edleafe: you had an action for this 15:36:40 jaypipes said that Monday might be a little better than Tue-Wed 15:37:01 I'm wondering if it's worth doing another Doodle to see if that would work for everyone 15:37:04 persist what bauzas ? 15:37:30 edleafe: fair 15:37:34 edleafe: Monday is fine for me 15:37:55 ok, then I'll send out the doodle message later today 15:38:15 #action edleafe to create Doodle for Monday meeting options 15:38:16 ndipanov: https://review.openstack.org/#/c/84906 given by lxsli 15:38:23 #action edleafe to create Doodle for Monday meeting options 15:38:49 ok, moving on 15:38:53 #topic open discussion 15:39:19 I have nothing to say but that I'm incrementally updating the request-spec-object BP 15:39:37 reviews are welcome if you're fed up by reviewing specs 15:39:40 hey guys may i have 1 more request for review... 15:39:42 https://review.openstack.org/#/c/193635 15:39:54 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/request-spec-object,n,z 15:40:50 xyhuang: strange, I thought I said it needs a spec 15:41:09 xyhuang: because it changes the interface between nova and the scheduler 15:41:37 thanks bauzas, will do a spec 15:42:00 xyhuang: that's MHO, probably someone could say something else 15:42:18 +1 to spec 15:42:20 bauzas: I would tend to agree 15:42:58 xyhuang: that said, I wrote a spec for amending the future RequestSpec object by passing a destination host, so yeah I would love a spec still 15:43:14 xyhuang: do you know about http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/request-spec-object.html ? 15:43:38 bauzas: yes 15:43:48 xyhuang: have you seen this? https://review.openstack.org/#/c/184534/ 15:44:11 oh probably no... 15:44:25 xyhuang: I've only just seen your patch but it may make sense to provide the network info as resource objects 15:44:50 lxsli: hence a spec, because I wonder if that's a compute resource or a request information 15:45:00 xyhuang: there's already an implementation patch, for reference: https://review.openstack.org/#/c/128992/ 15:45:02 lxsli: if we claim about it, then you're right 15:45:38 lxsli: thanks will check it out 15:45:45 xyhuang: very welcome :) 15:46:11 xyhuang: so yes, I think you should consider how to provide that information/resource to the scheduler 15:46:23 hence the specd 15:46:24 spec 15:46:33 i see 15:46:39 so a spec will be done 15:46:45 xyhuang: that said, do you know that there is a spec freeze deadline by Thur ? 15:47:10 not aware of that, but will do it asap 15:47:39 xyhuang: as you would probably require either resource-objects or request-spec-object to be implemented, I think it's difficult to merge the implementation by Liberty but rather the M cycle 15:48:20 Yes I agree - it's very unlikely it can be done in L 15:49:10 would it be possible to add it based on the current arch of request-spec? as this may be a small change 15:49:42 xyhuang: that's the design discussion which needs to be done 15:50:06 xyhuang: I mean, is it something that nova-compute is reporting to the scheduler, or is that only a hint given by the user ? 15:50:13 xyhuang: we want to be more strict about what can be in request-spec to aid Nova back-compatibility and stability 15:50:53 ok 15:51:08 xyhuang: so adding extra stuff to it will make that more difficult, I expect core team will prefer to wait until it's tidier 15:51:43 ok i see, anyway i will write up the spec and we can discuss later in more details maybe 15:51:51 xyhuang: cool 15:52:24 thanks 15:52:59 okay, any other question/concern before we call that meeting done ? 15:53:18 nope 15:53:25 at least not from me :) 15:54:12 we seem to have moved to #nova anyway :) 15:55:06 lxsli: we never left :) 15:55:41 I'm still there 15:55:57 okay, saying bye bye to the meeting ? 15:56:01 #endmeeting