чт, 16 янв. 2020 г. в 13:26, Martin Grigorov <martin.grigo...@gmail.com>:
> Hi Илья, > > On Thu, Jan 16, 2020 at 10:19 AM Илья Шипицин <chipits...@gmail.com> > wrote: > >> >> Hello, Martin! >> >> btw, just curious, how is Apache Foundation (or you personally) >> interested in all that ? >> please do not blame me, I really like to know. >> > ok, so you work in some company that is interested in haproxy on ARM64. you do not want to tell it's name, at least is it legal ? is it related to some government ? if "no" and "no", I guess most people won't ask any more questions :) personally, I do not work at Haproxy Inc, I use haproxy, sometimes I contribute to it. Please do not consider me as an "official representative". I'm interested in testing haproxy on ARM64, I planned to do so. I can priorierize it according to your interest to it. and yes, I can accept hardware donation (even considering I'm not part of Haproxy Inc). also, from my point of view, what would be really useful in your case is testing not just official reg-tests, but also your configs. reg-tests cover only partially. If you enable clang asan in your own workload there's a chance to catch something interesting (or, to make sure your own workload is ok). I can help with that as well. > >> > @apache.org is just one of my several emails. And it is the default one > in my email client. > ASF is not related anyhow to my participation here. > If I used my work email then it might look like some kind of > advertisement. I'd like to avoid that! > Next time I will use my @gmail.com one, as more neutral. Actually I've > used the GMail one when registering to this mailing list, so probably the > post from @apache has been moderated. I'll be more careful next time! > > Thanks, Илья! > > Regards, > Martin > > >> >> чт, 16 янв. 2020 г. в 12:32, Martin Grigorov <mgrigo...@apache.org>: >> >>> Hello HAProxy developers, >>> >>> At work we are going to use more and more ARM64 based servers and >>> HAProxy is one of the main products we rely on. >>> So I went checking whether HAProxy project has a CI environment for >>> testing on ARM architecture. >>> >> >> we are looking towards >> https://docs.travis-ci.com/user/multi-cpu-architectures >> >> >>> I've found this recent discussion: >>> https://www.mail-archive.com/haproxy@formilux.org/msg35302.html (I >>> didn't find a way how to continue on the same mail thread, so I'm starting >>> a new one. Apologies for that!). >>> >> >> I played with arm64 for a while, the issue I encountered is travis-ci >> cache key, i.e. we cache openssl builds between our builds. >> so travis used the same cache key for both amd64 and arm64 builds (this >> might have changed recently, I did not check yet) >> >> arm64 is in my queue (as well as recent s390x arch from travis), hope to >> get back to it within month or so. >> >> >>> From this discussion and from >>> https://github.com/haproxy/haproxy/blob/master/.travis.yml I understand >>> that there is no public CI in use (i.e. TravisCI or CirrusCI) but some of >>> the developers run some tests locally regularly. >>> >> >> it is not completely true. >> there's public CI. we do not use github PR machinery, so sometimes tests >> fail after push to master branch. it is considered as ok, failures are >> fixed pretty fast. >> for example, see >> https://www.mail-archive.com/haproxy@formilux.org/msg35910.html >> it was just perfect, failure detected using CI and fixed within few days. >> no customers affected. >> >> >>> I've forked the project and tested on TravisCI ( >>> https://travis-ci.org/martin-g/haproxy/builds) but unfortunately the >>> builds were not very stable: >>> 1) some tests fail sometimes. I guess it is because of some timing issues >>> For example: >>> - https://travis-ci.org/martin-g/haproxy/jobs/636745241 >>> - https://travis-ci.org/martin-g/haproxy/jobs/636750676 >>> - https://travis-ci.org/martin-g/haproxy/jobs/636763346 >>> >> >> that's very interesting. I'll have a look. >> >> >> >>> 2) There was some weird issue on testing with LibreSSL >>> The output redirect at >>> https://github.com/haproxy/haproxy/blob/bb9da0b8e23c46caab34fe6005b66fa8065fe3ac/.travis.yml#L96 >>> for >>> some reason got stuck the build. I've removed temporarily the output >>> redirects and then it passed. So, it looks like some issue with TravisCI >>> environment. >>> >> >> arm64 is slower, I guess we should add "*travis*_*wait* *30" *to >> build-ssl.sh script >> thank for the hint >> >> >>> >>> In addition I've run the build and tests on one of our machines and all >>> was OK! >>> >>> My question to you is: Are you happy with your current way of testing >>> ARM architectures or you want to add more ? >>> Here are some options: >>> 1) enable TravisCI >>> >> >> already done >> >> https://travis-ci.com/haproxy/haproxy >> >> >>> 2) my company is willing to donate an ARM64 based VM, if you are >>> interested. >>> >> >> I do not work at Haproxy Inc :) >> Willy ? >> >> >>> You will have a SSH access and a user with sudo permissions to install >>> anything that is needed. >>> The spec is aarch64 8 cores CPU 2GHz (Kunpeng), 16GB RAM, 500G disk >>> space and 5M network bandwidth. The OS could be any of CentOS 7.4/7.5/7.6, >>> EulerOS 2.8, Fedora 29, OpenSuse 15.0 and Ubuntu 16.04/18.04. >>> >>> In both cases it will be ARM64. From the earlier mail discussion I >>> understand you would prefer ARM32. >>> >> >> as for myself, I prefer both arm64 and arm32. >> however, both AMD64 and ARM64 are the same 64 bits. both of them are >> little-endian. but you mentioned at least 3 builds with ARM64 failing (we >> have those tests passing on AMD64)! >> >> >> >>> >>> Kind regards, >>> Martin >>> >>
