On Mon, 10 Dec 2018 at 20:16, Neil Williams <neil.williams at linaro.org> wrote:
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.
Thanks for pointing that out, Neil. I got the point, that the Apache server has to serve a static site during the restore process.
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.)
Thanks, the CLI operations are very helpful for automating the process. However, the docs say that all devices in "Reserved" state have to have their "current job" cleared. I can use "lava-server manage devices details" to check whether this field is actually set. There is no command to modify it, though. Seems like using the Python API is the only way to go here, right? The same applies to setting "Running" jobs to "Cancelled".
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
On Tue, 11 Dec 2018 at 11:28, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
On Mon, 10 Dec 2018 at 20:16, Neil Williams <neil.williams at linaro.org> wrote:
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.
Thanks for pointing that out, Neil. I got the point, that the Apache server has to serve a static site during the restore process.
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.)
Thanks, the CLI operations are very helpful for automating the process. However, the docs say that all devices in "Reserved" state have to have their "current job" cleared. I can use "lava-server manage devices details" to check whether this field is actually set. There is no command to modify it, though. Seems like using the Python API is the only way to go here, right? The same applies to setting "Running" jobs to "Cancelled".
https://git.lavasoftware.org/lava/lava/merge_requests/273
This should get into the upcoming 2018.12 release.
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
lava-users@lists.lavasoftware.org
-
Neil Williams -
Tim Jaacks