Comment 18 for bug 1814832
Revision history for this message
| Oliver Kurth (okurth-1) wrote Re: [Bug 1814832] Re: Correct and/or improve handling of certain quiesced snapshot failures | #18 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hi Christian,
is this the the repo for the packages: https:/
I am a little confused since these are from Feb 12th, and I believe I had them tested already (but can't find the email that I sent). So I just want to make sure I am not testing the wrong ones. Also, where can I find the packages for cosmic?
Thanks,
Oliver
_______
From: <email address hidden> <email address hidden> on behalf of Christian Ehrhardt <email address hidden>
Sent: Wednesday, April 10, 2019 11:50 PM
To: Oliver Kurth
Subject: [Bug 1814832] Re: Correct and/or improve handling of certain quiesced snapshot failures
Hey Oliver,
TL;DR: sorry, but please test it from proposed (again) in Bionic&Cosmic.
Detail:
Unfortunately this is not how it works.
I'd want to mark it verified per your request, but I know that this will raise SRU-Team-Eyebrows and not be released.
I'm in fact already in discussion for a couple of cases where people pre-tested on PPAs and we later released as SRU which means they need to be verified again for the final releasing. The problem is the tradeoff on non-trivial bugs, you want:
- provide something to test for the reporter ASAP
- be able to iterate on alternatives
- run more tests and tests by different parties
- all of the above you want to do without yet polluting -proposed (as there other
builds could depend on it, it could break other proposed testing, ...)
=> This is what a PPA is used for most of the times.
But due to the above that usually means we end up with a change tested
and verified from a PPA that will then in this way be proposed as SRU
(same code + some paperwork).
There the process requires that this final build shall be verified (yes
- again).
This mostly comes from the past were people didn't pre-check with PPAs, but also is needed to cover any gap as the testing of the PPAs might have been:
- weeks ago
- ran with other dependencies at the time but would fail now
- built with other dependencies at the time
- only one release was tested but the SRU covers multiple
But for the above and more it usually is worth and by the process required to re-test the versions in proposed.
I've had a few such cases in the past now and I have started discussing
alternatives, which so far all come down to do the tradeoffs above at a
different place - or to have the SRU process accept verifications with
identical builds (as in this case). But there seems to be no easy best
answer. Resolving that is a long term effort ending in adaption of the
SRU or Developers process - nothing that is done in a minute.
Until all of that is resolved, I'd really ask you to re-test the case as
built in Bionic/
burden/effort for you.
--
You received this bug notification because you are subscribed to the bug
report.
https:/
Title:
Correct and/or improve handling of certain quiesced snapshot failures
Status in open-vm-tools package in Ubuntu:
Fix Released
Status in open-vm-tools source package in Bionic:
Fix Committed
Status in open-vm-tools source package in Cosmic:
Fix Committed
Status in open-vm-tools package in Debian:
Fix Released
Bug description:
[Impact]
* Upstream identified an issue that can occur on aborted (or
due to communication issues while doing) quiesced snapshots.
* Backport the upstream changes as part of our work getting the latest
10.3.5 to the latest Ubuntu LTS (Bionic)
[Test Case]
* This is hard to test, but fortunately VMWare who have the right setup
for this tested our change from a PPA. I'll ask for that again on SRU.
Never the less I'll outline roughly what is needed to trigger [1]:
1. Use the host side interface to trigger a quiesced snapshot
2. this is the hard part - have communication failures between vmtools
(guest) and VMX (host) while this is ongoing.
3. From the Hosts POV the operation is aborted, but vmtools sends a
manifest eventually
4. Receiving this will make VMX reply a error (as it didn't wait for
anything like it)
5. Finally this broke the state machine and in subsequent cases vmtools
will not send a manifest again
* Further related fixes make sure vmtoolsd give up if VMX aborted the
snapshot [2] and another [3] makes sure manifests are always sent to
avoid any desync between VMX and vmtoolsd
[1]: https:/
[2]: https:/
[3]: https:/
[Regression Potential]
* This is quite a change to the snapshot handling, so in theory there a
regression has to be assumed. Due to a lack of testcases and expertise
on our side that was handed to VMWare itself who have a much wider
matrix of tests and setups to run them on.
This was tested and confirmed good (even before the change made
it upstream).
* Furthermore those kind of snapshots are relevant to those
who use them (and they most likely want the fix for reliability as you
could get into a state where no further snapshots were possible). But
OTOH the majority of users of the open-vm-tools package most likely
don't use the feature at all. Fortunately changes are local to only the
vmbackup functionality.
[Other Info]
* n/a
---
Customers may hit issues with quiesced snapshots under certain
circumstances. This is fixed in a branch forked from 10.3.5:
https:/
snapshot
A more detailed description of the issue can be found in the
individual commit messages.
Also filed at Debian: https:/
bin/bugreport
To manage notifications about this bug go to:
https:/