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? > > >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 > > > -- Jose Antonio Lopes Ganeti Engineering 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 Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
