Hello, On Thu, 10 Jan 2013 00:43:42 +0100 Alexander Sack <[email protected]> wrote:
[] > > CBuild make that pretty easy - it has several levels of indirection > > for routing builds: there're "spawn queues" which correspond to a > > specific product, which fans out to several "scheduler queues" > > which correspond to specific board type, from which it goes to an > > available board of that type. So, we'll just add symlink(s) to > > spawn queue to include a LAVA queue, and all should work > > automagically (synthetically tested on a sandbox, but again, need > > to see how well it works with real CBuild load and build set). > > > > cool. thanks a bunch. sounds very good then. Last question: do we > create a staging UI/dashboard instance that consumes the results/logs > from the LAVA produced results to ensure that the complete solution is > equivalent as well? I assume "staging UI/dashboard instance" of a CBuild web frontend itself, because as we decided at last Connect, "episode 1" will be centered around bringing LAVA as a backend to CBuild, and keep using its frontend as is. So yes, that's exactly what's left on development front of things - to bring build logs from LAVA back to CBuild, so CBuild advanced functionality (build/benchmark diff viewer, etc.) worked. Stevan and Milo work on that as we speak, using http://ec2-54-243-13-36.compute-1.amazonaws.com/helpers/ as a staging server. > -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
