Markus Hilger
a513bfc04f
raw_command raises on any nonzero completion code, so the 0xCA and 0xC5 checks in get_sdr could not run: a bmc that will not return a whole record in one go, or whose reservation went stale, failed the sensor load outright instead of being retried. Read the code from the exception, which carries it. The back off also had a fixed point, size // 2 + 2 being 3 for a size of 3, so a bmc that kept refusing would have been asked the same question for ever. Give up when the request cannot get any smaller. A header read cannot go under 5 bytes either, since that is where the record length sits, so give up there rather than parse a reply too short to index. The stale reservation retry could not end on its own either: it cleared the id and left taking a new one to the top of the loop, which only reserves for a partial read. Take one where the code is handled.
Confluent
Confluent is a software package to handle essential bootstrap and operation of scale-out server configurations. It supports stateful and stateless deployments for various operating systems.
Check this page for a more detailed list of features.
Confluent is the modern successor of xCAT. If you're coming from xCAT, check out this comparison.
Documentation
Confluent documentation is hosted on: https://xcat2.github.io/confluent-docs/
Download
Get the latest version from: https://xcat2.github.io/confluent-docs/downloads/
Check release notes on: https://xcat2.github.io/confluent-docs/release_notes/
Open Source License
Confluent is made available under the Apache 2.0 license: https://opensource.org/license/apache-2-0
Developers
Want to help? Submit a Pull Request.
Versioning and releases
The top-level VERSION file names the release the current branch is working toward. Build scripts
call ./mkversion, which turns it into the version stamped on packages: the tag itself on a release
tag (4.0.1), otherwise a development version (4.0.1.dev5+gdeadbee, or 4.0.1~dev5+gdeadbee for
the packages that have no setup.py).
mkversion also derives a version from the newest tag reachable from HEAD and uses whichever is
higher, so forgetting to bump VERSION after tagging the current branch cannot walk the version
backwards. Staying ahead of tags on other branches is what VERSION itself is for: patch releases
are tagged on release branches, which master never sees.
Cutting a new series:
- Land the release commit on master and tag
X.Y.0there. - Create branch
X.Yfrom that tag; it inheritsVERSION=X.Y.0. - Only then bump
VERSIONon master. Doing it before step 2 leaves the release branch on the wrong series.
Patch releases land on branch X.Y and are tagged X.Y.Z there; no VERSION edit is needed.