On Fri, Dec 13, 2013 at 2:06 PM, Michele Tartara <[email protected]> wrote: > 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,
*for the ``self_install`` mode* > so we 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 -- 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
