[libvirt] Plans for next release
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 ! Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
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. Michal
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. thanks, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
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? John
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
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. -- Andrea Bolognani / Red Hat / Virtualization
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
John Ferlan <jferlan@redhat.com> [2018-09-25, 07:05PM -0400]:
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.
Please, no, don't overcomplicate stuff. If a feature is not ready to be used by the user, don't pull it into master.
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?
John
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- IBM Systems Linux on Z & Virtualization Development ------------------------------------------------------------------------ IBM Deutschland Research & Development GmbH Schönaicher Str. 220, 71032 Böblingen Phone: +49 7031 16 1819 ------------------------------------------------------------------------ Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
participants (5)
-
Andrea Bolognani -
Bjoern Walk -
Daniel Veillard -
John Ferlan -
Michal Privoznik