On Wed 07 Sep 2011 04:12:04 PM IDT, Ayal Baron wrote:
----- Original Message -----
On Wed, Sep 07, 2011 at 06:27:40AM -0400, Ayal Baron wrote:
To be clear, you are suggesting that we could store this metadata on an existing DATA Storage Domain, right? In that case I agree. There is no need to create a new type of storage domain (META) whose exclusive purpose would be the storage of this type of information.
Correct. But it's not straightforward, it requires a new feature for existing domains (we've been discussing this for a long time).
Thanks for the information Ayal. What is the best way for me to help with this? I know your team is busy with many other project requirements.
Saggi, can you braindump on this?
-- Adam Litkeagl@us.ibm.com IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Your treading into very shaky grounds.
Just to make things clear there will never be another *new* domain class. Domain classes are a mistake and will be gradually removed. If some paradigm doesn't support the full features of a domain it shouldn't be one.
That being said I agree that there is a need for an API to push\pull "objects" from\to domains. These objects are blobs to VDSM and are only understood by management code. Further more I said many times that other objects like images and snapshots should also have a way to associate some metadata on them that is only understood by management.
This feature is so that VDSM will be more management agnostic. Anything that is not a direct responsibility of VDSM will be managed by objects pushed by management code. For interopability between management systems a standard will have to be created that VDSM will *not* enforce.
This will facilitate saving VM metadata on the domain. I continue to stress that VDSM will not be aware of it being a VM metadata.
As for connection management, I think that runtime management of connection information is the way forward. I am positively against VDSM reading the storage for additional connection or even understanding more metadata. I don't care if the mgmt pushes this as an object and uses it in it's own code.
As for how you can help, simplest thing would be to complete the missing functions in the current connection management code. public_validateStorageServerConnection public_getStorageConnectionsList
They are part of the current API and making them work will be a good start. The actual binding of connections to a domain is part of the new API and we are not sure how to go about implementing its support just yet. Also making iscsi.py. devicemapper.py multipath.py more feature complete and better separated is a good start for making sure we have the subsystems for advanced connection management features.