curtin-dev team mailing list archive

[Olivier Gayot <mp+427671@xxxxxxxxxxxxxxxxxx>]

Thanks for your comment Dan!

Diff comments:

> diff --git a/doc/topics/config.rst b/doc/topics/config.rst
> index ff766c7..9e3eab5 100644
> --- a/doc/topics/config.rst
> +++ b/doc/topics/config.rst
> @@ -363,6 +363,17 @@ If this key is set to the string 'disabled' then curtin will not
>  unmount the target filesystem when install is complete.  This
>  skips unmounting in all cases of install success or failure.
>  
> +**export_resume_data**: *<path to where to export the data needed to resume>*

> This might represent my misunderstanding of the curtin WORKING_DIR concept, but do we need these configs?

The concept is also new to me and my understanding is questionable so I hope my answer is not completely off :)

> If I didn't want to resume, I think I would be using `mktemp -d` each time for a fresh WORKING_DIR instance, and that my default assumption with that DIR would be that I could invoke curtin multiple times and any carry-over info would already be there.

In the current curtin version (i.e., 22.1) `curtin install` ignores and overrides environment variables such as WORKING_DIR. Therefore doing `$ WORKING_DIR=/tmp/working-dir curtin install ...` would do no more than `$ curtin install ...`. If we want to pass such information, it would either go through the config file, or through CLI parameters.

Can we specify the WORKING_DIR in the config file or CLI? Sure! But surely this means determining if we are resuming based on the presence of the WORKING_DIR specified. I remember banning this option, but I don't remember too well why. Maybe it is because of the integration with top dir being removed at the end of the installation.

That said, the idea of specifying the working directory through environment should work if we were willing to invoke the subcommands (e.g., block-meta, extract, curthooks, hook) directly.

$ WORKING_DIR=/tmp/persistent/working-dir
$ OUTPUT_FSTAB=/tmp/persistent/fstab
$ OUTPUT_NETWORK_CONFIG=/tmp/persistent/output-network-config
$ OUTPUT_INTERFACES=/tmp/persistent/output-interfaces
$ OUTPUT_NETWORK_STATE=/tmp/persistent/output-network-state
$ CONFIG=/tmp/persistent/merged-config.yaml
$ TARGET_MOUNT_POINT=/target
$ export WORKING_DIR OUTPUT_NETWORK_CONFIG OUTPUT_INTERFACES OUTPUT_NETWORK_STATE TARGET_MOUNT_POINT

$ curtin block-meta simple
$ curtin extract
$ curtin curthooks
$ curtin hook

^ but this comes with its own set of problems.

> Further, is it a bad idea to just export this resume date normally?

I don't think it would necessarily be a bad thing. I am aware of some limitations though:
 * when the config does not specify `unmount: disabled` (by default, it does not), not only does `curtin install` unmounts /target after finishing installation, but it also recursively removes the "top" directory (which contains WORKING_DIR). So importing the data would fail on subsequent invocation.

> If we just treated this as if export_resume_data was True by default, and import_resume_data was true if the data exists, what would be the result?

I am a bit reluctant to make curtin attempt to resume an install by default but I think it would work.

> +
> +When specified, curtin will export in the file specified the data required to
> +resume the installation and run further stages.
> +
> +**import_resume_data**: *<path from where to import the data needed to resume>*
> +
> +When specified, curtin will consider that the installation has already been
> +initiated and will load the data from the file specified. The target directory
> +will not be expected to be empty.
> +
>  **Example**::
>  
>    install:


-- 
https://code.launchpad.net/~ogayot/curtin/+git/curtin/+merge/427671
Your team curtin developers is subscribed to branch curtin:master.