Increased the wait between host_enable attempts, allowing to wait more for the host to reboot.
This will affect Automated Updates and other normal Patching Wizard
operations as well.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
CA-267330: [Update Wizard Improvements] The Update wizard: block the installation of an update on slaves if a reboot or a toolstack restart is pending on master
* CP-25081: UI improvements for USB passthrough
* CP-25081: Show text when AttachUsbDialog list is empty.
* Fix comments.
* Improve the presentation of warnings in USBEditPage.
* Update warning text of attach usb dialog.
* Simplify the layout of Attach USB Dialog.
* Check if USB devices plugged before showing UI.
* Fix comments.
* Fix comments.
* Improve code.
when the max tolerance is being calculated, the text and icon on top of HA
wizard is no longer visible after this fix.
Signed-off-by: Ji Jiang <ji.jiang@citrix.com>
* CP-24412: Apply a filter before adding USBs to candidate list in Attach Dialog.
* CP-24333: Apply HA restraint.
* CP-24412: Fix a merge error.
* CP-24412: implement actions to attach/detach/passthrough.
* CP-24412: Add license check before making UI components visible.
* CP-24412: Change layout of new components to Dpi.
* Fixed all comments.
* Fix comments.
* fixed comments
This is caused by the `waitingNtolUpdate.waitOne()` call being at the end of the loop, not the beginning. The reason is that the `waitingNtolUpdate` is set during the first iteration (before the thread even gets loaded) - because the setter for Settings in this file sets it (and that's set by the setter for AssignPriorites.Connection, which is set in the HAWizard constructor). So when the thread first spawns we do the calculations, then get to the `waitOne` lock, which is set so we go back around the loop and calculate everything again before returning to the lock and waiting to be triggered. The correct behaviour is to trigger only once on the page load, and then only when re-triggered. To achieve that I've moved the `waitOne` call to the beginning of the loop, so that (assuming the `waitingNtolUpdate` lock is set before the thread is first started) we immediately run the calculations and then stop at the beginning of the loop waiting to be triggered again. This means that on page load (and after each re-trigger) we only calculate once.
The assumption that the lock is set before the thread is triggered is currently valid, because as mentioned above it's currently set by the setter for Settings which is indirectly called by the wizard constructor. I don't want to rely on that behaviour though because it's very indirect, so just to be safe I've added an explicit set just before the thread is triggered so that it's guaranteed to run the calculations the first time. This isn't strictly necessary but seems better than relying on the existing implicit setting. Since we use the same mechanism just in a different place, all the existing code that sets `waitingNtolUpdate` continues to trigger this thread as expected.
Following pattern would be caught when using "XenCenter" "XenServer" and
"Citrix":
1) not "[" or "/" or """ on left of the brand string
2) brand string followed by space followed by not "p", and optional letter
3) optional letter followed by space followed by the brand string
4) brand string followed by "," and optional letter
5) begin with the brand string
6) end with the brand string
tested with all .resx files
Signed-off-by: Ji Jiang <ji.jiang@citrix.com>
