Re: [Engine-devel] [vdsm] Storage Device Management in VDSM and oVirt
----- Original Message -----
>>> So although I believe that when we create a gluster volume or an
>>> ovirt storage domain then indeed we shouldn't need a lot of low
>>> level commands, but it would appear to me that not allowing for
>>> more control when needed is not going to work and that there are
>>> enough use cases which do not involve a gluster volume nor a
>>> storage domain to warrant this to be generic.
>> I'm not against more control; I'm against uncontrollable API such
>> as
>> runThisLvmCommandAsRoot()
> I can't argue with this.
> I think what we're missing here though is something similar to
> setupNetworks which would solve the problem. Not have 100 verbs
> (createPartition, createFS, createVG, createLV, setupRaid,...)
> but rather have setupStorage (better name suggestions are welcome)
> which would get the list of objects to use and the final
> configuration to setup.
>
> This way we'd have a 2 stage process:
> 1. setupStorage (generic)
I was looking up on the VDSM archives and there are talks of using
libstoragemgmt (lsm)
Funny, we started using that acronym for Live Storage Migration :)
under VDSM. I was wondering if the setupStorage would be something
where
lsm would
be used to do the work, it seems fit for purpose here.
I don't think this is the libstoragemgmt mandate.
libstoragemgmt is:
"A library that will provide a vendor agnostic open source storage application
programming interface (API) for storage arrays."
i.e. it is there to abstract storage array specifics from the user.
It will be used by things like LVM etc, not the other way around.
setupStorage would use libstoragemgmt wherever appropriate of course.
But as the libstoragemgmt maintainer, Tony (cc'd) can correct me if I'm wrong
here.