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