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