* Fixed a bug (well, made a work-around for an issue without a known reproducer) where, on some occassion, a record will end up in the public table without being copied into the history schema. When this happens, the next resync would crash out because the resynd reads in the history table only. Now, when about to INSERT a record into the public schema during a resync, an explicit check is made to see if the record alread
y exists. If it does, the INSERT is instead redirected to the history schema.
* Cleaned up the fence agent metadata when displaying to a user, converting the shell codes to underline a string with square brackets instead. We also now replace newlines with <br /> tags. Lastly, to help fence_azure_arm's metadata description to display cleanly, a check is made to format the table correctly.
* Began work on the Striker menu for handling fence device management
Signed-off-by: Digimer <digimer@alteeve.ca>
@ -1076,6 +1076,12 @@ If you are comfortable that the target has changed for a known reason, you can s
<keyname="striker_0205">Existing Manifests:</key>
<keyname="striker_0206">Run</key>
<keyname="striker_0207">Edit</key>
<keyname="striker_0208">Configure fence devices. These will be used when creating install manifests and are a critical safety mechanisms that will protect your data when a node misbehaves.</key>
<keyname="striker_0210">Fence devices are used to force a node that has entered an unknown state into a known state. Recovery after a node fault can not proceed until this happens, so this step is critically important.</key>
<keyname="striker_0211">Note: Any IPMI (iRMC, iLO, DRAC, etc) fence config will be handled in the host's config. This section configures shared devices, like PDUs. The ports/outlets a given node will use will be set in the install manifest later.</key>
@ -1254,6 +1260,7 @@ Failure! The return code: [#!variable!return_code!#] was received ('0' was expec
<keyname="warning_0026">The recipient's email address appears to not be valid.</key>
<keyname="warning_0027">There was a problem saving the alert recipient data. Please check the logs for more information.</key>
<keyname="warning_0028">Failed to read the fence agent: [#!variable!agent!#] metadata. Ignoring it.</key>
<keyname="warning_0029">While resync'ing the table: [#!variable!table!#] on: [#!variable!host_name!# (#!variable!host_uuid!#)], there was an entry found in the public schema (#!variable!column!# = #!variable!uuid!#) but not in the history schema. This shouldn't happen, and it probably a bug. Switching the query's schema from public to history for the query: [#!variable!query!#] is being dropped.</key>
<!-- Errors -->
<keyname="error_0001">There are not enough network interfaces on this machine. You have: [#!variable!interface_count!#] interface(s), and you need at least: [#!variable!required_interfaces_for_single!#] interfaces to connect to the requested networks (one for Back-Channel and one for each Internet-Facing network).</key>
@ -1393,6 +1400,8 @@ The error was:
</key>
<keyname="error_0112"><![CDATA[Failed to read valid unified XML data from: [#!variable!file!#]. It should start with: [<?xml version="1.0" ?>]]]></key>
<keyname="error_0113">The unified metadata file: [#!data!path::data::fences_unified_metadata!#] was not found. There may have been a problem creating it.</key>
<keyname="error_0114">This row's modified_date wasn't the first column returned in query: [#!variable!query!#]</key>
<keyname="error_0115">This row's UUID column: [#!variable!uuid_column!#] wasn't the second column returned in query: [#!variable!query!#]</key>
<!-- These are units, words and so on used when displaying information. -->
Digimer
5 years ago
