Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-17
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 was created)
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: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 usages https://review.openstack.org/457535
09:22:52 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: CLI for allocations https://review.openstack.org/457534
09:22:53 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: [WIP] CLI for resource classes https://review.openstack.org/511182
09:22:53 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: CLI for aggregates https://review.openstack.org/505643
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 efried alex_xu My contention is that it *can't* return the correct RPs for this scenario under the current semantics.
12:33:34 cdent alex_xu: root is a bad term in this context :)
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 purplerbot <efried> ohh, you're missing a LEFT JOIN [2017-10-17 12:41:57.325623] [n 3Vz8]
12:42:56 cdent I’m going to save [t 3Vz8] because it is probably useful to whip out just about any time
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
12:48:45 efried alex_xu fixed nit ^
12:49:33 efried cdent Did you want me to rename that 'p' var ^ ?
12:50:25 efried cdent I don't think we can afford to sweep this under the rug now and just hope it doesn't rear its head later.
12:50:32 efried Sorry, that was meant for alex_xu
12:50:56 efried (I *totally* think we can sweep a terse variable name under the rug)
12:51:11 efried ('p' for 'precedent'.)
12:51:26 efried So let's try this again.
12:51:36 efried alex_xu I don't think we can afford to sweep this under the rug now and just hope it doesn't rear its head later.
12:52:10 efried alex_xu At the moment, the scope of where this code is used is very contained, and possibly never even makes its way to where the user can see it.

Earlier   Later