Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-13
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
16:28:29 sean-k-mooney so this has changed form the old advise of use the VIRT cpu model
16:28:42 melwitt kashyap: yeah so I think what should likely happen is that once they have the CI set up and running we will update the feature support matrix with all of the things that are working in the CI?
16:31:09 kashyap sean-k-mooney: No, no you're mixing up CPU model and machine type for AArch64
16:31:20 kashyap sean-k-mooney: 'virt' is still the recommended machine type for AArch64.
16:31:32 kashyap melwitt: Yeap.
16:31:33 sean-k-mooney ah yes i am
16:31:45 melwitt cool
16:31:54 sean-k-mooney this still will cause issue for live migration if we use max
16:32:08 sean-k-mooney so i dont know if that is a good default
16:32:13 kashyap melwitt: I _think_ first want to care about TCG, because for KVM, you'd need AArch64 hardware in the CI
16:32:25 kashyap sean-k-mooney: I've talked to the AArch64 maintainer, I'm posting the recommendations in the patch.
16:32:31 sean-k-mooney kashyap: we have AArch64 hardware in ci
16:32:33 melwitt kashyap: ack
16:32:46 sean-k-mooney kashyap: thats the whole point lenario donated some
16:32:49 kashyap sean-k-mooney: Good, then. We've got the recommendations for that, too.

Earlier   Later