On 09/26/2018 01:58 PM, Andrea Bolognani wrote:
On Wed, 2018-09-26 at 11:54 +0200, Michal Privoznik wrote:
> On 09/26/2018 01:05 AM, John Ferlan wrote:
>> So in summary, I believe the issues raised thus far are primarily
>> metadata locking related, so should we really hold up the release for
>> something that isn't fully complete or listed in news.xml as a ne
>> feature?
>
> Because if turned on in qemu.conf the feature has possibility of killing
> libvirtd every now and then. That's why we need to patch it before the
> release.
I didn't follow the discussion around the feature itself so I
apologize in advance if this ends up being just noise, but can we
not just make it so we don't recognize the corresponding qemu.conf
option for this release, thus making the feature impossible to turn
on for all intents and purposes, and reintroduce the knob once the
4.9.0 cycle starts so that we have plenty of time to work out any
remaining kinks in the implementation? That seems like it would be
the prudent thing to do.
Depends on what you understand under feature. The end goal I am trying
to achieve is libvirt remembering original owner of a file it relabels.
Patches I am working on will use XATTRs to do that (since there is no
better way to have shared DB between two libvirt daemons running on
distant hosts). Since working with XATTRs and chown() and setfcon() is
not atomic I need to have metadata locking.
So if metadata locking is also a separate feature (I guess not, there is
no added value to users really) then the feature is done (it has some
bugs but I've posted patches for those and there is an active discussion
going on). But if it is not a separate feature then we can temporarily
turn it off just for the release.
Michal