| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-13 | |||
| 15:08:16 | dansmith | brinzhang: heh, well, I work from home all the time, so I'm pretty much on quarantine normally :) | |
| 15:08:58 | brinzhang | dansmith: you are happiness, it's my dream :) | |
| 15:09:11 | kashyap | Wauw, Dan _is_ Happiness; that's something. | |
| 15:09:59 | dansmith | heh | |
| 15:13:13 | openstackgerrit | Brin Zhang proposed openstack/nova master: Store instance action event exc_val fault details https://review.opendev.org/694428 | |
| 15:14:51 | dansmith | brinzhang: we might want to make sure we have some functional tests that raise both nova and non-nova exceptions in such a way that we can examine them from the API | |
| 15:17:07 | brinzhang | dansmith: I saw you add non-nova test exception in https://review.opendev.org/#/c/712697/1/nova/tests/unit/objects/test_objects.py@1003 | |
| 15:17:36 | brinzhang | You mean, I should add some nova and non-nova exception for os-instance-actions API? | |
| 15:17:36 | mriedem | dansmith: brinzhang: i can look up the cve, but we were exposing credentials to the rbd backing a compute host via instance faults | |
| 15:17:57 | dansmith | brinzhang: yeah, but in a functional test I think | |
| 15:17:57 | mriedem | that's why i referred to the nova.compute.utils code that handles faults | |
| 15:18:07 | dansmith | mriedem: ack yeah | |
| 15:18:08 | mriedem | you could build on the functional test i wrote for ^ | |
| 15:19:02 | mriedem | dansmith: brinzhang: https://review.opendev.org/#/c/674821/ | |
| 15:20:01 | melwitt | kashyap: fyi I added you to this review about adding aarch64 cpu model | |
| 15:20:12 | melwitt | https://review.opendev.org/709494 | |
| 15:20:15 | kashyap | melwitt: Hiya | |
| 15:20:29 | kashyap | melwitt: Will look; thanks for the heads-up | |
| 15:21:43 | melwitt | cool thanks | |
| 15:22:09 | brinzhang | mriedem: dansmith: Looks like I need to add a functional test file for instance_actions, such as nova/tests/functional/test_instance_action.py | |
| 15:22:37 | mriedem | *shrug* there are lots of existing functional tests that make assertions using instance actions, | |
| 15:22:56 | mriedem | i'm not sure there is a module dedicated to instance actions outside of the api samples | |
| 15:23:18 | dansmith | yeah, just another case in one of those, or just add to test_server_faults, IMHO.. it's mostly the same thing | |
| 15:23:43 | mriedem | umm https://github.com/openstack/nova/blob/master/nova/tests/functional/test_instance_actions.py | |
| 15:23:54 | mriedem | or just use the existing module :) | |
| 15:24:12 | dansmith | heh yeah | |
| 15:24:31 | brinzhang | mriedem: yeah, I saw another api sample tests in nova\tests\functional\api_sample_tests\test_instance_actions.py | |
| 15:24:46 | dansmith | *gasp* | |
| 15:24:49 | dansmith | backslashes! | |
| 15:25:04 | mriedem | brinzhang: api samples are generally not really for this type of testing | |
| 15:25:20 | mriedem | they are more about happy path positive test scenarios with minimal fixture | |
| 15:25:31 | brinzhang | mriedem: I know, I will use your paste linke | |
| 15:25:38 | brinzhang | s/linke/link | |
| 15:26:27 | brinzhang | dansmith: I copied from windows, so it's backslashes! | |
| 15:26:38 | dansmith | brinzhang: hence the gasp! :) | |
| 15:27:03 | brinzhang | dansmith: The github sometime I cannot open it fastly, sometime 400 for me, I donot know why .. | |
| 15:28:56 | brinzhang | dansmith: You are a humorous technology *bull*. I think I missed a lot of interesting things :) | |
| 15:29:13 | dansmith | brinzhang: I'm just joking around, don't take me seriously :) | |
| 15:29:45 | mriedem | brinzhang: the great firewall :) | |
| 15:29:58 | mriedem | i'm assuming you're tunneled in through a windows VM for development and being able to be on IRC | |
| 15:30:08 | mriedem | like all of my old huawei coworkers in china | |
| 15:30:17 | brinzhang | dansmith: I like this style, It makes me free. | |
| 15:31:23 | brinzhang | mriedem: yes, the great firewall, we bought shadowscokets, but it cannot work now .. | |
| 15:31:31 | kashyap | LOL, interesting choice of words to describe dansmith: "humorous technology *bull*" :D | |
| 15:31:51 | kashyap | He _is_, though. But still, the vividness of the metaphor. | |
| 15:33:03 | brinzhang | kashyap: Forgive my native language is chinese | |
| 15:33:17 | brinzhang | kashyap: :) | |
| 15:33:22 | kashyap | brinzhang: No-no, I was just saying in jest (joking). Your English is fine | |
| 15:34:58 | brinzhang | kashyap: thanks, a little.. | |
| 15:38:44 | brinzhang | mriedem: I used windows OS and installed IRC(HexChat) in windows, but my VM boot from our company's server(NODE), it's an OpenStack cloud deployed by kolla, just connect by xshell :) | |
| 15:40:48 | kashyap | melwitt: I didn't notice it earlier, but confusingly the method is returning 'mode', while the actual content is 'model': https://review.opendev.org/#/c/709494/3/nova/virt/libvirt/utils.py | |
| 15:41:09 | kashyap | melwitt: I'll add some words in the change; didn't notice it before. | |
| 15:41:54 | melwitt | kashyap: yeah, me neither. though that's not the fault of that patch, right? | |
| 15:42:05 | melwitt | or are you saying the patch is returning the wrong thing | |
| 15:42:24 | kashyap | melwitt: You're right - not the fault of the patch; it's existing | |
| 15:42:47 | kashyap | melwitt: We can change that later, but the core idea (on the basis to set up a CI) is good | |
| 15:43:33 | kashyap | melwitt: I just asked the upstream QEMU AArch64 folks about the model chosen in the patch ('cortex-a57'). I'll report back on the patch. | |
| 15:43:41 | sean-k-mooney | brinzhang: i used a windows laptop basically as a thin client with cygwin and ssh to linux server most of my time working upstream | |
| 15:44:19 | sean-k-mooney | brinzhang: i only started runing linux on my main worstation/laptop when i left intel as we were required to use windows on the it provisioned laptop | |
| 15:44:47 | melwitt | kashyap: ok. yeah, I wasn't sure about the order and placement of the aarch64 checks. and maybe could use some code comments | |
| 15:44:53 | sean-k-mooney | also i like kolla. its easy to debug and uses | |
| 15:45:12 | kashyap | melwitt: Yes, defintely +1 on the code comments. | |
| 15:47:00 | brinzhang | sean-k-mooney: we are same, I think you like to use linux | |
| 15:48:01 | sean-k-mooney | i do but i dont dislike windoes either. | |
| 15:51:00 | brinzhang | sean-k-mooney: yeah, what suits you is the best :) | |
| 15:52:19 | brinzhang | it's time too later for me, I will go, thanks damsmith, mriedem, kashyap, sean-k-mooney (good morning) ^^ | |
| 16:04:50 | kashyap | melwitt: Ah, only noticed your comments _after_ I've hit send on mine. Along with your questions, I have added a few more. | |
| 16:06:01 | melwitt | kashyap: cool, better to have more comments to show if there's any agreement or if I'm only asking dumb questions :P | |
| 16:06:27 | kashyap | melwitt: No, just reading your questions; you make perfectly valid points there. | |
| 16:06:45 | kashyap | You are not a mind reader to know the intention; so asking for code comments is the only reasonable thing :D | |
| 16:08:10 | melwitt | this stuff is greek to me. I'd rather have some explanations there for those that venture to the code in the future, looking to refactor or whatever | |
| 16:08:17 | kashyap | melwitt: Okay, got some more input from QEMU maintainer (Peter Maydell) - he has special interest in AArc64 - I'll add it in the change. He recommends a bunch of things. | |
| 16:08:34 | melwitt | awesome! | |
| 16:09:35 | kashyap | melwitt: I know the mechanics of how QEMU handles things; but the innards of AArch64 and the usage is Greek for me too. (I find Greek aesthetically pleasing, though. I have a couple of books with Greek on left, the English translation on right. :D) | |
| 16:09:48 | melwitt | :) | |
| 16:19:03 | melwitt | kashyap: is this libvirt kvm aarch64 (which is mentioned on feature support matrix)? or is it libvirt qemu aarch64 (not on feature support matrix yet)? https://docs.openstack.org/nova/train/user/support-matrix.html | |
| 16:19:33 | kashyap | melwitt: Yeah, there was two things: | |
| 16:19:56 | kashyap | s/was/are/ | |
| 16:21:42 | kashyap | (1) TCG (the emulatd bits), or what is also referred to as "QEMU"-only; and (2) KVM (with hardware accelerated) in context of AArch64. I guess we want 'care' about both | |
| 16:22:04 | kashyap | Luckily, Peter from QEMU informs that for _both TCG/KVM, we can just use one model: 'max' | |
| 16:22:12 | kashyap | (Comments on why upcoming...) | |
| 16:22:32 | melwitt | kashyap: ok, so the proposed patches aren't for one in particular only | |
| 16:23:13 | kashyap | melwitt: Although for CI, perhaps the dev just cares about QEMU (TCG). Just like how Nova x86 CI runs on TCG guests (because no nested, to get KVM). | |
| 16:23:25 | kashyap | Not sure if I'm helping or confusing :D | |
| 16:23:40 | melwitt | uh ... helping a little :) but it's not you, it's me | |
| 16:23:59 | melwitt | I'm just trying to write something on the lp bug for the patch above the one we've been looking at | |
| 16:24:57 | sean-k-mooney | kashyap: what is the max model usef for? | |
| 16:24:57 | melwitt | the bug is unable to attach volume to instance with config drive on arm64 and according to the feature support matrix the support is "unknown" so I was thinking to set the bug Low based on that https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_attach_volume_driver_libvirt_kvm_aarch64 | |
| 16:25:03 | kashyap | melwitt: I see. I'll collect thoughts and write it in the change, and we can take it from there. | |
| 16:25:49 | kashyap | sean-k-mooney: The 'max' model will apparently give you the moving-target of "all the stuff we [QEMU] can currently emulate". | |
| 16:26:46 | kashyap | melwitt: Yeah, 'low' for now is fine. | |
| 16:26:48 | sean-k-mooney | kashyap: so totally non portable | |
| 16:27:01 | sean-k-mooney | kashyap: where is max used | |
| 16:27:26 | sean-k-mooney | e.g.is it a cpu model or a scisi contoler or what | |
| 16:27:31 | kashyap | sean-k-mooney: Well, the recommendation from the AArch64 experts is to use 'max' for _both_ TCG and KVM: | |
| 16:27:36 | kashyap | ... "unless you really specifically want an always-the-same-thing even in newer QEMU versions fixed target". | |
| 16:27:44 | sean-k-mooney | im trying to figure out the context | |
| 16:27:52 | kashyap | Please read the scrollback with Mel. | |
| 16:28:01 | kashyap | It's in context of https://review.opendev.org/#/c/709494/ | |
| 16:28:04 | sean-k-mooney | ya i was trying to and could not fiutre it out | |