On 29.09.2016 16:50, John Ferlan wrote:
>
>
> On 09/29/2016 10:06 AM, Michal Privoznik wrote:
>> On 15.09.2016 16:35, Michal Privoznik wrote:
>>> Just read the 3/3. I didn't know whether I should laugh or cry. I did both.
>>>
>>> Michal Privoznik (3):
>>> lock_driver_sanlock: Avoid global driver variable whenever possible
>>> m4: Check for sanlock_write_lockspace
>>> sanlock: Properly init io_timeout
>>>
>>> m4/virt-sanlock.m4 | 14 +++++---
>>> src/locking/lock_driver_sanlock.c | 69 +++++++++++++++++++++++++++++----------
>>> 2 files changed, 60 insertions(+), 23 deletions(-)
>>>
>>
>> Thanks John for ACKing the series. I'm not quite sure whether I can push
>> it now that we are in the freeze. I mean it can be viewed as a bug fix,
>> so I'm inclined to push it. What are your thoughts?
>>
>
> From the aspect of you have a legitimate bug that's causing a feature to
> not work properly, sure I agree. From the aspect of I've pushed
> something during a freeze before and was told I shouldn't have, maybe
> I'm not the best person to ask ;-).
>
> BTW: I understand your point about not wanting to document a specific
> version since it's possible (I suppose) that the API could be backported
> to some earlier release (not that we'd ever do that).
>
> Still, I'm reacting to a feature someone may have thought was working
> that suddenly will cause a failure to start a domain if they don't have
> the new API, but did have the old API. At least a running guest won't
> "go missing". IOW: how can we inform the user that the minimum version
> we expected now changed because of some change in an underlying package
> we depend on.
Well, I guess they will find out as soon they try to start a domain. If
they are running old sanlock (which they shouldn't at all - we advocate
for using our virlockd), they'll see a sensible error message:
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("unable to use io_timeout with this version of
sanlock"));
>
> All that said - push and say sorry later ;-)
Done :-)
Thank you.
Michal
>
> John
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list