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