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

----- Original Message ----- OpenStack and oVirt have different architectures and goals. Even though they are both marketed as IaaS solutions they are designed for different purposes. OpenStack is designed around the idea of simplifying the *development* and *integration* of IaaS subsystems through standardization of interfaces. If you design a system that requires access to some type of infrastructural resource you can develop against the OpenStack API for that specific resource and you can consume different underlying implementations of the subsystem. Alternatively if you are creating a new subsystem implementations one of your exposed APIs can be the appropriate OpenStack API. In short, they are a group of loosely coupled services meant to be used replicated and distributed in a cluster. Everyone can create they own implementations of the APIs. oVirt is designed around the idea of simplifying the *management* of said infrastructure. The ovirt-engine is the cluster manager and VDSM is the host-manager. Every host in the cluster has a host manager installed on it (VDSM) and some (currently only 1) might have the cluster-manager (ovirt-engine) and they are the effective brain. oVirt ideally only has managing entities. VDSM APIs delegate to other subsystems tasks that are in it's scope, the subsystems have their own APIs. For VMs you have libvirt, for networking you have the linux management tools and maybe netcf for policy we now have MOM. For iscsi we have iscsiadm, etc. The only odd one out is the image provisioning subsystem which I will get in to, don't worry. This means, if you didn't already gather, that no host managed by ovirt can exist without either VDSM or the ovirt-engine living on it. That being said, I am a huge proponent of making all subsystems optional. Meaning you can have VDSM that doesn't have the libvirt or networking glue bits and just has storage, and gluster. To put it simply, no host without a *managing* entity on it. But, as you all have pointed out, VDSM is redundant. There is no reason why the engine can't just directly ask libvirt to do things. There is no reason why we can't make a general iscsi management API and expose it on it's own, independent from other services. VDSM is frankensteinesque abomination of misplaced BL and pass-through APIs. This is why everyone are having a hard time figuring out what to do with it. I have people on one side bothering me about putting more *management* logic in. On the other side people are calling for standardized APIs which can't exist with engine specific management logic. To sum up this long rant, if you want to split up the bits that make VDSM in to independent subsystems just don't work on VDSM because VDSM (excluding the storage subsystem) is just glue anyway. Better just write another OpenStack back-end for something. As for the storage core. It is the only thing in VDSM that is not glue and actually needs to sit on the host. The new storage code I'm writing is actually developed in the hope that it will be independent from the rest of VDSM and VDSM will just have glue, like everything else.