On 12/13/2013 12:53 PM, Michele Tartara wrote:
On Fri, Dec 13, 2013 at 11:36 AM, Constantinos Venetsanopoulos
<[email protected]> wrote:
On 12/13/2013 11:40 AM, Jose A. Lopes wrote:
On Thu, Dec 12, 2013 at 06:23:57PM +0200, Constantinos Venetsanopoulos
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?
If I understand you correctly, you want to pass in an image to be used
as the user instance's disk, then boot the helper VM with the user
instance's disk mounted and run the untrusted OS scripts inside the
helper VM, while at the same time the trusted OS scripts run on the
host. Is this correct?
Exactly.
And I think it could be the same codepath as in ``self_install``,
if the admin specifies the :image:<URL> option after the name
of the definition.
If the :image:<URL> is set, then the second disk of the instance
(since the first will contain the virtual appliance) will not be empty,
but rather contain the requested image data. I think it's much
simpler than having the scripts getting synchronized and pass
let's say 10GB of a Windows Image data over the communication
channel.
What do you think?
I like the idea in general, but this creates an issue: how can you
specify both an image and an os-installation script to be used? My
original design used two separate parameters for that, but then it was
suggested that they be united in a single one, "-o", with or without
the "image:" prefix.
Isn't it possible to do:
-o my_definition+default:image:<URL>
will fetch and extract the image (for ``self_install`` and ``install``).
-o my_definition+default
will not fetch and extract the image (for ``self_install`` and ``install``)
Am I missing something?
Regards,
Constantinos
Thanks,
Michele
