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

----- Original Message ----- Asi I said, connect fails if the repoId is in use ATM. 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. No, that is not what I meant. If the user asked for a space driven image then the qcow2 version is the optimized version. I chose my words carefully when I originally wrote "a better way VDSM can represent the underlying data". "better" can mean different things in different circumstances. How VDSM makes it "better" is an implementation detail. It can even change between VDSM versions. An extreme case is if we ever decide to make QED the preferred format. That could potentially suddenly mark all images that are internally represented as qcow2 as degraded because VDSM has found a "better way to represent the data". All the user has to know is that "degraded images" can be used but they are in a what VDSM considers to be a sub-optimal state. It's up to the user to decide whether to optimize now, later or never. File based domains are responsible for syncing up object manipulation (creation\deletion) The backend is responsible for making sure it all works either by having a single writer (NFS) or having it's own locking mechanism (gluster). In our LVM based domains VDSM is responsible for basic object manipulation. The current design uses an approach where there is a single host responsible for object creation\deleteion it is the SRM\SDM\SPM\S?M. If we ever find a way to make it fully clustered without a big hit in performance the S?M requirement will be removed form that type of domain. OK This is part of the repo API which is out of the scope of this document but in general terms. getStorageRepositoryContraints() will return the NEED_S?M flag which will notify the manager that it needs to elect an S?M for this repository instance. All image createVirtualDisk() createSnapshot() and copyImage() and some fixes() will need to be performed on the S?M, removeImage() and some of the fixes could be performed on any host. As previously noted sending the option autoFix=False will make VDSM not automatically start a fix operation after the operation finished persisting the request and creating the object. This means you could offload the actual date IO to another host. Because what fixes can run on what host can change between versions you will just have to try and see if VDSM rejects it on hosts other then the SPM. There are also plans on abstracting further and making hosts that are not the S?M ask the S?M to create\delete objects for them so you can run any request on any host. I would very much like to implement that but I am still not sure how efficient inter VDSM communication is to commit to that. This can be easily implemented in the future by a new flag that marks that even though this repo requires an S?M it doesn't matter where you perform the operation. You would want to do it to get your images to a better state broken->(degraded|optimized) or degraded->optimized. Getting an image to a functional (degraded|optimized) state is obviously beneficial and getting to an optimized is better by definition. As an example. The user called copyImage() that created the all the objects involved and persisted the command and returned. The snapshot is not yet ready as the actual copy of the data didn't really happen. Lets say that the method was called with autoFix=False so you now have a broken image (the new image). You can't use it at the moment. Running a Fix will continue the actual operation moving it to a better state. VDSM will choose whatever is more likely to get the image to a functional state faster. This means that the image might find itself in a degraded state. This is good because if the user want to run the VM ASAP it can now do it for the price of performance. If the user has resource to spare (time\IO\hosts) it can choose to perform another fix and get the image to an optimized state. This ensures that the images is in the best state according to the users options. This of course doesn't mean best performance as the user might ask that VDSM value other things over performance. This system means that you can allocate and deallocate resources at will with minimal consequences. In some cases advanced users can use this system in conjunction with live merge \ live migration to actually "optimize" while it's running. This system means that VDSM can change it's policy and behavior between versions without that breaking the interface. We find a way to skip degraded state for some use case, great. We found a way to make some use case finish faster but in degraded mode, awesome. We found a way to make some operations run on all hosts, fantastic. The user can always handle it because it never assumes the physical result of any operation just the logical. Fix could literally mean anything, format conversion, compression\decompression, cleanups, merges.