Markus Hilger
b0ae4f201d
Three things stopped a redfish firmware update on MegaRAC. The AMI handler opened by asking the bmc to preserve fourteen named settings, and a build that knows a different set rejects the whole request, which aborted the update before anything was uploaded; send only the keys the bmc advertises. The multipart push carried the image alone, and the specification has it carry an UpdateParameters part too, which this firmware enforces. AMI also wants an OemParameters part naming the kind of image, and nothing was supplying one. The kind of image is asked for rather than worked out from the file. The extension is vendor habit rather than format, and the leading bytes answer just as confidently about an image they have never seen, while being wrong means a bmc flashed with a bios image. So nodefirmware takes --type, it travels as far as the handler that wants it, and where the bmc publishes the types it accepts, an unknown one is refused with the list, as is asking with none. A platform that reads the kind of firmware out of the image itself refuses the option rather than dropping it, so nobody aims an update somewhere they did not mean to. A parameter file still wins, since it can carry more than the image type. Updating the bmc takes the bmc, and the task being watched, away for minutes. That is the update working rather than the monitoring failing, so wait a bounded while for it to answer again instead of reporting a successful flash as an error.
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.