| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-23 | |||
| 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 | |
| 12:52:05 | hrw | sean-k-mooney: app store requires 64bit apps upload so it is only a matter of time | |
| 12:52:22 | sean-k-mooney | yep they just wanted it for a transition period | |
| 12:52:45 | hrw | once support for <iphone 5s gets killed they can go 64bit only | |
| 12:52:48 | sean-k-mooney | anyway its fun times as long as you are not intel right now | |
| 12:52:55 | hrw | o yes | |
| 12:53:27 | hrw | unless you are aarch64 porter/developer and have to fight with software written with 'there is only x86' mantra ;D | |
| 12:54:39 | sean-k-mooney | until there is a standard aarch64 system that runs normal linux that developers can use that is affordable that is going to be the case for a while | |
| 12:54:54 | hrw | use or buy? | |
| 12:55:14 | sean-k-mooney | well i was thinking by but i guess you can now use aws | |
| 12:55:39 | sean-k-mooney | e.g. a laptop/desktop that developers can use as a daily driver without going all the way to a full server | |
| 12:56:06 | hrw | sean-k-mooney: https://marcin.juszkiewicz.com.pl/2019/02/23/we-need-arm64-systems-for-developers-again/ | |
| 12:56:18 | hrw | sean-k-mooney: yeah | |
| 12:56:21 | kevinz | hrw: thanks for the comments, I will check | |
| 12:56:56 | hrw | sean-k-mooney: there are attempts to run linux natively on those snapdragon based win10 laptops | |
| 12:57:00 | sean-k-mooney | hrw: ya basically that :) | |
| 12:57:38 | sean-k-mooney | that could be intersting but do they supprot hardware virtualisation so you could do openstack dev on them | |
| 12:58:06 | hrw | in theory virtualization is mandatory on aarch64 | |
| 12:58:17 | sean-k-mooney | oh good to know | |
| 12:58:53 | sean-k-mooney | i guess even on a mobile/laptop chip it might be useful for sandboxing | |
| 12:59:24 | sean-k-mooney | e.g. for secure contianer technology/linux subsystem for windows | |
| 12:59:44 | openstackgerrit | Kevin Zhao proposed openstack/nova master: Add default cpu model for aarch64 https://review.opendev.org/709494 | |
| 13:00:41 | hrw | sean-k-mooney: https://paste.centos.org/view/975095f5 - how many mistakes I made? | |
| 13:00:50 | hrw | sean-k-mooney: CI job | |
| 13:01:39 | hrw | sean-k-mooney: 'check-arm64' is pipeline in zuul - used at same time as 'check' | |
| 13:02:32 | sean-k-mooney | if the nodeset is already defiend somewhere else you do not need to redefine it. | |
| 13:02:51 | sean-k-mooney | other then that it looks more or less correct | |
| 13:03:03 | hrw | sean-k-mooney: in kolla we created one | |
| 13:03:37 | sean-k-mooney | zuul collects all the definition form all projects | |
| 13:03:52 | sean-k-mooney | so if its already defeined in another repo you can just reuse it | |
| 13:03:56 | hrw | I know, looking at tempest one now | |
| 13:04:10 | hrw | sean-k-mooney: aarch64 is not quite popular in CI so far | |
| 13:05:04 | sean-k-mooney | if you want to redfine the node set then you might need to give it a new name | |
| 13:05:13 | sean-k-mooney | the other think is the voting:false | |
| 13:05:29 | sean-k-mooney | that should be in the where you use the job under check-arm64 | |
| 13:05:42 | sean-k-mooney | not in the job definition | |
| 13:06:52 | hrw | sean-k-mooney: you use both form ;) | |
| 13:07:02 | hrw | nova-lvm has voting in definition | |
| 13:07:46 | sean-k-mooney | i think if you set it in the defition it will apply to all uses of the job | |
| 13:07:53 | sean-k-mooney | basically chanign the default | |
| 13:07:54 | hrw | ok | |
| 13:08:04 | sean-k-mooney | people dont expect to have to set voting:true | |
| 13:08:22 | hrw | yep | |
| 13:08:50 | sean-k-mooney | i would do something like this http://paste.openstack.org/show/791022/ | |
| 13:08:59 | sean-k-mooney | but ya i think way you had would work | |
| 13:09:43 | hrw | on it | |
| 13:10:12 | alex_xu | dansmith: last question for this https://review.opendev.org/#/c/631244/68/nova/conductor/manager.py@1621, Sundar said you are more clear on this. The question is why we don't fail directly when binding failed at build_instances instead of try next alt host. The build_and_run_instances looks like will fail directly when binding arq failed. | |
| 13:10:31 | hrw | sean-k-mooney: https://paste.centos.org/view/61a2b0ca | |
| 13:11:15 | hrw | sean-k-mooney: openstack-single-node-bionic-aarch64 copied from devstack | |
| 13:11:30 | hrw | sean-k-mooney: openstack-single-node-bionic-aarch64 copied from devstack openstack-single-node-bionic one | |
| 13:11:35 | hrw | to be exact | |
| 13:16:41 | gibi | lyarwood: I saw yet another evacuation problem in the live-migration task on master | |
| 13:16:51 | gibi | lyarwood: VirtualInterfaceCreateException happens during evac | |
| 13:16:57 | gibi | https://zuul.opendev.org/t/openstack/build/2703656a683043a6b741fa4c2283b314/log/job-output.txt#7708 | |
| 13:17:01 | gibi | https://zuul.opendev.org/t/openstack/build/2703656a683043a6b741fa4c2283b314/log/logs/screen-n-cpu.txt?severity=4#7865 | |
| 13:17:22 | gibi | I don't knowi if you already see this | |
| 13:20:08 | artom | stephenfin, so I've finally gotten around to removing the 2/3 NUMA split in https://review.opendev.org/#/c/672595/ | |
| 13:20:29 | artom | Mind taking a look when you get a chance? I'll revisit your hugepages bugfix in the meantime | |
| 13:22:25 | sean-k-mooney | hrw: yes that woudl be better since you have the group dfinition that are used for the ansible roles | |
| 13:22:50 | sean-k-mooney | using primary may have worked but like would have caused issues | |
| 13:23:34 | hrw | sean-k-mooney: 'primary' was taken from kolla ;D | |
| 13:23:36 | sean-k-mooney | hrw: is there a reason that you are not defineing this in devstack and using a depends-on | |
| 13:23:49 | sean-k-mooney | ah i know that seamed familar | |
| 13:24:27 | sean-k-mooney | they use primary and secondary instead of subnode terminology | |
| 13:24:37 | sean-k-mooney | that we use for devstack | |
| 13:24:56 | hrw | sean-k-mooney: after playing with devstack in past there is no stick long enough to touch it (forgive poor idiom use) | |
| 13:25:39 | sean-k-mooney | hrw: devstack and kolla-ansible are my two favorite installers | |
| 13:25:45 | hrw | ;) | |
| 13:25:46 | sean-k-mooney | depending on what im doing | |
| 13:25:50 | hrw | yoctozepto: ^^ idea? | |
| 13:26:13 | lyarwood | gibi: sorry was out at lunch, no I hadn't seen any issues since my changes landed :/ | |
| 13:26:17 | hrw | sean-k-mooney: I only use k-a for deployment. at least I know that it works and gives me sane setup | |
| 13:26:40 | hrw | sean-k-mooney: when I used devstack the way of dealing with issues was 'restart and hope' | |
| 13:26:50 | sean-k-mooney | hrw: ya i use k-a for any long lived setup and use devstack for everything else | |
| 13:27:40 | sean-k-mooney | devstack is actully pretty reliable you just need to learn how to use it | |
| 13:27:51 | sean-k-mooney | and how to fix common issues | |
| 13:28:18 | sean-k-mooney | normally when it breaks its because of a depency did a new release | |
| 13:29:07 | sean-k-mooney | once you know what to look for fixing it get much simpler | |
| 13:29:13 | gibi | lyarwood: I hope this is just a one time issue. I've rechecked the patch see if it goes now | |
| 13:29:13 | hrw | possible | |