14:00:11 <edleafe> #startmeeting nova_scheduler 14:00:12 <openstack> Meeting started Mon Jun 26 14:00:11 2017 UTC and is due to finish in 60 minutes. The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:15 <openstack> The meeting name has been set to 'nova_scheduler' 14:00:20 <edleafe> Who's here today? 14:00:22 <dtantsur> o/ 14:00:23 <alex_xu> o/ 14:01:25 <jaypipes> hola 14:01:59 <edleafe> Pretty empty this morning - everyone can stretch out! 14:02:17 <edleafe> #topic Specs & Reviews 14:02:35 * alex_xu lay down on the ground 14:02:35 * jaypipes currently rebasing the placement-allocation-requests series 14:02:44 <jaypipes> running tests... 14:02:44 <edleafe> I was out Friday, so I'm not as up-to-date on the status of many of these patches 14:03:20 <edleafe> #link Allocation Candidates https://review.openstack.org/#/c/475448/ 14:03:36 <edleafe> jaypipes: should be ready for review in a little while? 14:03:59 <jaypipes> edleafe: yup. 15 minutes. 14:04:15 <edleafe> kewl 14:04:24 <edleafe> #link Nested Resources: series starting with https://review.openstack.org/#/c/415920/ 14:04:33 <edleafe> Looks like there was some action on this 14:04:49 * bauzas waves 14:05:29 * edleafe waves back 14:05:44 <bauzas> yeah, I can review the nested RP series, but I thought it was needing allocation candidates series to be merged first? 14:05:54 <bauzas> of course, we can merge some of the changes 14:06:11 <bauzas> at least the ones related to the caching object in the compute service 14:06:55 <edleafe> sure, but reviews to catch mistakes or clarify what the code is doing is always useful 14:07:34 <jaypipes> bauzas, edleafe: nested resource providers needs to come after allocation requests, yes. 14:07:45 <jaypipes> I've been delaying rebasing the n-r-p series. 14:08:11 <alex_xu> so the goal in the release is allocation requets? 14:08:15 <jaypipes> https://review.openstack.org/#/c/469147/ is a standalone change that would be great to merge. 14:08:48 <jaypipes> alex_xu: no, the goal is allocation requests, placement claims, shared providers, traits and then nested providers if we get to them. 14:08:57 <edleafe> Heh, that was next up 14:08:58 <edleafe> #link Delete all inventory: https://review.openstack.org/#/c/460147/ 14:09:16 <alex_xu> jaypipes: ok...only one month left 14:09:22 <edleafe> oh wait - that's different 14:09:37 <edleafe> oh wait - that's different 14:09:40 <edleafe> doh! 14:09:48 <jaypipes> alex_xu: yes, I know... 14:10:01 <edleafe> #link Add UUID field to PciDevice Object https://review.openstack.org/#/c/469147/ 14:11:33 <bauzas> jaypipes: added to my review queue ^ 14:11:39 <jaypipes> merci 14:12:16 <edleafe> The last link I have on the agenda is 14:12:18 <edleafe> #link Placement API ref docs: https://review.openstack.org/#/q/topic:cd/placement-api-ref+status:open 14:12:40 <edleafe> Anyone have any other specs or reviews to discuss? 14:12:58 <alex_xu> I have question about why we put resource-class into extra spec 14:13:48 <edleafe> alex_xu: where else could we put it? 14:13:49 <alex_xu> sounds like new functionality add to the API without Microversion, also think about what I can do for request traits 14:14:22 <edleafe> AFAIK, extra_specs is not versioned 14:14:42 <alex_xu> #link request traits in Nova https://review.openstack.org/#/c/468797/ 14:14:57 <edleafe> And it's not part of the defined API. It's part of the Flavor object 14:16:06 <alex_xu> yea, I guess one of extra_specs problems is not versioned 14:16:21 <edleafe> Also, a flavor is not supposed to change 14:16:53 <edleafe> If you associate a trait like SSD with a an existing flavor, now you get something different 14:17:10 <edleafe> even though you are requesting the same flavor 14:17:44 <alex_xu> but the user have no way to know the current nova deployment whether support traits or not without microversion 14:17:44 <edleafe> alex_xu: I hate flavors, but until we can totally re-work them, we're stuck 14:18:01 <bauzas> I thought we agreed on that a couple of releases earlier :) 14:18:22 <edleafe> what do you mean about a user needing to know about traits? 14:18:26 <alex_xu> bauzas: yea, I try to know the orignal reason which I missed... 14:19:01 <bauzas> there are 3 ways to inject quantitative or qualitative requests 14:19:07 <edleafe> alex_xu: the use case we're trying to handle is requesting an Ironic machine 14:19:10 <bauzas> 1/ is the image, which is user-based 14:19:23 <bauzas> 2/ is using hints, which is user-based and per instance 14:19:35 <bauzas> 3/ is using flavor, which is admin-based 14:20:09 <alex_xu> bauzas: sorry, actually my question is why we add an new attributes to the flavor instead of extra specs 14:20:15 <bauzas> since admins manage their capacity, it's understandable for them to propose flavors that can match their clouds 14:20:19 <alex_xu> s/why/why no/ 14:20:28 <alex_xu> ...s/why no/why not/.. 14:20:39 <bauzas> alex_xu: why we use extra specs instead of Flavor attributes ? 14:21:13 <bauzas> because of the interoperability between clouds, I'd say 14:21:55 <alex_xu> bauzas: this spec add resource class into the extra spec http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html 14:22:28 <edleafe> alex_xu: yes, that's the spec I was working from 14:22:30 <bauzas> I don't disagree with that 14:22:52 <alex_xu> so...that won't be a interoperability problem? 14:23:15 <bauzas> I'm really sorry, I'm not sure I'm getting your concern with the above spec 14:23:59 <edleafe> alex_xu: I don't think anyone *likes* doing it this way. It's just the least terrible way, given what we have to work with 14:24:01 <alex_xu> ah sorry, my question is that why we didn't add new attributes like flavor.resources in the API instead of adding resources into the extra spec in that proposal. 14:24:44 <edleafe> alex_xu: see the 'Alternatives' section of that spec 14:25:42 <alex_xu> oh... 14:28:03 <alex_xu> looks like is for ironic transion 14:29:13 <edleafe> alex_xu: yeah, if we can get Ironic working with placement this cycle, that's a big win 14:30:37 <alex_xu> ok, I guess in longterm, we want to get those out of flavor 14:31:04 <edleafe> long term we want to burn flavors to the ground 14:32:02 <alex_xu> still sounds we add new feature to the API without microversion. or we would say that is feature we didn't support offically... 14:33:22 <edleafe> Well, it's not an API change; it's a flavor change 14:33:42 <alex_xu> ok 14:34:46 <edleafe> Well, it seems like we've already been here, so let's make it official 14:34:49 <edleafe> #topic Open discussion 14:35:04 <edleafe> Anything else to discuss? 14:36:45 <edleafe> Going once... 14:36:56 <bauzas> save me time for homeworking with my daughter :) 14:37:05 <edleafe> :) 14:37:11 <edleafe> Going twice... 14:37:25 <edleafe> #endmeeting