Closed msimonin closed 5 years ago
I merged this in EnOSlib : https://gitlab.inria.fr/discovery/enoslib/commit/c66bddbbab3d2316442e1e4a39c88d28048136e4
In short, I suggest to generate a working_dir
on the frontend (e.g using the current directory) to ease the use of the build process for the VMonG5K provider.
I also merged this: https://gitlab.inria.fr/discovery/enoslib/commit/b2ed4b3e33fd3c5cdbf9f3bf65a6c01616472238
So, I suggest to generate strategy=copy
so that, for vmong5k, the disk image is directly reusable (without the qemu-img commit step).
We can also add a post build option to commit the results:
vagrant package ...
for vagranttgz-g5k ...
for g5k
Rationale:
Note that, for 1., another solution would be to use a persistent registry or a registry backed by a rbd (ceph on g5k only). These solutions don't seem to be convenient for most users and difficult to setup in a dynamic environment such as G5K.
Action Items:
enos build
incli.py
tasks.py
inspired by https://gitlab.inria.fr/discovery/kenan/blob/1d0bc663ff0a41b9c41e08ea3facbaae1c2c2ac2/kenan/provider/static/task.py#L115-126get_build_conf
in each enos provider so that the instruction on tasks.py build the complete conf and then calldeploy
.