On Mon, 10 Dec 2018 at 16:45, Tim Jaacks tim.jaacks@garz-fricke.com wrote:

Hello everyone,

I am trying to implement a backup and restore routine for our LAVA server, based on the documentation:

https://validation.linaro.org/static/docs/v2/admin-backups.html#restoring-a-...

The creation of the backup is straight-forward. I have problems with the order of the proposed restore steps, though.

Step 6 is "Stop all LAVA services". However, afterwards in step 7 it says "Make sure that this instance actually works by browsing a few (empty) instance pages." This should obviously be done before, right?

Yes, there is a problem there - thanks for catching it. I think the bulk of the page dates from the last stages of the migration when V1 data was still around. I'll look at an update of the page tomorrow. Step 7 is a sanity check that the install of the empty instance has gone well, Step 9 is to ensure that the newly restored database is put into maintenance as soon as possible to prevent any queued test jobs from attempting to start. The critical element of Step 9 is to ensure that the lava-master service is stopped.

The emphasis of the section is on ensuring that the instance only serves a "Maintenance" page, e.g. the default Debian "It works!" apache page, to prevent access to the instance during the restore.

Accessing the UI would involve having an alternative way to serve the pages. If that can be arranged, just for admins, (e.g. by changing the external routing to the box or redirecting DNS temporarily) then the UI on the instance can be used with the change that the lava-server-gunicorn service does not need to be stopped (because access has been redirected). Other services would be stopped. However, this would involve a fair number of apache config changes, so is best left to those admins who have such config already on hand.

The operations can be done from the command line and that's probably best for these docs.

Step 7 can be replaced by:

lava-server manage check --deploy

Step 9 can be replaced by looping over:

lava-server manage devices update --health MAINTENANCE --hostname ${HOSTNAME}

or, if there are a lot of devices:

lava-server manage maintenance --force

(This maintenance helper has been fixed in master - soon to be 2018.12 - so older versions would use the first command & loop.)

The actual problem is that step 9 says "In the Django administration interface, take all devices which are not Retired into Offline". This cannot be an ordering issue, because the LAVA services actually must not be available during these modifications. How do I use the Django admin interface, while all LAVA services are stopped?

I'll look at changing the page to use CLI operations for steps 7 and 9. Some labs can do the http redirect / routing method but the detail of that is probably not in scope for this page in the LAVA docs. I'll add a note that admins have that choice but leave it for those admins to implement.

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 tim.jaacks@garz-fricke.com www.garz-fricke.com WE MAKE IT YOURS!

Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

---

Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users