Not true. The master produces the configuration which is fed to the dispatcher - the two are very directly tied at the level of what devices can support and how that support is used by test jobs. Changes and fixes in the device-type templates will change how the dispatcher uses the code support to control the device.
With all due respect, Sir, I would not agree/would disagree to by your/Linaro's currently presented architecture. Lava-server, as master, has some/most generic tasks to do. Accent here to GENERIC!
Or, is there some Master task which is NOT generic?!
Web-interface, database (postgress-sql), scheduler... All of these are generic components, don't you agree? Or they depend out of Slave behind the generic ZMQ???
So, in order to maintain the correctness of the overall architecture, I would say that Lava-server should be the GENERIC component maintained. It has nothing to do (per say) with the DUTs, which are HW dependent tested platforms.
In contrary, Lava-dispatcher has some HW/DUT dependencies. And, you should have one master per one or more slaves, and each slave will do the specific HW dependent job. Dependent out of HW platform which is under the test. Dispatcher is directly tied to DUT HW platforms it manages!
And... Very correct DMZ for these two entities is, actually, generic ZMQ protocol. I very like this idea! :-)
The two have always been maintained by the same team and in a tightly integrated manner.
I would say, this is rather bogus argument to defend the wrong architecture. Architecture does NOT depend who does maintain it (the same of different teams), but does depend on the correct scalability requirements, in such the case! ;-)
Zoran _______
On Mon, Apr 23, 2018 at 4:06 PM, Neil Williams neil.williams@linaro.org wrote:
On 23 April 2018 at 14:54, Zoran S zoran.stojsavljevic.de@gmail.com wrote:
lava-server and lava-dispatcher have been merged into a single source repository - lava
If you ask me, this is the (very) questionable decision. Indeed!?
lava-server is the front-end manager of the whole Lava test environment, while lava-dispatcher is the back-end. Connected/splitted by ZMQ protocol. And... They should be separately maintained
Not true. The master produces the configuration which is fed to the dispatcher - the two are very directly tied at the level of what devices can support and how that support is used by test jobs. Changes and fixes in the device-type templates will change how the dispatcher uses the code support to control the device. The two have always been maintained by the same team and in a tightly integrated manner.
, since they represent (very) different things. Essentially, they do (very) different tasks. They are, after all, apples and oranges.
The bulk of the expected work from here on is Device Integrations. Each new device integration typically involves changes to the dispatcher to support new deployment / boot methods as well as new templates for the device configuration. Combining the codebase allows those changes to be more easily verified because the output of the device configuration templates can be fed directly to the lava-dispatcher code changes in the dispatcher unit tests.
Previously, this has resulted in static device configuration files in the dispatcher unit tests and that has caused problems.
In other words, if you update/buy advanced/more expensive apples, you also force testers to update for nuthin'/buy for the loss the same oranges, they had before?!
Not true. the packages are built from a single source package. That does not mean that the binary packages need to be updated on the actual instances.
Up until now, lava-server has always depended on the latest version of lava-dispatcher. That specific dependency is being removed as part of this change.
Nevertheless, the principle remains that the lava-master and lava-slave should be updated together so that the device configuration is in line with the dispatcher support. See compatibility settings in the documentation.
https://lava.codehelp.co.uk/static/docs/v2/simple-admin.html#index-5
Is it the wise decision???
Two cents worth lamenting/analysis, Zoran _______
On Thu, Apr 19, 2018 at 3:41 PM, Neil Williams neil.williams@linaro.org wrote:
This is for particular note for developers as it changes the way that reviews happen.
If you've noticed a few reviews being abandoned, this is why.
lava-server and lava-dispatcher have been merged into a single source repository - lava
lava-coordinator will follow in time, to ease the update of lava-coordinator to Python3.
This will, in future, allow easier testing of device integrations by allowing the lava_scheduler_app unit tests to be linked to the lava_dispatcher unit tests and have a single review which adds both sides of the device support.
There will be a lot of testing, as normal, so staging will be moving to packages built from the new source repository tree.
The old lava-server.git and lava-dispatcher,git repositories will become read-only and will get no further code changes. All changes will be done in lava.git
https://git.linaro.org/lava/lava.git/
The documentation will be updated over the next few days.
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
Lava-announce mailing list Lava-announce@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-announce
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/