| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain filesystems are sometimes used in specialty computing
environments where a shared storage infrastructure or fabric exists.
These filesystems allow for multi-host shared concurrent read/write
access to the underlying block device by *not* locking the entire
device for exclusive use. Generally ranges of the disk are reserved
for each interacting node to write to, and locking schemes are used
to prevent collissions.
These filesystems are common for use cases where high availability
is required or ability for individual computers to collaborate on a
given workload is critical, such as a group of hypervisors supporting
virtual machines because it can allow for nearly seamless transfer
of workload from one machine to another.
Similar technologies are also used for cluster quorum and cluster
durable state sharing, however that is not specifically considered
in scope.
Where things get difficult is becuase the entire device is not
exclusively locked with the storage fabrics, and in some cases locking
is handled by a Distributed Lock Manager on the network, or via special
sector interactions amongst the cluster members which understand
and support the filesystem.
As a reult of this IO/Interaction model, an Ironic-Python-Agent
performing cleaning can effectively destroy the cluster just by
attempting to clean storage which it percieves as attached locally.
This is not IPA's fault, often this case occurs when a Storage
Administrator forgot to update LUN masking or volume settings on
a SAN as it relates to an individual host in the overall
computing environment. The net result of one node cleaning the
shared volume may include restoration from snapshot, backup
storage, or may ultimately cause permenant data loss, depending
on the environment and the usage of that environment.
Included in this patch:
- IBM GPFS - Can be used on a shared block device... apparently according
to IBM's documentation. The standard use of GPFS is more Ceph
like in design... however GPFS is also a specially licensed
commercial offering, so it is a red flag if this is
encountered, and should be investigated by the environment's
systems operator.
- Red Hat GFS2 - Is used with shared common block devices in clusters.
- VMware VMFS - Is used with shared SAN block devices, as well as
local block devices. With shared block devices,
ranges of the disk are locked instead of the whole
disk, and the ranges are mapped to virtual machine
disk interfaces.
It is unknown, due to lack of information, if this
will detect and prevent erasure of VMFS logical
extent volumes.
Co-Authored-by: Jay Faulkner <jay@jvf.cc>
Change-Id: Ic8cade008577516e696893fdbdabf70999c06a5b
Story: 2009978
Task: 44985
|
| |
|
|
|
|
|
|
| |
Pass kwargs to dispatch_to_managers method in execute_clean_step
Change-Id: Ida4ed4646659b2ee3f8f92b0a4d73c0266dd5a99
Story: 2010123
Task: 45705
|
| |
|
|
| |
Change-Id: I94657967763f058fccd4f19656925d02cd8973b8
|
| |
|
|
|
|
| |
Change-Id: I304a460f88f3f8ee33cf642355f0e659184db724
Story: #2006963
Task: #40727
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently the index page contains a brief introduction and 3 links.
Expand the table of contents to show more subheadings.
Clean up the install, admin and contributing docs of unnecessary
and wrong content and redundant headings.
Update URLs throughout the text.
Change-Id: I03279ffc9faf387b08f727dee3b8898a69918460
|
| |
|
|
|
|
|
|
|
|
| |
They're not easily discoverable there, let's keep them in tree.
The examples have been restructured to have two different projects
ready to be copied and adjusted. PEP8 failures have been fixed.
Change-Id: I2af04f4b7f9a2109fe83ec517e716159331a48bb
Co-Authored-By: Jay Faulkner <jay@jvf.cc>
|
| |
|
|
| |
Change-Id: Id7c5686cdbdc79812e06eb4a5f87eddc75005cc3
|
| |
|
|
| |
Change-Id: I7473b96d47d959fc4c02cecbfaf4785d5f92996a
|
| |
|
|
| |
Change-Id: I5cf2627d999d4f3cf7bc2367f4d9cfddf6391146
|
| |
|
|
|
|
|
|
| |
This is the follow-up patch addresses outstanding comments for
commit 689dbf6b5c6ec1dcaf1fa37d288518c91eedf4ec.
Change-Id: I72c189988c5c274c32d61a2b9aea5a84da2b2c6e
Related-Bug: #1526449
|
| |
|
|
|
|
|
|
| |
This adds documentation for rescue mode, including the finalize_rescue
command as well as upstream support in agent images.
Change-Id: Id0834941ee4dacf2e7c0feaa65126d63e8a97c39
Partial-Bug: 1526449
|
| |
|
|
| |
Change-Id: Ib9a3897795993e7bce9a43d4028e1c9a90d47302
|
|
|
Change-Id: I43890d380b3cb6b19cfb84bf5d9dcad4f19c0062
|
