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, since they represent (very) different things. Essentially, they do (very) different tasks. They are, after all, apples and oranges.
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?!
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
Sorry for the failed attempt. This is the repeated attempt. Certainly worth the cause! ;-)
Zoran
---------- Forwarded message ---------- From: Zoran S zoran.stojsavljevic.de@gmail.com Date: Mon, Apr 23, 2018 at 3:54 PM Subject: Re: [Lava-announce] Merging the LAVA code source To: Lava Users Mailman list lava-users@lists.linaro.org Cc: Lava Announce Mailman List lava-announce@lists.linaro.org
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, since they represent (very) different things. Essentially, they do (very) different tasks. They are, after all, apples and oranges.
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?!
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
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
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/
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/
Hi Neil,
Just want to ask a silly question: lava(merged lava-server and lava-dispatcher) is updated to Python3 or not? If not, does development team has a plan to update it to Python3?
Thanks and Regards, Yifan
From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Neil Williams Sent: Tuesday, April 24, 2018 4:02 PM To: Zoran S zoran.stojsavljevic.de@gmail.com Cc: Lava Users Mailman list lava-users@lists.linaro.org; Lava Announce Mailman List lava-announce@lists.linaro.org Subject: Re: [Lava-users] [Lava-announce] Merging the LAVA code source
On 24 April 2018 at 08:21, Zoran S <zoran.stojsavljevic.de@gmail.commailto: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.orgmailto:neil.williams@linaro.org> wrote:
On 23 April 2018 at 14:54, Zoran S <zoran.stojsavljevic.de@gmail.commailto: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.orgmailto: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.orgmailto:neil.williams@linaro.org http://www.linux.codehelp.co.uk/
Lava-announce mailing list Lava-announce@lists.linaro.orgmailto:Lava-announce@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-announce
Lava-users mailing list Lava-users@lists.linaro.orgmailto:Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.orgmailto:neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams ============= neil.williams@linaro.orgmailto:neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On 24 April 2018 at 09:35, Li, Yifan2 yifan2.li@intel.com wrote:
Hi Neil,
Just want to ask a silly question: lava(merged lava-server and lava-dispatcher) is updated to Python3 or not?
Please subscribe to lava-announce - https://lists.linaro.org/pipermail/lava-announce/2018-April/000050.html
If not, does development team has a plan to update it to Python3?
Thanks and Regards,
Yifan
*From:* Lava-users [mailto:lava-users-bounces@lists.linaro.org] *On Behalf Of *Neil Williams *Sent:* Tuesday, April 24, 2018 4:02 PM *To:* Zoran S zoran.stojsavljevic.de@gmail.com *Cc:* Lava Users Mailman list lava-users@lists.linaro.org; Lava Announce Mailman List lava-announce@lists.linaro.org *Subject:* Re: [Lava-users] [Lava-announce] Merging the LAVA code source
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/
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?
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)?! :-)
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/
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/
-
Li, Yifan2 -
Neil Williams -
Zoran S