[Engine-devel] Domain rescan action question

Ayal Baron abaron at redhat.com
Wed Aug 1 07:48:28 UTC 2012



----- Original Message -----
> On 08/01/2012 12:21 AM, Ayal Baron wrote:
> >
> >
> > ----- Original Message -----
> >> On 07/31/2012 11:30 PM, Hopper, Ricky wrote:
> >>> Hey all,
> >>>
> >>> As I'm making progress with the domain rescan functionality, I've
> >>> realized that I'm unsure what to do with any disks that are
> >>> detected on
> >>> the domain. Should I add them back into the database to be listed
> >>> as
> >>> floating disks, or should I just return a list of disk images to
> >>> be
> >>> attached to whatever the caller of the query needs?
> >>>
> >>> - Ricky
> >>
> >> i'm not sure they should be added automatically.
> >> I think a dialog[1] showing orphan disks/images on the storage
> >> domain
> >> for user to choose which to import as 'floating' disks would be
> >> better
> >> than auto importing them.
> >
> > why? this same functionality would be used to import an existing
> > domain.
> > If these disks are referenced in OVFs we are not familiar with on
> > this domain then we should import the *VMs*.
> > If they are referenced by other VMs that are already in the system
> > (but disks have been unreachable until now) then the disks should
> > just be added to the db in attached mode.
> > If neither, then the disks should be added as floating disks.
> > For the import functionality, once you subsequently import another
> > domain with OVFs which do reference these disks then if user
> > hasn't appropriated them for other VMs then they would move to
> > attached state, otherwise need to add those VMs with errors.
> >
> > Note that there are 2 reasons for unknown valid disks to be on the
> > domain:
> > 1. delete was initiated in engine but not performed on storage
> > (then floating is fine as only way to automatically delete them is
> > if user chooses to do so)
> > 2. disks were created there outside of the system - should just
> > detect and import and use logic above.
> >
> >>
> >> there is also the reverse of flagging existing disks as 'missing'
> >> in
> >> storage?
> >
> > If disks were floating then they should just be removed, otherwise
> > should be moved to illegal state (we have this state for disks
> > today).
> >
> >>
> >>
> >> [1] or a subtab on the storage domain.
> >
> > Another sub-tab for disks?
> > It's possible but what would you do when importing an existing
> > domain into the system? require user to manually select which
> > disks to import? or would you have different flows for import of
> > domain and rescan of contents? (I'd rather keep it simple with
> > less tabs and manual operations for user to perform, seems more
> > intuitive to me).
> >
> 
> I'm not sure orphaed images and importing an entire domain should be
> the
> same flow from UX part.
> and for a netapp native clone, you'd want to only import the newly
> cloned ("orphaned) image from the storage via an api call, not the
> entire domain/images

For proper bookkeeping I think we'd want these disks to be reflected in the GUI.  I do not however think we need to add additional tabs for this.
We could have yet another state ('orphaned' or sth.) for disks to be able to easily differentiate in the GUI etc.
I would imagine we'd regularly scan domains to account for storage usage.
If we do add such a state then we'd need an API to 'enable' it (so that it could be done automatically).

 



More information about the Engine-devel mailing list