| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-23 | |||
| 10:48:06 | lyarwood | kashyap: I haven't had time to circle back to it yet | |
| 10:48:25 | lyarwood | kashyap: but it looks like the config drive is missing it's LABEL causing the test to fail | |
| 10:48:25 | stephenfin | bauzas: sure | |
| 10:49:15 | kashyap | I see; I'll see if I can poke more to see why Zuul complains | |
| 10:51:20 | lyarwood | kashyap: tbh I think it might be a bug with the version of q35 Ubuntu is using | |
| 10:51:39 | lyarwood | kashyap: well QEMU but you get the point | |
| 10:51:44 | kashyap | Hmm, didn't think of it; you mean version of QEMU? | |
| 10:51:49 | kashyap | Bingo | |
| 10:51:50 | lyarwood | yeah | |
| 10:52:13 | kashyap | lyarwood: BTW, be careful with the term "circle back"; Urban Dictionary has a harsh definition of it. Not gonna link it :D | |
| 10:53:25 | kashyap | I'll check the QEMU version of Ubuntu; sometimes they miss to backport some bug fixes. FWIW, we've pointed them out before | |
| 10:53:38 | kashyap | (I mean, in a different scenario) | |
| 11:08:10 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: libvirt: change UEFI check to handle AArch64 better https://review.opendev.org/714311 | |
| 11:09:21 | hrw | this patch should pass tests (does 'tox -e py38') and better shows issue | |
| 11:10:07 | kashyap | hrw: Hi | |
| 11:10:13 | hrw | hi kashyap | |
| 11:10:18 | hrw | others | |
| 11:10:52 | kashyap | hrw: Good point on the undefine with NVRAM thing | |
| 11:10:55 | hrw | now I have one of those nasty days when I look at nova code... | |
| 11:10:57 | kashyap | Will look post-lunch | |
| 11:11:03 | kashyap | :D | |
| 11:11:31 | hrw | speaking of q35... when it will be finally default? | |
| 11:12:44 | hrw | x86 users will get hit hard with it. pleasure to look would be | |
| 11:13:43 | bauzas | gibi: stephenfin: done http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013507.html | |
| 11:14:15 | gibi | bauzas: thanks | |
| 11:26:01 | hrw | "kernel doesn't support AMD SEV" message is funny | |
| 11:26:18 | hrw | as it gets checked on all archs instead of just x86 | |
| 11:53:04 | hrw | I wonder how much it will be rewritten once it will be supported somewhere else than amd cpus | |
| 11:54:44 | stephenfin | gibi: did you ever do a blog post on the bandwidth-aware scheduling feature? | |
| 11:55:05 | stephenfin | I recall there being one floating around before a past PTG but heck if I can find it now | |
| 11:55:09 | gibi | stephenfin: rubasov did one in the early days. let me find the link | |
| 11:55:38 | gibi | stephenfin: is this the one you remember? https://rubasov.github.io/2018/09/21/openstack-qos-min-bw-demo.html | |
| 11:56:12 | sean-k-mooney | stephenfin: there was two summit presentations too | |
| 11:56:36 | stephenfin | gibi: That's the one, yup. Thanks! | |
| 11:56:51 | sean-k-mooney | one descirbiing the poc and then one describing the final feature | |
| 11:57:22 | gibi | sean-k-mooney: I only remember showing the PoC | |
| 11:58:04 | sean-k-mooney | yes showed the poc in vancovour and the final version in denver i think | |
| 11:58:24 | gibi | https://www.youtube.com/watch?v=ls9RXpG6Is0 | |
| 11:58:48 | gibi | there was some PTG presentation, true. The above is a summit presentation | |
| 11:59:02 | sean-k-mooney | sorry yes that is waht im thinking of | |
| 11:59:23 | gibi | I think we don't have any recording, other than the blog post, about the PTG presentation | |
| 12:01:34 | hrw | https://paste.centos.org/view/abe36617 - does it look ok to send for review? skipping AMD SEV check on !x86-64 | |
| 12:09:47 | hrw | fixed missing import, running tox, will send | |
| 12:11:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/pike: Avoid circular reference during serialization https://review.opendev.org/714148 | |
| 12:12:20 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: libvirt: check for AMD SEV only on x86-64 https://review.opendev.org/714425 | |
| 12:18:43 | kashyap | hrw: Upstream there's a CI job to test it: https://review.opendev.org/#/c/708701/ | |
| 12:19:32 | kashyap | hrw: "it" == q35; and aiming to switch to it in the 'V' release, or early, if possible. | |
| 12:20:51 | hrw | kashyap: cool ;) | |
| 12:21:41 | hrw | kashyap: I start to think how to add aarch64 ci job ;D | |
| 12:22:12 | kashyap | I'm not good with the CI stuff, but probably check with #openstack-infra or other folks here (like Sean) might tell you more. | |
| 12:22:35 | kashyap | It is "usually" take-an-existing-job-and-tweak-it | |
| 12:22:48 | hrw | I know | |
| 12:22:56 | hrw | handled too much of CI in kolla | |
| 12:26:17 | kashyap | Oh, dear. Okay :) | |
| 12:28:37 | lyarwood | melwitt / elod: https://review.opendev.org/#/q/topic:bug/1867380+status:open - could you hit the rest of these today please? | |
| 12:29:05 | openstackgerrit | Kevin Zhao proposed openstack/nova master: Add default cpu model for aarch64 https://review.opendev.org/709494 | |
| 12:29:17 | lyarwood | https://review.opendev.org/#/q/topic:bug/1813789+status:open should also be ready to review | |
| 12:31:07 | hrw | sean-k-mooney: which nova ci job would be best to run on aarch64? | |
| 12:32:41 | sean-k-mooney | start with i think tempest-integrated-compute? | |
| 12:32:51 | sean-k-mooney | let me see if i can get the correct name | |
| 12:33:26 | sean-k-mooney | ya tempest-integrated-compute | |
| 12:33:54 | sean-k-mooney | if you have that working we disucsed that you really need 2 multi node jobs | |
| 12:34:10 | sean-k-mooney | one with qcow image backedn and cinder with lvm | |
| 12:34:15 | sean-k-mooney | and the second with ceph | |
| 12:35:02 | kevinz | sean-k-mooney: hrw: so the nova CI still rely on devstack CI test finished ? | |
| 12:35:23 | sean-k-mooney | that way you can test live and code migration with both block and volume backed migration in the first job and shared storage in teh second | |
| 12:35:31 | hrw | kevinz: thx | |
| 12:35:52 | sean-k-mooney | kevinz: can you rephrase that? | |
| 12:36:35 | sean-k-mooney | kevinz: the upstream integration ci jobs outside of install projects all use devstack to deploy the code under test | |
| 12:36:52 | sean-k-mooney | and then use tempest to exectue the tests if that is what you were asking | |
| 12:36:54 | kevinz | I mean "tempest-integrated-compute" test need devstack jobs ready? https://review.opendev.org/#/c/708317/ | |
| 12:37:38 | sean-k-mooney | kevinz: ah right well yes unless you are going to do alot more work and port one of the install jobs | |
| 12:38:14 | sean-k-mooney | e.g. create a job based on osa or kolla-ansible or something that can deploy on aarch64 | |
| 12:38:43 | sean-k-mooney | kevinz: although is https://review.opendev.org/#/c/708317/ for aarch64 as arm64 is technically a different architecutre | |
| 12:38:46 | gibi | dansmith: went through cyborg series again, I had only couple of things so I feel we are close | |
| 12:40:49 | kevinz | sean-k-mooney: OK, so based on Devstack CI jobs, some tempest test are not stable...means failed "sometimes" | |
| 12:41:24 | sean-k-mooney | kevinz: well that happens on x86 too you know | |
| 12:41:28 | sean-k-mooney | is it more unstable | |
| 12:43:09 | kevinz | hrw: sean-k-mooney: I'm going to enlarge the VM to 16GB to see if it works better... | |
| 12:44:25 | hrw | kevinz: commented on that devstack patch | |
| 12:45:23 | sean-k-mooney | you sould only need 8G but it might be an issue with your concurancy how may cpus cores do you have exposed and what concurancy is the job running with | |
| 12:46:47 | sean-k-mooney | by the way am in the only person who asociates arm64 with arm64_32 and uses AArch64 when refering to 64bit arm v8 compilation target | |
| 12:47:06 | sean-k-mooney | as in arm64_32 form this context https://llvm.org/devmtg/2019-04/slides/TechTalk-Northover-A_tale_of_two_ABIs_ILP32_on_AArch64.pdf | |
| 12:47:52 | hrw | sean-k-mooney: aarch64 is official architecture name :) | |
| 12:48:02 | sean-k-mooney | i guess without the _32 suffix arm64 is used interchangeable with aarch64 | |
| 12:48:34 | hrw | arm64_32 is aarch32 which is 32bit mode on aarch64 cpu. totally optional thing in cpu design, not present in several server processors | |
| 12:48:44 | sean-k-mooney | hrw: yep just i dont see arm64 that often and was not sure if people were shotening arm64_32 or not | |
| 12:48:45 | hrw | sean-k-mooney: exactly | |
| 12:48:53 | hrw | no arm64==aarch64 | |
| 12:48:58 | sean-k-mooney | ok | |
| 12:49:15 | hrw | for me arm64_32 is one step from abomination ;D | |
| 12:49:15 | sean-k-mooney | ill keep avoiding using arm64 then and keep using aarch64 | |
| 12:49:34 | sean-k-mooney | well its better then continuing to use armv7 | |
| 12:50:44 | sean-k-mooney | hrw: did you see the recent new about that amazon graviton2 chips | |
| 12:50:54 | sean-k-mooney | those look really interesting | |
| 12:50:59 | hrw | sean-k-mooney: aarch32 support in aarch64 cpus is mainly distro builders and android developers nowadays imho. first ones remove armv7 builders and move to aarch32 VM instances on aarch64 servers, latter ones need a way to build/test their arm32 android apps somewhere natively | |
| 12:51:01 | sean-k-mooney | too bad they dont sell them | |
| 12:51:14 | hrw | sean-k-mooney: graviton2 looks great | |
| 12:51:40 | hrw | sean-k-mooney: let me say that way: please do not start aarch64 developers hardware discussion. | |
| 12:51:42 | sean-k-mooney | hrw: well apple are also pussing aarch32 for legacy compatiblity reasons | |