14:00:15 <edleafe> #startmeeting nova_scheduler
14:00:16 <openstack> Meeting started Mon Jan  9 14:00:15 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:19 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:20 <cdent> o/
14:00:25 <diga> o/
14:00:40 <edleafe> Good UGT morning to you all!
14:01:17 <rfolco> o/
14:01:26 <bauzas> \o
14:02:00 <_gryf> o/
14:02:06 <edleafe> anyone know if jaypipes is around today?
14:02:35 <cdent> he was moving code earlier today
14:02:43 <cdent> (around 5am his time...)
14:03:08 <edleafe> ugh. I don't move my eyelids that early
14:03:33 <cdent> could be he' s got a bit to move his eyelids for him
14:03:47 <cdent> bot
14:03:50 * cdent sighs
14:04:05 <edleafe> Well, let's get started
14:04:13 <edleafe> #topic Specs and Reviews
14:04:35 <edleafe> Getting a list of filtered RPs
14:04:35 <edleafe> #link https://review.openstack.org/#/c/392569/
14:04:43 <edleafe> bauzas?
14:05:04 <bauzas> yup ?
14:05:31 <bauzas> oh, an error
14:05:34 <edleafe> Any news or items to discuss on that?
14:05:54 <bauzas> graaah, it's probably about the previous merge
14:06:01 <bauzas> I mean, the rebase
14:06:11 <edleafe> no, that looked like a CI issue, not yours
14:06:26 <bauzas> FWIW, I had no time to look at the issue
14:06:31 <bauzas> just discovered it
14:06:44 <bauzas> oh yeah
14:06:50 <bauzas> http://logs.openstack.org/69/392569/24/check/gate-nova-python27-db-ubuntu-xenial/f79d32b/console.html#_2017-01-09_09_23_51_578225 :(
14:07:13 <edleafe> Is there anything we can do to help (besides reviews)?
14:07:15 <bauzas> and http://logs.openstack.org/69/392569/24/check/gate-tempest-dsvm-neutron-placement-full-ubuntu-xenial-nv/544860f/console.html#_2017-01-09_09_26_43_279546 :(
14:07:37 <bauzas> edleafe: well, I'll just upload the scheduler patch by today
14:08:10 <edleafe> ok, so no blockers
14:08:24 <edleafe> Next up...
14:08:30 <edleafe> #topic Placement Client
14:08:43 <edleafe> Also bauzas on this one
14:08:59 <edleafe> Anything to discuss?
14:09:13 <bauzas> like I said, I'll provide the change tonight or tomorrow
14:09:36 <bauzas> for the moment, https://review.openstack.org/#/c/417111/4 is WIP
14:09:46 <edleafe> ok, cool - just checking if there were any issues
14:09:47 <cdent> I think part of the topic there is do we need to think about the when/how of a python-placementclient
14:10:01 <bauzas> because I'd like to see us merging first the scheduler change
14:10:03 <cdent> (something I've been mentioned on the rp update emails for a while)
14:10:11 <bauzas> cdent: not really yet
14:10:19 <edleafe> cdent: yes, agreed. Personally, it seems a bit premature
14:10:31 <cdent> I agree with bauzas, though, that we don't need one for the scheduler changes
14:10:33 <bauzas> cdent: I think it could be something for Pike
14:10:38 <bauzas> but not for Ocata
14:10:45 <edleafe> bauzas: +1
14:10:47 <cdent> the thing I think we're ignoring is people wanting to make shared disk providers
14:11:06 <cdent> the specs describe openstack client commands for creating those
14:11:34 <cdent> it's fine if we're putting that off to later, but I think we can be more explicit about it
14:12:22 <edleafe> cdent: I think those specs were more aspirational, to show where we would end up, as opposed to what we commit to for Ocata
14:12:29 <cdent> the relates to the other thing I brought up on that email: needing to pay attention to aggregates when filtering resources
14:14:08 <edleafe> cdent: so... anything to add to the email points?
14:14:21 <cdent> (which I guess is down there in open mmic section of the agenda so we can wait until then)
14:14:50 <edleafe> ah, ok.
14:15:09 <cdent> All I would add is that it would be nice to make sure that we're all on the same page about the end game for ocata, to avoid last minute confusion.
14:15:43 <edleafe> Yeah, let's get into that in Opens
14:15:59 <edleafe> #topic Resource Tracker cleanup series
14:16:02 <edleafe> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/custom-resource-classes
14:16:16 <edleafe> No jaypipes to discuss that
14:16:25 <edleafe> Seems to be moving well
14:16:34 <edleafe> Let's just keep up with reviews
14:17:21 <edleafe> Next up:
14:17:21 <edleafe> #topic Placement Docs
14:17:24 <edleafe> #link https://review.openstack.org/#/c/409340/
14:17:31 <edleafe> cdent?
14:17:45 <cdent> the main sticking point on this is the need to hook it into CI
14:18:03 <cdent> there's plenty of automation in place to deal with projects that have a single directory named 'api-ref'
14:18:13 <cdent> but placement adds a new directory 'placement-api-ref'
14:18:31 <cdent> and as far as I can tell the existing automation is not parameterized
14:18:39 <cdent> so I guess we need to duplicate it
14:18:57 <cdent> I've only have a superficial look though... I find project-config dirs very hard to parse
14:19:10 <cdent> (how x connects to y)
14:19:12 <edleafe> So this is an artifact of the not-yet-split-out status?
14:19:20 <cdent> pretty much
14:19:51 <edleafe> Yeah, I guess that's expected when you pretend that a single project has two separate APIs
14:20:22 <edleafe> OK, let's move on to Bugs
14:20:29 <edleafe> #topic API not returning aggregate UUIDs
14:20:47 <edleafe> The code for that merged over the weekend, so keep moving, nothing to see here...
14:21:07 <edleafe> #topic Allocation bad input handling and dead code fixing
14:21:09 <edleafe> #link https://review.openstack.org/#/c/416751/
14:21:16 <edleafe> That's my series
14:21:32 <edleafe> It's done, if only I could get CI to be happy
14:22:05 <edleafe> So let's move on to...
14:22:09 <edleafe> #topic Opens
14:22:23 <edleafe> Two things that cdent brought up
14:22:41 <edleafe> First, is the 'can_host' field still useful?
14:22:53 <bauzas> folks, I need to disappear as always this winter time :(
14:22:59 <edleafe> That's more of a Jay question, since he thinks it's needed
14:23:00 <bauzas> edleafe: I think so yeah
14:23:05 <edleafe> ok, thanks bauzas
14:23:18 <cdent> If we do need it, then the resource tracker needs to start using it, because I don't think it currently does?
14:23:58 <edleafe> I'm concerned about the special snowflake aspect of it
14:24:17 <edleafe> It's a very compute-centric view of resources
14:24:35 <cdent> me too, I think it is redundant can_host == (VCPU inv > 1)
14:24:52 <edleafe> In my discussions with Jay, having a RP marked as 'shared' would accomplish the same thing
14:25:13 <edleafe> cdent: true, but that's also compute-centric
14:25:14 <cdent> however: the curernt plan for filtering providers is that the list returned is just compute nodes, either because they can host the desired resources or are aggregate associated with this
14:25:30 <cdent> s/this/with something that can
14:25:42 <cdent> thus my assertion that we need a test case to work backwards from
14:25:56 <edleafe> Well, let's save this for a time when Jay is around
14:25:59 <cdent> We realized at the end of last cycle that we were trying to do the real work too late.
14:26:13 <cdent> So I'd like to be sure we get started sooner than later
14:26:24 <edleafe> cdent: excellent point re: test case
14:26:57 <edleafe> We'd need to simulate several compute nodes as well as some shared storage, no?
14:27:19 <cdent> seems so yeah
14:27:29 <cdent> and associate some but not all by aggregation
14:27:43 <edleafe> So that goes to the other point you brought up: filtering on aggregates
14:27:54 <cdent> The fact that I can't articulate what needs to happen in a clean and clear way (to myself or anyone else) is what worries me.
14:28:28 <edleafe> wait - you mean pages of complex SQL isn't clear to you????
14:28:51 <cdent> It's clear that it is incomplete
14:29:40 <cdent> there's jay's email with subject "Some attachments to help with resource providers querying" that he sent out to some of us
14:29:47 <edleafe> So this is an excellent point. Abstract models that aim to be all-encompassing really have a hard time when faced with reality
14:30:11 <edleafe> We need to ensure that the real world is adequately represented
14:30:16 <cdent> yes
14:30:58 <edleafe> So I might have some time in the coming days to start working on a test scenario
14:31:08 <edleafe> If so, I
14:31:11 <edleafe> ugh
14:31:28 <edleafe> If so, I'll try to come up with something that we can bang on
14:31:35 <cdent> If you're inclined, you should be able to fake the whole thing in gabbi: creation of the resources and inventory, setting up the aggregation
14:31:43 <cdent> then you'll see the whole where the filtering is supposed to happen
14:31:57 <cdent> sigh
14:31:59 <cdent> hole!
14:32:09 <edleafe> OK, that will give me a chance to get more intimate with gabbi :)
14:33:02 <edleafe> So... anyone have anything else for Open Discussion?
14:33:05 <_gryf> yeah, just a heads up. I've started to work on BP for providing distinctive messages for errors (especially on 409 errors) for placement API. I'll push it soon.
14:33:32 <cdent> aw crap, I saw that earlier in last week I meant to include it in the email _gryf
14:33:33 <_gryf> it's targeted to pike, and I've already was pointed to the right direction by cdent
14:33:40 <diga> Hi All, I am working on https://blueprints.launchpad.net/nova/+spec/placement-notifications BP
14:33:42 <edleafe> distinctive in what way?
14:34:10 <diga> I had chat with gibi on notification & suggested me to submit the spec for this BP
14:34:16 <edleafe> #link https://blueprints.launchpad.net/nova/+spec/placement-notifications
14:34:18 <_gryf> edleafe, to provide a json in the payload in response
14:34:39 <_gryf> with details what was wrong
14:34:54 <edleafe> Details are always nice :)
14:35:13 <_gryf> yeah…
14:35:16 <diga> edleafe: I will submit on WIF PS by today EOD
14:35:21 <cdent> I think the key aspect of the 409 distinction stuff is the use of an internal code
14:35:40 <cdent> as defined by the api-wg errors guideline
14:35:59 <edleafe> diga: cool. Be sure to add that link to the agenda next week if you want more feedback
14:36:00 <cdent> diga: were you able to figure out all the stuff about versioned notifications okay?
14:36:08 <_gryf> edleafe, yup
14:36:10 <diga> edleafe: Sure
14:36:34 <rfolco> I have started investigating the issue on earlier microversions returning 404 instead of 405, does this overlaps with some of the above ?
14:36:42 <diga> cdent: yeah, going through all the details. gibi has suggested some docs to go through first
14:37:17 <diga> cdent: I still need to go through versioned object, will go through it today
14:37:26 <edleafe> rfolco: that depends on the microversion change, right?
14:37:39 <diga> cdent: placement-api service working with devstack in my setup :)
14:38:00 <cdent> rfolco: as far as I know the 404 when it should be 405 is probably only present on your DELETE inventories change and despite what I said on that review, the proper fix is probably to be explicit in your handler instead of using the version_handler decorator
14:38:02 <edleafe> You're adding a new method to a resource
14:38:38 <cdent> the decorator doesn't have access to the Route map, so it is a bit complicate for it to choose between 404 and 405.
14:38:42 <rfolco> oh I see, I thought that return code would apply for any previous microversion method
14:39:15 <edleafe> rfolco: if you expose a new resource via a microversion, earlier versions should return 404
14:39:43 <rfolco> I thought it should return NotAllowed instead
14:39:56 <rfolco> ok, would align this with cdent later
14:39:56 <cdent> 405 on new method on existing resource
14:40:03 <cdent> 404 on entirely new resource
14:40:24 <edleafe> exactly. For earlier versions, that resource didn't exist
14:40:26 <cdent> rfolco: yeah, find me and we can talk about it more if needed
14:41:19 <rfolco> cdent, deal
14:41:26 <edleafe> Anything else for Opens?
14:41:46 <edleafe> Or can I go make another batch of coffee?
14:42:05 <edleafe> Oh, one more thing!
14:42:09 <cdent> but wait
14:42:10 <cdent> there's more
14:42:16 <edleafe> I'll be away next week
14:42:21 <edleafe> cdent: can you run the meeting?
14:42:26 <cdent> yup
14:42:35 <edleafe> ok, thanks
14:42:56 <edleafe> I think that's everything... (fingers crossed)
14:43:04 <cdent> I'm going to change everything so we aren't persisting resource tracking
14:43:25 <edleafe> cdent: cool. Will that be ready later today?
14:43:40 <cdent> DHT over IPFS for global resource state
14:43:46 <cdent> in about 5 minutes
14:43:58 <edleafe> should be a no-brainer
14:44:02 <cdent> totes
14:44:09 <edleafe> OK, thanks everyone!
14:44:12 <edleafe> #endmeeting