On Thu, Dec 12, 2013 at 1:08 PM, Constantinos Venetsanopoulos <[email protected]> wrote: > Hello Michele, > > the design looks good. Just two points: > > 1. There is no description in the doc w.r.t. the location that the > virtual appliance is going to be stored, and how is it going to be > spawned. I guess the disk-to-be-customized of the instance in > ``install`` mode will have the disk template defined by the user. > However, how will the disk containing the virtual appliance get > provisioned? In a QCOW manner maybe, since we want it to be fast > and since it is going to be read-only?
I left out the location and file format of the virtual appliance as I considered them as implementation details, that have to appear in the documentation, rather than in the design. QCOW sounds indeed as a good option, and probably /srv/ganeti/helper_vm/ (or something similar) would be a good choice. > 2. More importantly, I don't see a way how you could do the following: > dd a predefined OS image onto the disk-to-get-customized of the > instance (like the one in ``self_install`` mode) and then spawn > the virtual appliance and continue with the ``install`` procedure. > How do you plan to support the above scenario which IMHO is going > to be the most common case? Maybe we should have the :image:<URL> > option in ``install`` mode too? The idea is that in ``install`` mode things work more or less as they do now, with OS installation scripts doing whatever they like, with the additional safety of being run inside a VM, so it's up to the scripts to decide how to write the image on the disk. What is not explicit in the design, and that could be indeed added, is to specify a location, part of the metadata, where the URL of the image appears, so that the scripts can actually fetch it and use it. Thanks, Michele -- Google Germany GmbH Dienerstr. 12 80331 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores
