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/



--