Hi Daniel, Makes sense, agreed. However, did you get a chance to review the security_model patch? https://www.redhat.com/archives/libvir-list/2010-September/msg00435.html On 10/06/2010 09:59 PM, Daniel P. Berrange wrote:
On Wed, Oct 06, 2010 at 06:22:29PM +0200, Daniel Veillard wrote:
On Thu, Sep 30, 2010 at 10:30:10PM +0530, Harsh Prateek Bora wrote:
This patch introduces a new attribute export_fs to the filesystem element which specifies the type of export. Currently only 'local' type of exported filesystem is supported. More types like NFS, clusterFS, etc. can be added later as required.
Note: This patch is based on the following two patches: 1) Daniel's patch to support 9pfs: https://www.redhat.com/archives/libvir-list/2010-September/msg00358.html 2) Another related patch to support 'security_model' attribute: https://www.redhat.com/archives/libvir-list/2010-September/msg00435.html
Signed-off-by: Harsh Prateek Bora<harsh@linux.vnet.ibm.com>
Okay, I don't understand what's the point of adding that attribute with only one possible value and systematically generated. I think it's better to propose this when there is an actual use case for the attribute, then it will be easier to say if this is the right construct to add or not.
I agree and in fact think this extra attribute is almost certainly the wrong approach. The existing<filesystem type='....'> attribute should be sufficient for our needs. When QEMU supports FS backends which are not 'local', then we will likely add extra values for type='...' to cope with them. So lets just wait until QEMU actually supports some non-local modes.
Regards, Daniel