[ovirt-devel] [ovirt-users] Unremovable disks created through the API

[Tomáš Golembiovský]

On Wed, 7 Mar 2018 15:12:58 +0200
Arik Hadas <ahadas at redhat.com> wrote:

> On Wed, Mar 7, 2018 at 1:01 PM, Tomáš Golembiovský <tgolembi at redhat.com>
> wrote:
> 
> > Hi,
> >
> > this sounds like a good idea in general. Few interconnected questions
> > though...
> >
> > On Wed, 7 Mar 2018 10:42:31 +0200
> > Arik Hadas <ahadas at redhat.com> wrote:
> >  
> > > IMHO, the process should be comprised of:
> > > 1. virt-v2v calls an API with the (probably partial since the OS and  
> > other  
> > > things are unknown at that point) OVF configuration
> > > 2. virt-v2v uploads the disks
> > > 3. virt-v2v provides the up-to-date configuration
> > >
> > > Step #1 will enable ovirt-engine:
> > > 1. Most importantly, to cleanup uploaded disks in case of an error during
> > > the import process. Otherwise, we require the client to clean them up,
> > > which can be challenging (e.g., if the virt-v2v process crashes).  
> >
> > Who will handle the removal in case of problems? Engine after timeout?
> > Or is the only benefit that administrator can remove all disks in one
> > step by removing the VM?
> >  
> 
> So I was thinking that the wrapper command will hold the amount of disks
> that should be uploaded for the VM.
> If for some predefined period of time no new disk is added or an upload
> doesn't make any progress (assuming the uploads are done sequentially), to
> fail the import operation and that would roll back the resources (disks,
> VMs) that were created as part of the import process.
> 
> 
> >
> > Note that the uploads do not timeout at the moment. However strange that
> > might be. So I assume removing the disks/VM will be impossible anyway
> > because of locking.
> >  
> 
> Yeah, I think no timeout was defined because uploading from the browser is
> relatively fragile and we didn't want the upload to fail, and the partial
> disks to be removed, due to browser issues but rather to be able to resume
> their upload. But different logic can be implemented in the wrapping
> command.

Would it make sense to add the timeout parameter to API? That way the
client can choose whether it wants one and how big. No timeout could
still be the default.

    Tomas

> As for locking, we don't have to call RemoveDisk but instead, to terminate
> the upload which will eventually remove the disks.
> 
> 
> >
> >  
> > > 2. To inform the user that the process has started - so he won't get
> > > surprised by seeing disks being uploaded suddenly. That will give a  
> > context  
> > > to these upload operations.  
> >
> > The uploaded disks will still remain unattached though. Or do you plan
> > for Engine to create and attach the disks?
> >  
> 
> Right, so when we have that "context" and a VM entity in the databse, we
> can attach the disks to the VM when they are created.
> 
> 
> >
> >  
> > > 3. To inform the user about the progress of the import process, much like
> > > we do today when importing VMs from vSphere to RHV.  
> >
> > How will this be handled? Will Engine report the progress in the Virtual
> > Machines view and compute something based on the upload progress?
> >  
> 
> Yes, I don't see why not showing that in the status field (at the VMs tab)
> as we do today for VMs that are being imported.
> The engine would need to know the estimated actual sizes of the disks in
> order to compute it though.
> 
> 
> >
> > Tomas
> >  
> > > 4. To perform validations on the (partial) VM configuration, e.g.,
> > > verifying that no VM with the same name exists/verifying there is enough
> > > space (optionally mapping different disks to different storage devices)  
> > and  
> > > so on, before uploading the disks.
> > >
> > >
> > > The gaps I see:
> > > 1. We don't have a command for step #1 yet but that's something we can
> > > provide relatively quickly. We need it also to support uploading an OVA  
> > via  
> > > oVirt's webadmin.
> > > 2. We have a command for step #3, but it is not exposed via the API.  
> >
> >
> > --
> > Tomáš Golembiovský <tgolembi at redhat.com>
> >  


-- 
Tomáš Golembiovský <tgolembi at redhat.com>