[Engine-devel] [vdsm] RFC: New Storage API

[Adam Litke]

On Mon, Dec 10, 2012 at 03:36:23PM -0500, Saggi Mizrahi wrote:
> > Statements like this make me start to worry about your userData
> > concept.  It's a
> > sign of a bad API if the user needs to invent a custom metadata
> > scheme for
> > itself.  This reminds me of the abomination that is the 'custom'
> > property in the
> > vm definition today.
> In one sentence: If VDSM doesn't care about it, VDSM doesn't manage it.
> 
> userData being a "void*" is quite common and I don't understand why you would thing it's a sign of a bad API.
> Further more, giving the user choice about how to represent it's own metadata and what fields it want to keep seems reasonable to me.
> Especially given the fact that VDSM never reads it.
> 
> The reason we are pulling away from the current system of VDSM understanding the extra data is that it makes that data tied to VDSMs on disk format.
> VDSM on disk format has to be very stable because of clusters with multiple VDSM versions.
> Further more, since this is actually manager data it has to be tied to the manager backward compatibility lifetime as well.
> Having it be opaque to VDSM ties it to only one, simpler, support lifetime instead of two.
> 
> I guess you are implying that it will make it problematic for multiple users to read userData left by another user because the formats might not be compatible.
> The solution is that all parties interested in using VDSM storage agree on format, and common fields, and supportability, and all the other things that choosing a supporting *something* entails.
> This is, however, out of the scope of VDSM. When the time comes I think how the userData blob is actually parsed and what fields it keeps should be discussed on ovirt-devel or engine-devel.
> 
> The crux of the issue is that VDSM manages only what it cares about and the user can't modify directly.
> This is done because everything we expose we commit to.
> If you want any information persisted like:
> - Human readable name (in whatever encoding)
> - Is this a template or a snapshot
> - What user owns this image
> 
> You can just put it in the userData.
> VDSM is not going to impose what encoding you use.
> It's not going to decide if you represent your users as IDs or names or ldap queries or Public Keys.
> It's not going to decide if you have explicit templates or not.
> It's not going to decide if you care what is the logical image chain.
> It's not going to decide anything that is out of it's scope.
> No format is future proof, no selection of fields will be good for any situation.
> I'd much rather it be someone else's problem when any of them need to be changed.
> They have currently been VDSMs problem and it has been hell to maintain.

In general, I actually agree with most of this.  What I want to avoid is pushing
things that should actually be a part of the API into this userData blob.  We do
want to keep the API as simple as possible to give vdsm flexibility.  If, over
time, we find that users are always using userData to work around something
missing in the API, this could be a really good sign that the API needs
extension.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center