curtin-dev team mailing list archive

[Dan Bungert <mp+427671@xxxxxxxxxxxxxxxxxx>]

Review: Needs Information

I have a critical design question, the implementation looks entirely fine.

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?
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.

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

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?

> +
> +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.