On Thu, Dec 12, 2013 at 5:23 PM, Constantinos Venetsanopoulos <[email protected]> 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?
My idea was that in such a case the user can use the communication channel to have the untrusted script wait for the trusted one. So, the trusted one can download the image and put it on the disk, then it notifies the untrusted scripts that can go on with the rest of the work. But let's hear also what Jose thinks about this, given that he's the one who's going to work on the implementation of this part. > > >> 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 >> > 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
