[libvirt] Plans for next release

[Michal Privoznik]

On 09/26/2018 01:05 AM, John Ferlan wrote:
> 
> 
> On 9/25/18 9:38 AM, Daniel Veillard wrote:
>> On Tue, Sep 25, 2018 at 09:42:20AM +0200, Michal Privoznik wrote:
>>> On 09/24/2018 03:42 PM, Daniel Veillard wrote:
>>>>   that's next week ! If we want to release around Oct 1st, I would
>>>> suggest to enter freeze this Wed, probably in the morning europe time,
>>>> then plan for an RC2 friday morning and if everything goes well, have
>>>> the final release next monday.
>>>>
>>>>   I hope that works for everybody !
>>>
>>> Well, I introduced metadata locking in this release and as usual there
>>> are some follow up patches waiting for review:
>>>
>>> https://www.redhat.com/archives/libvir-list/2018-September/msg01134.html
>>>
>>> Also, Bjoern reported some issues with the feature (/me wonders if it's
>>> s390 specific) and he said he'll debug this week. Anyway, those patches
>>> and any patch that he'll write can be viewed as a bug fix and therefore
>>> can be merged during freeze.
>>
>>   Okay, let's proceed as expected, on Friday we can assess if Monday is still
>> right time for release, or if needed just postpone after Monday.
>>
> 
> I've reviewed the patches Michal posted - so that part is a fait
> accompli ;-)
> 
> IMO: Since usage of the metadata lock logic requires some amount of
> setup (e.g. changing a qemu.conf value), it's easy enough to indicate
> that the support isn't ready. In fact, in Michal's response to my review
> for patch 22/23:
> 
> https://www.redhat.com/archives/libvir-list/2018-September/msg00795.html
> 
> essentially indicates there's more to come in selinux.
> 
> So, I assume we can still call this "feature" as a work in progress.
> Perhaps we need a new section in news.xml or some other means to
> indicate we have "experimental code" with "limited support" (similar to
> the QEMU development preview and/or the x- prefixed capabilities). IOW:
> a buyer/user beware if you trip across this, then you are on your own -
> until of course we fix all the "known" issues.
> 
> 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 new
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.

But I agree that the feature in the state it is now doesn't have any
added value for users. So far it adds some locking over chown() which
was atomic anyway. I'm working on the patches that users will benefit
from (remembering the original owner of files we chown()).

Michal