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<ha...@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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
