On 10 June 2016 at 00:15, Konrad Scherer Konrad.Scherer@windriver.com wrote:
Hello,
For the 2016.4 release I had created a custom LAVA extension to add 2 commands and 2 xmlrpc methods. The extension mechanism was very convenient. All I had to do was install an egg on the system and restart the lava service. When I upgraded to 2016.6 the extension did not work due to commit b6fd045cc2b320ed34a6fefd713cd0574ed7b376 "Remove the need for extensions".
I was not able to find a way to add my extension to INSTALLED_APPS and register the xmlrpc methods without modifying settings/common.py and urls.py. I looked through common.py and distro.py and could not find support in settings.conf for extensions. I also looked for a local_settings import which is referenced on the Internet as a common way to extend django, but did not find it. If there is a way to extend LAVA without modifying the LAVA python code, please let me know and I will be happy to send in a documentation patch.
It would have been nice if functionality such as the extension mechanism, which is part of the external interface of LAVA, had gone through a deprecation cycle. A reworked demo app showing how the new extension mechanism works would have also been helpful.
Sorry about that - the extensions support was removed amongst a lot of other changes to (start to) streamline the codebase and remove historical or legacy code, particularly at the lower levels where it affects all operations. It's part of the ongoing work for LAVA V2, including the upcoming move to require django 1.8. The current migration is complex and code sometimes needs to be removed or adapted. Extensions cannot be tested as part of the development of LAVA, so it is preferable for changes to be made inside the LAVA codebase and extensions have therefore been removed. There wasn't a deprecation cycle for this step, so our apologies for that.
The migration to LAVA V2 increases the number and types of methods available to export data from LAVA - XML-RPC, REST api and ZMQ. The intention is that customisation will take place in custom frontends which abstract the generic LAVA data to make it relevant for particular teams. If there are extra calls which need to be exported, these need to be contributed to the LAVA codebase so that these can be tested and maintained.
We've had significant problems when lava has been mixed with pip installs or third-party eggs - introducing instability, failures and errors. The use of any non-packaged code with lava, other than through the existing API, is not supported.
Please talk to us about what the commands and methods were trying to achieve - we are open to having more calls available as long as the code being used can be properly tested within the codebase.