| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-17 | |||
| 09:10:28 | jichen | HTTP/1.1 200 OK | |
| 09:10:30 | jichen | Date: Tue, 17 Oct 2017 09:09:54 GMT | |
| 09:10:31 | jichen | Server: Apache/2.4.18 (Ubuntu) | |
| 09:10:33 | jichen | Content-Length: 62 | |
| 09:10:34 | jichen | Content-Type: application/json | |
| 09:10:36 | jichen | OpenStack-API-Version: placement 1.10 | |
| 09:10:37 | jichen | vary: OpenStack-API-Version | |
| 09:10:39 | jichen | x-openstack-request-id: req-4ce20136-afb8-405e-86ff-2397a21cc1c2 | |
| 09:10:39 | cdent | jichen: you’re right that we should probably be consistent about it, but it looks like we weren’t. I think the logic that was used is that a location header is a good idea if the response is empty | |
| 09:10:40 | jichen | Connection: close | |
| 09:10:42 | jichen | {"traits": ["CUSTOM_ABC"], "resource_provider_generation": 19} | |
| 09:10:44 | jichen | sorry, wrong lURL | |
| 09:11:03 | jichen | 2nd URL I used is to PUT traits | |
| 09:11:10 | cdent | jichen: for long pastes like that it is better to use a pastebin like http://paste.openstack.org/ | |
| 09:11:17 | jichen | ok, right now | |
| 09:11:31 | cdent | that’s put to add traits to a resource provider, not to create a trait | |
| 09:11:57 | jichen | cdent: http://paste.openstack.org/show/623800/ | |
| 09:14:20 | priya__ | hi ..could somebody review the commit - https://review.openstack.org/#/c/508533/ | |
| 09:14:44 | cdent | jichen: right, so that request corresponds with this handler: https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/trait.py#L217-L248 which does not set the header | |
| 09:14:52 | cdent | jichen: do you think it should? | |
| 09:16:37 | jichen | cdent: I guess I used wrong URL ... I think we should not add a header as this is a just 'associate' | |
| 09:16:59 | jichen | so I will update the document of placement api ref.. it doesn't have the info about this header | |
| 09:18:10 | masber | good afternoon all, I am having an issue resizing nodes. My hardware runs NUMA and I pin my vcpus for better performance. I could not resize the instance because it could not fit any NUMA node so what I did was to shutdown the vms on that node so the kvm could relocate them and make more space for the extra resources | |
| 09:18:51 | cdent | I think we didn’t end up adding the info about headers because there’s no clear use case for them. When I wrote the first bits of the code that did add a location header, I did it because it is standard form: create something? then put a location header in the response. We don’t necessarily need to cloud the documentation with that except perhaps in the case of POST /resource_providers (because that tells you wha | |
| 09:18:51 | cdent | was created) | |
| 09:19:01 | cdent | jichen: in everything else there are other ways | |
| 09:19:04 | masber | I resized the node while it was shutdown, and then I tried to confirm the resize but confirmation failed saying "cannot resize instance while it is in vm_state resized" | |
| 09:19:40 | masber | since then I can even start resizing the node as state stays as active | |
| 09:19:45 | masber | *can't | |
| 09:20:03 | masber | is this a bug or am I doing something stupid? | |
| 09:21:12 | jichen | cdent: ok, I can live with that, I thought we return location for every thing we created like you mentioned; and you are right, seems no clear use case for that, thanks for your guide | |
| 09:21:50 | cdent | jichen: you’re welcome, and thank you for trying to make sure we are consistent, we can probalby do better on that. | |
| 09:22:25 | jichen | cdent: yes, I will make more analysis on that :), thanks | |
| 09:22:52 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for allocations https://review.openstack.org/457534 | |
| 09:22:52 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for usages https://review.openstack.org/457535 | |
| 09:22:53 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for aggregates https://review.openstack.org/505643 | |
| 09:22:53 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] CLI for resource classes https://review.openstack.org/511182 | |
| 09:22:54 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] RP list: member_of and resources parameters https://review.openstack.org/511183 | |
| 09:31:43 | priya__ | cdent : Could you please review https://review.openstack.org/#/c/508533/ | |
| 09:32:59 | cdent | priya__: yes, will put it on my list for today | |
| 09:33:54 | priya__ | thank you ! | |
| 10:45:13 | openstackgerrit | Naichuan Sun proposed openstack/nova master: VGPU_support: add enabled white list https://review.openstack.org/512580 | |
| 11:11:16 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Change 'InstancePCIRequest' spec field https://review.openstack.org/449257 | |
| 11:16:23 | ralonsoh | alex_xu: hi, if you have time, can you take a look at https://review.openstack.org/#/c/502306/? | |
| 11:17:23 | ralonsoh | alex_xu: BTW, this one was approved last cycle. Half of the code is already merged. I would like to have it approved this cycle to continue the work: https://review.openstack.org/#/c/504895/ | |
| 11:24:17 | openstackgerrit | edan david proposed openstack/nova master: Don't overwrite binding-profile https://review.openstack.org/505613 | |
| 12:21:30 | cdent | alex_xu: if you didn’t see this bit of irc chat yesterday, it covers some of the issues with shared providers and traits: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-16.log.html#t2017-10-16T18:37:18 | |
| 12:21:50 | cdent | it took quite a while to figure out what efried was talking about but we finally figured it out in that chat | |
| 12:25:05 | efried | That's me. It can take a while to figure out wtf I'm talking about. | |
| 12:25:28 | efried | I'd like to think it's because they're such advanced concepts, I have to explain them carefully to lesser mortals. | |
| 12:25:41 | efried | (In case you're just joining us, naw, that ain't it.) | |
| 12:26:25 | cdent | that ^^ was driven by alex’s latest comment on your spec, on the principle of more context is better | |
| 12:27:41 | efried | cdent I know, and I appreciate it. I'm just ribbin ya. | |
| 12:29:15 | cdent | I know, I’m giving you context on the context giving, for sake of contextualizing the people in our context, contextually | |
| 12:29:47 | alex_xu | ralonsoh: yea, add it to my review list | |
| 12:30:04 | cdent | soon the ai which is learning human behavior from the log of this channel will achieve consciousness, and presumably wipe us from the face of the earth | |
| 12:30:16 | alex_xu | cdent: efried yea, I read that today | |
| 12:30:37 | alex_xu | cdent: efried, the current trait implement supports that case | |
| 12:31:08 | alex_xu | the current trait implement will try to collect the traits from the RP and sharing RP which in the same aggregates | |
| 12:31:22 | efried | alex_xu The case where RAID5 and SSD are split across the compute RP and the shared storage RP? | |
| 12:32:32 | alex_xu | the problem is the current implementation of https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L2453 doesn't return the correct PRs | |
| 12:33:17 | alex_xu | _get_all_with_shared only return that root RP once. | |
| 12:33:34 | cdent | alex_xu: root is a bad term in this context :) | |
| 12:33:34 | efried | alex_xu My contention is that it *can't* return the correct RPs for this scenario under the current semantics. | |
| 12:33:51 | cdent | efried: your forthcoming test will make it all clear :D | |
| 12:34:10 | alex_xu | for that case, actually we expect return that root RP twoice, and then we should generate two combinations: #1 root RP with local disk, #2 root RP with shared disk | |
| 12:34:35 | alex_xu | cdent: forgive me, let me use root rp first :) that pain for me also | |
| 12:34:57 | efried | alex_xu Actually, it won't return the compute+localdisk combination, because that wouldn't satisfy the RAID5 trait. | |
| 12:34:59 | alex_xu | and then, the trait implementation will find out #1 and #2 which have enough trait | |
| 12:35:37 | efried | But it *will* return the compute+shared combination, even though it *shouldn't*. | |
| 12:36:23 | efried | It shouldn't because the shared storage doesn't satisfy the SSD trait. But placement has no way of knowing that RAID & SSD were both supposed to apply to the storage, whereas the HW_CPU... trait wasn't. | |
| 12:37:56 | alex_xu | efried: I didn't have test it, but I think the current code will return compute+local | |
| 12:38:09 | alex_xu | and it never return the compute+shared combination | |
| 12:38:18 | efried | alex_xu Because of that bug? Maybe. | |
| 12:38:47 | alex_xu | because the implement of _get_all_with_shared | |
| 12:39:32 | alex_xu | but that still doesn't correct, you are expecting _get_all_with_shared return two combinations | |
| 12:39:56 | efried | _get_all_with_shared is the piece that doesn't yet take traits into account? | |
| 12:40:01 | alex_xu | and then the trait implement will filter out the correct one | |
| 12:40:07 | alex_xu | efried: yes | |
| 12:40:27 | efried | Right, gotcha. So you're right: _get_all_with_shared *should* return *both* combinations. (If it's not, that's a bug.) | |
| 12:40:51 | efried | And then the code you're writing *should* filter *both* of them out and yield zero candidates. | |
| 12:40:55 | alex_xu | efried: because this https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L895 | |
| 12:41:04 | efried | But there's no way to write your code to do that. | |
| 12:41:25 | alex_xu | that condition assumes that there only have the one case in (local and shared) | |
| 12:41:55 | alex_xu | efried: but the first thing we should figure out is that whether we want to support that case | |
| 12:41:57 | efried | ohh, you're missing a LEFT JOIN | |
| 12:42:21 | efried | Well, I contend we can't *not* support that case. | |
| 12:42:26 | efried | At least not long term. | |
| 12:42:56 | cdent | I’m going to save [t 3Vz8] because it is probably useful to whip out just about any time | |
| 12:42:56 | purplerbot | <efried> ohh, you're missing a LEFT JOIN [2017-10-17 12:41:57.325623] [n 3Vz8] | |
| 12:43:34 | efried | (c) 2017 | |
| 12:44:09 | efried | So alex_xu, if we were going to say we don't support that scenario, how would that be worded? | |
| 12:44:43 | alex_xu | at least, currently the nova doesn't support the case we have local disk and shared disk | |
| 12:45:06 | alex_xu | actually nova doesn't know about the disk is local or shared, it just create the instance image in a directory | |
| 12:45:37 | alex_xu | under that directory, it maybe local or a NFS... | |
| 12:45:52 | efried | alex_xu What about local ephemeral (boot) plus volumes? | |
| 12:46:10 | alex_xu | and I didn't have any real world case similar to that in my mind | |
| 12:46:34 | alex_xu | efried: the resource class DISK_GB is only about local ephemeral disk | |
| 12:46:54 | alex_xu | s/local ephemeral disk/ephemeral disk/ | |
| 12:47:54 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: set/check if inventory change in tree https://review.openstack.org/470575 | |