On Fri, Dec 13, 2013 at 2:01 PM, Constantinos Venetsanopoulos <[email protected]> wrote: > 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? >
Just a lot more parsing required. And, the fact that the original idea is not to have os scripts at all, so whe should also support one more option with respect to the ones you are listing, which is: -o image:<URL> But I think it's perfectly doable. Cheers, 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
