14:00:15 #startmeeting nova_scheduler 14:00:16 Meeting started Mon Oct 17 14:00:15 2016 UTC and is due to finish in 60 minutes. The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:19 The meeting name has been set to 'nova_scheduler' 14:00:26 Anyone around today? 14:00:27 <_gryf> o/ 14:00:28 \o 14:00:29 o/ 14:01:01 jaypipes is on holiday in Barcelona, so he won't be joining us 14:02:34 Well, let's get started. This should be a quick meeting 14:02:36 #topic Specs & Reviews 14:02:51 First up: laski's policy changes for placement 14:02:51 #link https://review.openstack.org/#/c/382640/ 14:03:37 Doesn't seem like laski is around now 14:03:40 cdent I put that up as a reminder that it is there and because there are some questions about code location 14:03:48 Has everyone had a chance to look that over? 14:04:02 * cdent experiences tab failure 14:04:09 Or, more to the point, does anyone have anything about that to discuss now? 14:04:19 * edleafe is sure it will be a topic at the Summit 14:04:43 the code that checks the policy enforcement is in the existing nova policy file, I thought perhaps extracting to the placement hierarchy might ease extraction later 14:05:00 and if not, we may as well just merge it 14:06:00 cdent: policy for placement? 14:06:48 sorry, not clear, I meant policy.py file, not the json config file 14:07:03 cdent: ah, ok. 14:07:23 the implementation is nice: it actually requires no config file at the moment 14:07:42 I'll have to look that part over in more depth, but first impression is that it should be in placement 14:08:16 IN any case, we can discuss on the review 14:08:19 Next up: aggregates 14:08:19 #link https://review.openstack.org/#/c/362863/ 14:08:35 Lots of +1s 14:08:52 ditto, just a reminder, look at those three patches, not merging is blocking some neutron progress on starting to use resource providers 14:09:30 cdent: good point. We should probably poke the cores in -nova 14:10:16 Let's move on 14:10:17 #topic Opens 14:10:26 optional placement db 14:10:26 #link https://etherpad.openstack.org/p/placement-optional-db-spec 14:10:59 this is also from me (I think they all are). I was hoping to encourage jaypipes, dansmith and bauzas to fill out the long term vision section 14:11:22 or make some kind of declaration on if we are even going to do anything 14:11:24 yeah, maybe that could wait for the placement session next week ? :) 14:11:28 * dansmith puts it in the tab queue again 14:12:06 Well, it would be helpful to have the *current* understanding documented so our discussion is starting from a known point 14:12:17 bauzas: even if we talk about it next week we still need a coherent plan written and agreed, or we'll repeat the chaos we've been having 14:12:22 edleafe++ 14:12:33 As opposed to the midcycle, where there were many different understandings 14:13:46 #action jaypipes dansmith bauzas to write down the current long-term objective in https://etherpad.openstack.org/p/placement-optional-db-spec prior to Summit 14:14:08 Next up: placement leftovers 14:14:08 #link https://etherpad.openstack.org/p/placement-newton-leftovers 14:14:32 Thanks to cdent for that nice pumpkin spice summary 14:15:16 That might be a good place to start on prioritizing the work after the summit 14:15:23 s/after/at 14:15:54 Next up: Any last-minute discussions before Barcelona 14:16:10 I am in the process of writing up my thoughts on the current nested RP design 14:16:17 I was going to ask about that 14:16:28 in case you missed it, I think we're going down the wrong track here 14:16:44 but I can't fully explain it in IRC-sized chunks 14:16:51 so I'm writing it up in a blog. 14:17:08 I'll post that link when it's ready 14:17:16 Any other items to discuss? 14:17:20 <_gryf> i have a quick question regarding custom resources 14:17:24 sure 14:18:00 <_gryf> will be possible with it to define something like block device which can be passed to the vm? 14:18:17 <_gryf> qemu seems to support attaching physical devices 14:18:42 _gryf: in nova? As opposed to doing that through Cinder? 14:18:51 <_gryf> right 14:19:11 I don't think there would be a lot of support for nova duplicating cinder functionality 14:19:18 <_gryf> actually 14:19:29 <_gryf> it is not a volume attachement 14:19:43 But the eventual goal of a separate placement engine is to allow Cinder and other services to use it for their placement decisions 14:19:48 <_gryf> it is rather passing down raw device to the vm 14:20:32 _gryf: where are these raw devices coming from? IOW, what would the Resource Provider be? 14:20:50 <_gryf> edleafe, the host, I think 14:21:23 <_gryf> which can expose some of it's hdd as a resources 14:21:37 <_gryf> of course they shouldn't be mounted 14:22:20 _gryf: I think you should ask about that in the -nova channel. It sounds like something that must have already been considered 14:22:34 <_gryf> yeah 14:22:38 <_gryf> it's just an idea 14:23:02 <_gryf> certain operators asked me if it is possible 14:23:09 You'd have to explain the use case to help others understand 14:23:14 _gryf: there's nothing preventing resource providers tracking that stuff if someone wants to manage them, but being able to use it in decisions or booting or whatever is another thing entirely 14:23:31 <_gryf> due to client needs for high performance storage 14:24:17 <_gryf> cdent, yeah, I'd rather thinkl of such resources as additional one for images/volumes than a primary device 14:24:28 Alright - anything else? Or are we done? 14:24:43 we seem done 14:24:47 <_gryf> yup 14:24:47 A reminder: no meeting for the next two weeks due to summit/travel 14:24:57 <_gryf> right. see you there 14:25:24 Yes, looking forward to arguing^H^H^H discussing with all of you in Barcelona! 14:25:27 ++ 14:25:27 :) 14:25:29 <_gryf> :) 14:25:46 #endmeeting