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

[Deepak C Shetty]

On 12/08/2012 01:23 AM, Saggi Mizrahi wrote:
>
> ----- Original Message -----
>> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
>> To: "Saggi Mizrahi" <smizrahi at redhat.com>
>> Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>, "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development"
>> <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
>> Sent: Friday, December 7, 2012 12:23:15 AM
>> Subject: Re: [vdsm] RFC: New Storage API
>>
>> On 12/06/2012 10:22 PM, Saggi Mizrahi wrote:
>>> ----- Original Message -----
>>>> From: "Shu Ming" <shuming at linux.vnet.ibm.com>
>>>> To: "Saggi Mizrahi" <smizrahi at redhat.com>
>>>> Cc: "VDSM Project Development"
>>>> <vdsm-devel at lists.fedorahosted.org>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Thursday, December 6, 2012 11:02:02 AM
>>>> Subject: Re: [vdsm] RFC: New Storage API
>>>>
>>>> Saggi,
>>>>
>>>> Thanks for sharing your thought and I get some comments below.
>>>>
>>>>
>>>> Saggi Mizrahi:
>>>>> I've been throwing a lot of bits out about the new storage API
>>>>> and
>>>>> I think it's time to talk a bit.
>>>>> I will purposefully try and keep implementation details away and
>>>>> concentrate about how the API looks and how you use it.
>>>>>
>>>>> First major change is in terminology, there is no long a storage
>>>>> domain but a storage repository.
>>>>> This change is done because so many things are already called
>>>>> domain in the system and this will make things less confusing for
>>>>> new-commers with a libvirt background.
>>>>>
>>>>> One other changes is that repositories no longer have a UUID.
>>>>> The UUID was only used in the pool members manifest and is no
>>>>> longer needed.
>>>>>
>>>>>
>>>>> connectStorageRepository(repoId, repoFormat,
>>>>> connectionParameters={}):
>>>>> repoId - is a transient name that will be used to refer to the
>>>>> connected domain, it is not persisted and doesn't have to be the
>>>>> same across the cluster.
>>>>> repoFormat - Similar to what used to be type (eg. localfs-1.0,
>>>>> nfs-3.4, clvm-1.2).
>>>>> connectionParameters - This is format specific and will used to
>>>>> tell VDSM how to connect to the repo.
>>>> Where does repoID come from? I think repoID doesn't exist before
>>>> connectStorageRepository() return.  Isn't repoID a return value of
>>>> connectStorageRepository()?
>>> No, repoIDs are no longer part of the domain, they are just a
>>> transient handle.
>>> The user can put whatever it wants there as long as it isn't
>>> already taken by another currently connected domain.
>> So what happens when user mistakenly gives a repoID that is in use
>> before.. there should be something in the return value that specifies
>> the error and/or reason for error so that user can try with a
>> new/diff
>> repoID ?
> Asi I said, connect fails if the repoId is in use ATM.
>>>>> disconnectStorageRepository(self, repoId)
>>>>>
>>>>>
>>>>> In the new API there are only images, some images are mutable and
>>>>> some are not.
>>>>> mutable images are also called VirtualDisks
>>>>> immutable images are also called Snapshots
>>>>>
>>>>> There are no explicit templates, you can create as many images as
>>>>> you want from any snapshot.
>>>>>
>>>>> There are 4 major image operations:
>>>>>
>>>>>
>>>>> createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
>>>>>                      userData={}, options={}):
>>>>>
>>>>> targetRepoId - ID of a connected repo where the disk will be
>>>>> created
>>>>> size - The size of the image you wish to create
>>>>> baseSnapshotId - the ID of the snapshot you want the base the new
>>>>> virtual disk on
>>>>> userData - optional data that will be attached to the new VD,
>>>>> could
>>>>> be anything that the user desires.
>>>>> options - options to modify VDSMs default behavior
>> IIUC, i can use options to do storage offloads ? For eg. I can create
>> a
>> LUN that represents this VD on my storage array based on the
>> 'options'
>> parameter ? Is this the intended way to use 'options' ?
> No, this has nothing to do with offloads.
> If by "offloads" you mean having other VDSM hosts to the heavy lifting then this is what the option autoFix=False and the fix mechanism is for.
> If you are talking about advanced scsi features (ie. write same) they will be used automatically whenever possible.
> In any case, how we manage LUNs (if they are even used) is an implementation detail.

I am a bit more interested in how storage array offloads ( by that I 
mean, offload VD creation, snapshot, clone etc to the storage array when 
available/possible) can be done from VDSM ?
In the past there were talks of using libSM to do that. How does that 
strategy play in this new Storage API scenario ? I agree its implmn 
detail, but how & where does that implm sit and how it would be 
triggered is not very clear to me. Looking at createVD args, it sounded 
like 'options' seems to be a trigger point for deciding whether to use 
storage offloads or not, but you spoke otherwise :) Can you provide your 
vision on how VDSM can understand the storage array capabilities & 
exploit storgae array offloads in this New Storage API context ? -- 
Thanks deepak