Re: [Engine-devel] Domain rescan action question

From: "Ricky Hopper" <Ricky.Hopper(a)netapp.com&gt; To: "Dan Yasny" <dyasny(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Itamar Heim" <iheim(a)redhat.com&gt;, "Andrew Cathrow" <acathrow(a)redhat.com&gt; Sent: Wednesday, 1 August, 2012 4:56:45 PM Subject: Re: [Engine-devel] Domain rescan action question On 8/1/12 9:42 AM, "Dan Yasny" <dyasny(a)redhat.com&gt; wrote: > > >----- Original Message ----- >> From: "Ricky Hopper" <Ricky.Hopper(a)netapp.com&gt; >> To: "Dan Yasny" <dyasny(a)redhat.com&gt;, "Andrew Cathrow" &gt;&gt;&lt;acathrow(a)redhat.com&gt; >> Cc: engine-devel(a)ovirt.org, "Itamar Heim" <iheim(a)redhat.com&gt;, >> "Ricky >>Hopper" <Ricky.Hopper(a)netapp.com&gt; >> Sent: Wednesday, 1 August, 2012 4:34:53 PM >> Subject: Re: [Engine-devel] Domain rescan action question >> >> >> >> On 8/1/12 5:59 AM, "Dan Yasny" <dyasny(a)redhat.com&gt; wrote: >> >> > >> > >> >----- Original Message ----- >> >> From: "Andrew Cathrow" <acathrow(a)redhat.com&gt; >> >> To: "Itamar Heim" <iheim(a)redhat.com&gt;, "Dan Yasny" >> >> <dyasny(a)redhat.com&gt;, >> >>"Ricky Hopper" <Ricky.Hopper(a)netapp.com&gt; >> >> Cc: engine-devel(a)ovirt.org >> >> Sent: Wednesday, 1 August, 2012 12:24:42 AM >> >> Subject: Re: [Engine-devel] Domain rescan action question >> >> >> >> >> >> >> >> ----- Original Message ----- >> >> > From: "Itamar Heim" <iheim(a)redhat.com&gt; >> >> > To: "Ricky Hopper" <Ricky.Hopper(a)netapp.com&gt; >> >> > Cc: engine-devel(a)ovirt.org >> >> > Sent: Tuesday, July 31, 2012 4:44:34 PM >> >> > Subject: Re: [Engine-devel] Domain rescan action question >> >> > >> >> > 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. >> >> > >> >> > there is also the reverse of flagging existing disks as >> >> > 'missing' >> >> > in >> >> > storage? >> >> > >> >> >> >> Perhaps we should start a feature page to discuss and better >> >> scope >> >> it. >> >> There is a feature page that we could expand, it doesn't >> >> discuss >> >> the >> >> notion of importing those disks which is certainly something we >> >> need >> >> to address. >> >> >> >> >> >> http://wiki.ovirt.org/wiki/Features/Orphaned_Images >> > >> >The original idea was to scan the storage domains and compare the >> >images >> >lists to the database, thus getting a list of images no longer >> >relevant >> >and scrubbing the storage. This will actually be addressed >> >properly >> >in >> >the future (Ayal can elaborate on that) but for now this is >> >needed >> >at >> >least for that use case. >> > >> > >> >As I understand, the conversation here is about trying to take an >> >already >> >populated SD (from another setup I suppose), scanning it and >> >putting >> >it >> >into RHEV? >> >> As I understood it, the purpose of this functionality wasn't to >> find >> images which should be removed from storage, but to find images on >> the >> domain that oVirt was unaware of and importing them for use (for >> instance, >> if a disk was created outside of oVirt on the domain). If one of >> the >> use >> cases for this feature is also the orphaned images mentioned on >> the >> feature page, that may expand the functionality into a separate >> domain >> scrub and storage import, both of which would call the rescan >> (meaning the >> rescan would not actually add to the database, but instead return >> a >> list >> of "orphaned" disk images). >> >> Another solution would be to import all disk images into the >> database >> either way, and let the user delete any orphaned images from the >> GUI. > >I think are nice to have, but the problem with the scanning is that >if >we're not scanning a master domain or an export domain, all we will >see >is a bunch of images with no context or even hints as to where they >belong. The data that makes it all usable is in the engine database >and >in the ovf files on the master domain. > >This is why I stopped at the orphaned images part of the feature - >because there it's feasible, I would rely on the engine database for >image ID comparisons. > >If we present a user with a list of nameless disks, I doubt it will >be of >any use. The way this would work is by comparing a list of disk images from vdsm and from oVirt's database, finding the ones vdsm returns that oVirt doesn't have, and then either adding or returning those images. So oVirt's db will be used in the comparison.

As far as presenting the user with nameless disks, that's a point I hadn't considered; we could generate some sort of placeholder metadata upon addition to show the user that these are new/orphaned disks that were found on the storage domain. Is it safe to assume that the disks discovered by this feature won't be attached to anything?

> > >> > >> >> >> >> > >> >> > [1] or a subtab on the storage domain. >> >> > >> >> > _______________________________________________ >> >> > Engine-devel mailing list >> >> > Engine-devel(a)ovirt.org >> >> > http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> > >> >> >> > >> >-- >> > >> > >> > >> >Regards, >> > >> >Dan Yasny >> >Red Hat Israel >> >+972 9769 2280 >> >> > >-- > > > >Regards, > >Dan Yasny >Red Hat Israel >+972 9769 2280