On 12/13/2013 10:50 AM, Michele Tartara wrote:
On Thu, Dec 12, 2013 at 5:23 PM, Constantinos Venetsanopoulos
<[email protected]> wrote:
Hello Michele,
On 12/12/2013 03:54 PM, Michele Tartara wrote:
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.
OK. That sounds good.
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.
The problem is that you may want to access private repositories
to fetch the image data that you don't want them to be accessible
by untrusted code, or even access a host's local directory. You do
not want to do that from inside the helper VM. Right?
I know that you could do that from the trusted part of the
definition, but again I don't see how this is possible since you
say that trusted and untrusted code will run synchronously.
Another option would be to pass the data over the communication
channel, but I don't think this is the best way to do it either.
I proposed the :image:<URL> option thinking that we could
use the same mechanism that will already get implemented for
the ``self_install`` mode.
What do you think?
My idea was that in such a case the user can use the communication
channel to have the untrusted script wait for the trusted one. So, the
trusted one can download the image and put it on the disk, then it
notifies the untrusted scripts that can go on with the rest of the
work.
But let's hear also what Jose thinks about this, given that he's the
one who's going to work on the implementation of this part.
Please see my comments on Jose's reply.
Thanks,
Constantinos
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.
Yes, I also think we should have that in any case.
Thanks,
Constantinos
Thanks,
Michele
Cheers,
Michele
