| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 17:25:48 | dansmith | jaypipes: so what you're saying is, you have low standards in general, right? | |
| 17:26:09 | jaypipes | dansmith: you're awfully ornery today. | |
| 17:33:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: xenapi: avoid unnecessary BDM query when building device metadata https://review.openstack.org/481162 | |
| 17:34:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: [placement] Improve allocation_candidates coverage https://review.openstack.org/481153 | |
| 17:34:50 | mriedem | there you go | |
| 17:49:09 | dansmith | mriedem: thanks now I can sleep tonight | |
| 17:51:23 | mriedem | just fyi, i lost all kinds of sleep last night over that task_state thing we talked about | |
| 17:51:54 | dansmith | heh | |
| 18:15:03 | cdent | jaypipes: are you around, I'm having some confusion over the format of the allocations requests in the candidates response | |
| 18:15:17 | cdent | this is what an allocation update looks like: https://review.openstack.org/#/c/470933/10/placement-api-ref/source/update-allocations-request.json | |
| 18:15:33 | cdent | it's a list of multiple providers | |
| 18:16:20 | jaypipes | cdent: right. | |
| 18:16:34 | jaypipes | cdent: and allocation candidates is a list of that HTTP request structure. | |
| 18:16:36 | cdent | but the output from allocation_candidates (by the docstring at least) is not | |
| 18:16:46 | jaypipes | (without the project_id and user_id of course, since it's not yet known) | |
| 18:16:57 | jaypipes | cdent: link? | |
| 18:17:26 | cdent | oh wait, I think maybe I'm just misreading the docstring on _transform_allocation_requests | |
| 18:17:43 | cdent | not sure | |
| 18:17:53 | cdent | I see a list of dicts | |
| 18:18:01 | cdent | but I'm expecting to see a list of lists of dicts | |
| 18:18:48 | cdent | https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation_candidate.py#L55 | |
| 18:18:51 | jaypipes | cdent: well, the allocation requests response part is a list of dicts, with the dicts having a single key "allocations" that itself is a list of dicts :) | |
| 18:19:09 | jaypipes | cdent: thus, matching the required request payload for PUT /allocations/{uuid} | |
| 18:19:48 | cdent | ah, so the word 'allocations' is repeated many times | |
| 18:19:51 | cdent | that's what threw me off | |
| 18:20:16 | jaypipes | cdent: yeah, I know :( | |
| 18:20:25 | jaypipes | cdent: it's just that's the payload of the request... | |
| 18:20:53 | jaypipes | cdent: the code originally didn't have that repeated allocations key thing but then I realized that wasn't actually what the HTTP payload needed :) | |
| 18:20:54 | cdent | except without the project and user it has to be cooked anyway | |
| 18:20:59 | jaypipes | ya | |
| 18:21:30 | cdent | this is probably not the best code for getting me back into a reviewing frame of mind. it is rather dense | |
| 18:21:53 | jaypipes | cdent: indeed. | |
| 18:22:02 | jaypipes | cdent: WELCOME BACK from PTO! :P | |
| 18:23:02 | cdent | I liked it out there in the world. I might have to go back. | |
| 18:28:22 | cdent | jaypipes: i left some comment on the scheduler side of using candidates (both patches). Overall it seems mostly sane (if a bit dense). instance_uuids is only ever greater than one if someone has requested N of the exact same thing, yes? So affinity doesn't come into play? | |
| 18:29:11 | jaypipes | cdent: correct. | |
| 18:29:28 | cdent | ✔ | |
| 18:47:45 | cdent | jaypipes, edleafe: has there been discussion or decision on whether the query parameter interfaces to /resource_providers and /allocation_candidates should/will have parity? | |
| 18:48:15 | cdent | related, edleafe, is this (filtering rps on traits) still a thing: https://review.openstack.org/#/c/474602/ | |
| 18:50:03 | edleafe | cdent: Heh, your guess is as good as mine. I'm not sure if the plan is still to add that for Pike | |
| 18:50:43 | edleafe | cdent: And if it is, it will have to be copied to the allocation code. | |
| 18:51:13 | cdent | I guess the more immediately salient question for edleafe is: are you still managing that patch? | |
| 18:51:21 | edleafe | cdent: yes | |
| 18:51:25 | cdent | cool, thanks | |
| 18:51:39 | cdent | i'm regrouping my links to things | |
| 18:52:09 | edleafe | cdent: I'm also not clear on whether the /resource_providers filtering is going to continue to be a supported thing | |
| 18:52:11 | mriedem | filtering by traits is definitely high risk at this point | |
| 18:52:24 | mriedem | i don't see why we'd add more to GET /resource_providers, | |
| 18:52:30 | mriedem | when we use /allocation_candidates now | |
| 18:52:44 | mriedem | i mean, we could, but not a priority for nova scheduling atm | |
| 18:52:45 | cdent | mriedem: because sometimes you just want to know about resource providers? | |
| 18:52:50 | cdent | oh, yeah, that | |
| 18:52:51 | cdent | sure | |
| 18:53:05 | edleafe | mriedem: well, yeah, that's my thinking. Except that others may be relying on it being completed | |
| 18:53:12 | mriedem | what others? | |
| 18:53:17 | mriedem | changes or people? | |
| 18:53:38 | mriedem | or https://en.wikipedia.org/wiki/The_Others_(2001_film) ? | |
| 18:53:44 | edleafe | mriedem: any other group that is waiting for placement to be fully funcitonal for their needs | |
| 18:53:46 | mriedem | gggghost kids! | |
| 18:54:01 | mriedem | edleafe: let those groups speak up if they are | |
| 18:54:06 | mriedem | because so far they are silent | |
| 18:54:18 | mriedem | probably b/c they are ghost kids | |
| 18:54:19 | edleafe | mriedem: I just have this silly voice in my head that wants me to think that Placement != Nova | |
| 18:54:29 | mriedem | sure, but realize we have 3 weeks | |
| 18:54:39 | mriedem | claims in the scheduler is the end goal right? | |
| 18:54:46 | mriedem | and allocation candidates is a dependency for that | |
| 18:54:49 | edleafe | mriedem: for pike, yes | |
| 18:54:58 | mriedem | any other utopian sugar is probably queens | |
| 18:55:17 | edleafe | I didn't mean to imply that it would be a thing for pike, just that it might be useful to others at some point | |
| 18:55:45 | mriedem | sure, but let's worry about that when it definitely is | |
| 18:56:20 | edleafe | if we never worry about it, it never will be | |
| 18:58:22 | mriedem | are we going to compete on the worriness scale? | |
| 19:01:08 | edleafe | like I said, I keep thinking that placement is a thing in itself, and not a nova subsystem | |
| 19:01:45 | mriedem | nothing i'm talking about makes it a nova subsystem | |
| 19:04:16 | jmlowe | thanks! | |
| 19:04:22 | jmlowe | you have my attention | |
| 19:04:27 | jaypipes | cdent: parity, no. will there likely be a couple more parameters to the allocation candidates call? yeah. | |
| 19:04:47 | cdent | jmlowe: that's all you get | |
| 19:05:15 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/481189 | |
| 19:05:28 | jmlowe | damn, I'll go back to ignoring this channel for another 1k-2k messages | |
| 19:05:42 | cdent | best choice for your mental health | |
| 19:06:35 | openstackgerrit | Rick Bartra proposed openstack/nova master: Add policy granularity to the Flavors API https://review.openstack.org/449288 | |
| 19:06:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 19:16:09 | melwitt | dansmith: I've mostly removed the instance uuid from the access url for the console stuff, but met a confusing point regarding the transition period between consoleauth/memcached and the database backend, | |
| 19:16:32 | melwitt | the code in the console proxy was using the presence of the instance uuid to determine whether to go to the database backend for validation vs going to the consoleauth service, | |
| 19:16:45 | melwitt | without the instance uuid, we don't really know if the access url is old or new, memcached or database. I'm not sure what to do about that | |
| 19:16:57 | melwitt | I thought, could try first for the database, if that fails, try consoleauth, if that fails too then it's really invalid. but that assumes the operator is running consoleauth still. which might be okay | |
| 19:17:18 | melwitt | my concern there is after all of the outstanding consoles have moved to the database backend, it's safe to stop running consoleauth, but then the fallback behavior should also be turned off. | |
| 19:17:31 | melwitt | so I was thinking we might need a config option | |
| 19:17:49 | dansmith | I don't have this cached in my head.. if hitting the DB is the way forward, | |
| 19:17:51 | dansmith | why not just always do that and stop looking at the auth cache? | |
| 19:18:03 | dansmith | could have a workaround conf for it I guess, but if database always works... | |
| 19:18:17 | melwitt | because of existing urls that people might be using, that had been generated pre-database | |
| 19:18:21 | mriedem | jaypipes: ok comments inline https://review.openstack.org/#/c/476631/ | |
| 19:18:43 | dansmith | melwitt: aren't those expired in like an hour or something? | |
| 19:19:32 | melwitt | dansmith: maybe. I was thinking that, the easy way would be just invalidate them all and make people get new urls. but I dunno how accommodating we need to be about the transition | |
| 19:19:53 | dansmith | melwitt: if it's a short timeout, I don't think we should need to jump through crazy hoops for that | |
| 19:20:06 | melwitt | k. I'll double check what it is | |
| 19:20:20 | dansmith | I wish we could talk about this and fix it in like one week.. I keep paging this data in and out of my brain | |
| 19:29:14 | mriedem | give your mind a break, | |