On 10 June 2016 at 18:53, Sandeep Chawla sandeep@cyngn.com wrote:
Neil, Thanks for the explanation on the limitations of Lava extensions.
I too have a lava extension that I wrote.
It added a few XML RPC apis to deploy data to the lava server at /usr/share/lava-server/static/
That is a django directory for UI files, templates, css, javascript and the like. Various django utility programs are able to take ownership of the those locations.
It makes no sense to use that for downloads to a device when that should be happening using lava-dispatcher. You risk breaking the UI and it's an abuse of the https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard which Debian follows.
The tmp/ directory is /var/lib/lava/dispatcher/tmp/ - if you're using the example apache config from the source.
The purpose was to deploy device images on the server so that its faster to use in multiple jobs
There's no point having those files on the server - the files need to be on the dispatcher. Even if you use a single machine as both, you must still use the dispatcher directories.
Is there another way the builds/binaries can be deployed to the server ?
Use a caching proxy (e.g. squid) or a local fileserver to make files more easily available to the dispatcher. These files have no business being anywhere where the server would find them.
If its ok, I can add those patches to lava
Sorry - no. That would not be appropriate or suitable.
(Looks like removing the extensions was actually a good way to highlight issues with how things need to actually work. I'm glad we removed it - should probably have done so earlier.)
LAVA instances require admins - in return, LAVA can improve efficiency by asserting some things about how an instance should be administered. It helps everyone if all instances are maintained in standard ways - otherwise we cannot help you when bugs appear due to a mistake in local administration. This is a particular problem with single-user instances where the user is also the LAVA admin, system admin, test writer and developer. These are not small roles - busy instances need a medium sized team to operate and maintain, without considering any development.
With V2, the work for the test writers and admins is both changing and increasing as a deliberate change to make LAVA more transparent.
There is a lot of help out there for administering Debian-based systems and how to adopt the best practices. LAVA is complex and although we are making some parts of it easier, that simply puts more emphasis on the test writers and the admins. This is one reason why only Debian is currently supportable - we just don't have the resources to run a parallel lab on a different OS to be confident in advising on administration and maintenance. (It would need to be just as busy as validation.linaro.org, with a similar set and number of devices and that quickly becomes impractical.)
The more that instances diverge from best practice, the more likely it is that fixes and improvements in LAVA will break those instances - things just suddenly stop working. Yet, every instance is different, so LAVA cannot and will not do this work for you. There is room in V2 for a very large range of fully supportable instances.