On Fri, Dec 13, 2013 at 03:15:43PM +0200, Constantinos Venetsanopoulos wrote:
> On 12/13/2013 03:08 PM, Michele Tartara wrote:
> >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>
>
> You are right. I forgot that you can have ``self_install``
> with no scripts at all.
>
> >>But I think it's perfectly doable.
>
> Perfect. So, we would have:
>
> for ``install``:
> -o my_definition+default:image:<URL>
> (fetches and extracts image first, then spawns helper)
> -o my_definition+default
> (just runs the scripts)
>
> and for ``self_install``:
> -o image:<URL>
> (fetches and extracts image onto disk, doesn't run scripts)
> None
> (doesn't fetch and extract image and doesn't run scripts)
>
> Right?
The idea sounds great!
We will combine both of your, Michele and Constantinos's, suggestions,
namely, allow OS scripts in both the 'install' and 'self_install'
modes while keeping the parameters simple.
gnt-instance ... [{-o|--os-type} OS[+variant]] [--os-image <file|URL>]
>
> Constantinos
>
> >>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
> >
> >
>
--
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
