On Mon, 15 Oct 2018 at 10:46, Tim Jaacks email@example.com wrote:
is there a way of setting tags for existing devices via the command line? The "lava-server manage devices update" command does not have a "--tags" parameter, as the "lava-server manage devices add" has.
This support has now been implemented as a dedicated lava-server manage command, without recourse to the shell. This support will be included in the next release.
Tags can currently only be set for devices when the device is added. When the update command was created, manipulating tags was out of scope. If you fancy working on that support, that would be handy.
For everyone interested in this feature: I have found a much more flexible solution using the "lava-server manage shell" command. This provides a Python shell offering all possible modifications using the LAVA Python API.
It is intended for developers only - you need a good understanding of the underlying code base to make useful changes here.
There is NO support if you get things wrong in the shell. It is trivially easy to catastrophically destroy your entire database in this shell. Access to this shell should NEVER be given except to developers and those able to reconstruct the effects of their mistakes. It is currently restricted to users who have shell access to the master *and* sudo privileges as well. That group of people should always be very tightly regulated in any production lab.
Always have a known working backup before invoking the shell.
from lava_scheduler_app.models import Device, Tag device = Device.objects.get(hostname="mydevice") tag = Tag.objects.get_or_create(name="mytag") device.tags.add(tag)
Tags can be removed similarly, using "device.tags.remove(tag)".
You're missing the (implicit) handling inside the shell - the device still needs to be saved.
Python script files can be passed to the lava-server command using standard Linux redirection:
lava-server manage shell < myscript.py
I did not find this anywhere in the LAVA docs. Is there a reason for that?
It is massively powerful and therefore massively dangerous. It is the proverbial sledgehammer being used to crack a nut - massive overkill and massive risk of data loss when misused.
I am using this Python API now with Ansible for LAVA device creation as well as for users, groups, permissions and authentication tokens. Works reliably.
There is nor will there ever be any assurance that shell commands which work with one release of LAVA will not completely trash your instance with the some later release of LAVA. It's not just that these commands might fail, these commands can easily silently continue yet silently trash the instance at the same time.
It is also likely that changes made in the shell could be undone, mangled or corrupted by migrations required during package upgrades, running daemons, callbacks and other tasks within LAVA.
Automated use of this shell is highly dangerous. We will disown any problems caused by the use of this shell - use it at your own risk.
Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 firstname.lastname@example.org www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz _______________________________________________ Lava-users mailing list Lavaemail@example.com https://lists.linaro.org/mailman/listinfo/lava-users