Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
On Fri, Jun 14, 2019 at 01:34:34AM +0500, ??? wrote: > well, I am going to play with cron jobs say "after haproxy-2.0 release" OK, that works for me! > as for being good citizens, when I look at > > https://travis-ci.org/openssl/openssl/builds > > (25k builds 1hr each ), I'm sure we are good citizens. really :) Indeed, it could be said we have some margin :-) Willy
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
пт, 14 июн. 2019 г. в 01:27, Willy Tarreau : > On Thu, Jun 13, 2019 at 10:28:19PM +0500, ??? wrote: > > > > or we can drop boringssl build in favour of Manu :) > > > > > > I suggest to drop BoringSSL. It's not intended to be used outside of > > > Google anyway. So if it breaks the user gets to keep both pieces and > can > > > report the issue in the tracker or on the list. > > > > > > > recently, I've found that if you wish to specify custom cipher suites in > > CloudFlare, you need to use BoringSSL syntax. > > so there's some use of it. same for LibreSSL > > I'd say that I'm in favor of testing what doesn't add effort nor cost. > At the moment BoringSSL represents a cost for the infrastructure and the > build time, but if we can use a cron job with it it should be a good > option. In this case we could possibly do the same with the least > common combinations (e.g. linux+no option, older libressl builds) and > be good citizens with Travis and save on build time. > > Just a suggestion anyway, I don't have strong feelings on this. > well, I am going to play with cron jobs say "after haproxy-2.0 release" as for being good citizens, when I look at https://travis-ci.org/openssl/openssl/builds (25k builds 1hr each ), I'm sure we are good citizens. really :) > > Willy >
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
On Thu, Jun 13, 2019 at 10:28:19PM +0500, ??? wrote: > > > or we can drop boringssl build in favour of Manu :) > > > > I suggest to drop BoringSSL. It's not intended to be used outside of > > Google anyway. So if it breaks the user gets to keep both pieces and can > > report the issue in the tracker or on the list. > > > > recently, I've found that if you wish to specify custom cipher suites in > CloudFlare, you need to use BoringSSL syntax. > so there's some use of it. same for LibreSSL I'd say that I'm in favor of testing what doesn't add effort nor cost. At the moment BoringSSL represents a cost for the infrastructure and the build time, but if we can use a cron job with it it should be a good option. In this case we could possibly do the same with the least common combinations (e.g. linux+no option, older libressl builds) and be good citizens with Travis and save on build time. Just a suggestion anyway, I don't have strong feelings on this. Willy
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
чт, 13 июн. 2019 г. в 22:25, Tim Düsterhus : > Ilya, > Willy, > > Am 13.06.19 um 19:11 schrieb Илья Шипицин: > > чт, 13 июн. 2019 г. в 22:07, Willy Tarreau : > > > >> On Thu, Jun 13, 2019 at 10:01:52PM +0500, ??? wrote: > >>> "everything enabled" is impossible. 51degrees may be enabled in two > >>> mutually exclusive ways. it doubles number of build configurations. > >> > >> It's not big deal, the haproxy-specific code remains the same and only > >> the 51D-specific one differs, so once Ben tells you "this one or that > >> one is more relevant", we stick to it and that's fine. > > I agree with Willy here. The dummy library primarily exists to make sure > the appropriate functiions exist to link against. Just select one (I > guess the 'pattern' based one) and we should be good. The dummy library > is an approximation anyway. > > >> Thinking about the boringssl mess which takes ages to rebuild, I don't > >> know if it's possible to script some form of "once every X times" or > >> alternatively "build only when random()%10==0". That could also help > >> preserving travis resources while still reporting once in a while if > >> we broke anything there. I'd also say that boringssl is constantly > >> built by Manu, I wouldn't be surprised if he detected our breakage > >> faster than travis :-) > >> > > > > there are couple of options: > > > > 1) we can use ccache (and cache it between builds). however, ccache is > > buggy itself, I turned it "off" already for several projects > > > > 2) we can setup special "cron" builds, for example it will build haproxy > + > > boringssl once a day. > > > > or we can drop boringssl build in favour of Manu :) > > I suggest to drop BoringSSL. It's not intended to be used outside of > Google anyway. So if it breaks the user gets to keep both pieces and can > report the issue in the tracker or on the list. > recently, I've found that if you wish to specify custom cipher suites in CloudFlare, you need to use BoringSSL syntax. so there's some use of it. same for LibreSSL > > Best regards > Tim Düsterhus >
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
Ilya, Willy, Am 13.06.19 um 19:11 schrieb Илья Шипицин: > чт, 13 июн. 2019 г. в 22:07, Willy Tarreau : > >> On Thu, Jun 13, 2019 at 10:01:52PM +0500, ??? wrote: >>> "everything enabled" is impossible. 51degrees may be enabled in two >>> mutually exclusive ways. it doubles number of build configurations. >> >> It's not big deal, the haproxy-specific code remains the same and only >> the 51D-specific one differs, so once Ben tells you "this one or that >> one is more relevant", we stick to it and that's fine. I agree with Willy here. The dummy library primarily exists to make sure the appropriate functiions exist to link against. Just select one (I guess the 'pattern' based one) and we should be good. The dummy library is an approximation anyway. >> Thinking about the boringssl mess which takes ages to rebuild, I don't >> know if it's possible to script some form of "once every X times" or >> alternatively "build only when random()%10==0". That could also help >> preserving travis resources while still reporting once in a while if >> we broke anything there. I'd also say that boringssl is constantly >> built by Manu, I wouldn't be surprised if he detected our breakage >> faster than travis :-) >> > > there are couple of options: > > 1) we can use ccache (and cache it between builds). however, ccache is > buggy itself, I turned it "off" already for several projects > > 2) we can setup special "cron" builds, for example it will build haproxy + > boringssl once a day. > > or we can drop boringssl build in favour of Manu :) I suggest to drop BoringSSL. It's not intended to be used outside of Google anyway. So if it breaks the user gets to keep both pieces and can report the issue in the tracker or on the list. Best regards Tim Düsterhus
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
чт, 13 июн. 2019 г. в 22:07, Willy Tarreau : > On Thu, Jun 13, 2019 at 10:01:52PM +0500, ??? wrote: > > "everything enabled" is impossible. 51degrees may be enabled in two > > mutually exclusive ways. it doubles number of build configurations. > > It's not big deal, the haproxy-specific code remains the same and only > the 51D-specific one differs, so once Ben tells you "this one or that > one is more relevant", we stick to it and that's fine. > > Thinking about the boringssl mess which takes ages to rebuild, I don't > know if it's possible to script some form of "once every X times" or > alternatively "build only when random()%10==0". That could also help > preserving travis resources while still reporting once in a while if > we broke anything there. I'd also say that boringssl is constantly > built by Manu, I wouldn't be surprised if he detected our breakage > faster than travis :-) > there are couple of options: 1) we can use ccache (and cache it between builds). however, ccache is buggy itself, I turned it "off" already for several projects 2) we can setup special "cron" builds, for example it will build haproxy + boringssl once a day. or we can drop boringssl build in favour of Manu :) > > Willy >
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
On Thu, Jun 13, 2019 at 10:01:52PM +0500, ??? wrote: > "everything enabled" is impossible. 51degrees may be enabled in two > mutually exclusive ways. it doubles number of build configurations. It's not big deal, the haproxy-specific code remains the same and only the 51D-specific one differs, so once Ben tells you "this one or that one is more relevant", we stick to it and that's fine. Thinking about the boringssl mess which takes ages to rebuild, I don't know if it's possible to script some form of "once every X times" or alternatively "build only when random()%10==0". That could also help preserving travis resources while still reporting once in a while if we broke anything there. I'd also say that boringssl is constantly built by Manu, I wouldn't be surprised if he detected our breakage faster than travis :-) Willy
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
On Thu, Jun 13, 2019 at 06:28:09PM +0200, Tim Düsterhus wrote: > I'm unhappy with that patch: > > a) It makes unrelated changes to the OpenSSL version (that should be a > separate patch). I'm also at fault here because I saw this and didn't bother that much, being busy on other stuff :-/ > b) It removed the "gcc without any flags" build and instead replaced it > with "gcc with all flags, but a separate 51d from all others". I didn't notice this one. > I consider the "X without any flags" very useful to detect missing > preprocessor guards and code accidentally relying on a build flag. I agree, and in "without any flags" I'd even disable threads as we broke the thread-less builds quite a few times in the past. > I suggest to draft a real plan on how the tests should proceed, taking > into account to not abuse Travis' free service, before making any more > changes to the configuration. > > I suggest: > > - Linux + gcc with everything disabled. > - Linux + clang with everything disabled. > - Linux + gcc with everything enabled (incl. device detection and > prometheus). > - Linux + clang with everything enabled (incl. device detection and > prometheus). > - Linux + gcc with ONLY SSL enabled for each of the various SSL libraries. > - Mac + clang with everything from core HAProxy enabled (no device > detection and prometheus). > - Windows with everything from core HAProxy enabled (no device > detection and prometheus). > > That way the edge cases (everything enabled and everything disabled) are > systematically tested. The less important platforms (Windows / Mac; > everything that is not the default OpenSSL) get some basic exposure > without skyrocketing build times, because things are redundantly tested > (e.g. no need to test compression with each SSL library, that's why only > SSL should be enabled for those). I tend to think that this proposal is quite reasonable. Willy
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
чт, 13 июн. 2019 г. в 21:28, Tim Düsterhus : > Ilya, > > (removed Ben and Christopher from Cc, as this no longer about 51d) > > Am 13.06.19 um 17:01 schrieb Илья Шипицин: > > please find "travis-ci + 51degree" patch attached. > > I'm unhappy with that patch: > > a) It makes unrelated changes to the OpenSSL version (that should be a > separate patch). > b) It removed the "gcc without any flags" build and instead replaced it > with "gcc with all flags, but a separate 51d from all others". > > I consider the "X without any flags" very useful to detect missing > preprocessor guards and code accidentally relying on a build flag. > > I'm aware that there still is "clang without any flags", but there > really should be "clang without any flags" and "gcc without any flags" > as history has shown that they sometimes do things differently. > > All in all the Travis configuration is pretty unorganized by now. It > "randomly" mashes together various options so that everything is somehow > tested at least once, but there is no real logic behind it. As an > example: Why is the Prometheus test added to LibreSSL 2.7.5? Why not > BoringSSL? > > I suggest to draft a real plan on how the tests should proceed, taking > into account to not abuse Travis' free service, before making any more > changes to the configuration. > > I suggest: > > - Linux + gcc with everything disabled. > - Linux + clang with everything disabled. > - Linux + gcc with everything enabled (incl. device detection and > prometheus). > "everything enabled" is impossible. 51degrees may be enabled in two mutually exclusive ways. it doubles number of build configurations. > - Linux + clang with everything enabled (incl. device detection and > prometheus). > - Linux + gcc with ONLY SSL enabled for each of the various SSL > libraries. > - Mac + clang with everything from core HAProxy enabled (no device > detection and prometheus). > - Windows with everything from core HAProxy enabled (no device > detection and prometheus). > > That way the edge cases (everything enabled and everything disabled) are > systematically tested. The less important platforms (Windows / Mac; > everything that is not the default OpenSSL) get some basic exposure > without skyrocketing build times, because things are redundantly tested > (e.g. no need to test compression with each SSL library, that's why only > SSL should be enabled for those). > > Best regards > Tim Düsterhus >
Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
чт, 13 июн. 2019 г. в 21:28, Tim Düsterhus : > Ilya, > > (removed Ben and Christopher from Cc, as this no longer about 51d) > > Am 13.06.19 um 17:01 schrieb Илья Шипицин: > > please find "travis-ci + 51degree" patch attached. > > I'm unhappy with that patch: > > a) It makes unrelated changes to the OpenSSL version (that should be a > separate patch). > b) It removed the "gcc without any flags" build and instead replaced it > with "gcc with all flags, but a separate 51d from all others". > > I consider the "X without any flags" very useful to detect missing > preprocessor guards and code accidentally relying on a build flag. > > I'm aware that there still is "clang without any flags", but there > really should be "clang without any flags" and "gcc without any flags" > as history has shown that they sometimes do things differently. > > All in all the Travis configuration is pretty unorganized by now. It > "randomly" mashes together various options so that everything is somehow > tested at least once, but there is no real logic behind it. As an > example: Why is the Prometheus test added to LibreSSL 2.7.5? Why not > BoringSSL? > I'd like to add PCRE2 and SLZ to future builds also, I'd like to add more clang sanitizers (currently we use only ASAN and it is extremely useful) also, I'm not sure how many LibreSSL versions do we actually need (I taken three of them) as for gcc, I'm not happy with it's sanitizers, but maybe I'll add some later. that's why we have much more clang builds. also, I'm not very happy with current BoringSSL caching (it caches only downloads, and it seems that S3 cache is almost the same as clean checkout) > > I suggest to draft a real plan on how the tests should proceed, taking > into account to not abuse Travis' free service, before making any more > changes to the configuration. > sure. I do not mind > > I suggest: > > - Linux + gcc with everything disabled. > - Linux + clang with everything disabled. > - Linux + gcc with everything enabled (incl. device detection and > prometheus). > - Linux + clang with everything enabled (incl. device detection and > prometheus). > - Linux + gcc with ONLY SSL enabled for each of the various SSL > libraries. > - Mac + clang with everything from core HAProxy enabled (no device > detection and prometheus). > - Windows with everything from core HAProxy enabled (no device > detection and prometheus). > > That way the edge cases (everything enabled and everything disabled) are > systematically tested. The less important platforms (Windows / Mac; > everything that is not the default OpenSSL) get some basic exposure > without skyrocketing build times, because things are redundantly tested > (e.g. no need to test compression with each SSL library, that's why only > SSL should be enabled for those). > > Best regards > Tim Düsterhus >
Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)
Ilya, (removed Ben and Christopher from Cc, as this no longer about 51d) Am 13.06.19 um 17:01 schrieb Илья Шипицин: > please find "travis-ci + 51degree" patch attached. I'm unhappy with that patch: a) It makes unrelated changes to the OpenSSL version (that should be a separate patch). b) It removed the "gcc without any flags" build and instead replaced it with "gcc with all flags, but a separate 51d from all others". I consider the "X without any flags" very useful to detect missing preprocessor guards and code accidentally relying on a build flag. I'm aware that there still is "clang without any flags", but there really should be "clang without any flags" and "gcc without any flags" as history has shown that they sometimes do things differently. All in all the Travis configuration is pretty unorganized by now. It "randomly" mashes together various options so that everything is somehow tested at least once, but there is no real logic behind it. As an example: Why is the Prometheus test added to LibreSSL 2.7.5? Why not BoringSSL? I suggest to draft a real plan on how the tests should proceed, taking into account to not abuse Travis' free service, before making any more changes to the configuration. I suggest: - Linux + gcc with everything disabled. - Linux + clang with everything disabled. - Linux + gcc with everything enabled (incl. device detection and prometheus). - Linux + clang with everything enabled (incl. device detection and prometheus). - Linux + gcc with ONLY SSL enabled for each of the various SSL libraries. - Mac + clang with everything from core HAProxy enabled (no device detection and prometheus). - Windows with everything from core HAProxy enabled (no device detection and prometheus). That way the edge cases (everything enabled and everything disabled) are systematically tested. The less important platforms (Windows / Mac; everything that is not the default OpenSSL) get some basic exposure without skyrocketing build times, because things are redundantly tested (e.g. no need to test compression with each SSL library, that's why only SSL should be enabled for those). Best regards Tim Düsterhus
