On 24 April 2018 at 14:09, Zoran S zoran.stojsavljevic.de@gmail.com wrote:
Sorry, but this was only a notification of a decision already taken and
implemented by
the development team. The change itself was not and is not up for
discussion on this list.
Sorry to be (brutal) honest with you and Linaro. ;-)
I (sincerely) expect in The Future you/Linaro will be MUCH (much) more serious with some responsibilities to this list, and to your/Linaro Lava architecture?
This is a user list. It is not a development list.
I remain unconvinced that you, personally, understand the LAVA architecture and design let alone our aims and objectives.
Or... I expect out there that will be some more serious people/companies with some more serious testing environment. I hope for this to happen (competition is All Good, don't you think)! ;-)
Do we have agreement here (I truly hope so)?! :-)
Not really.
LAVA is absolutely serious about automation validation. I disagree with all the rest of your assumptions.
Zoran Stojsavljevic
On Tue, Apr 24, 2018 at 10:02 AM, Neil Williams neil.williams@linaro.org wrote:
On 24 April 2018 at 08:21, Zoran S zoran.stojsavljevic.de@gmail.com
wrote:
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.
Sorry, but this was only a notification of a decision already taken and implemented by the development team. The change itself was not and is
not up
for discussion on this list.
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/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
lava-announce@lists.lavasoftware.org
-
Neil Williams