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