Conversation
✅MegaLinter analysis: Success
See detailed reports in MegaLinter artifacts Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining
|
From OSISM 11 a new deployment deploys Ceph with cephadm, and the deploy guide described ceph-ansible only. Add a section that walks the cephadm plays in order: OSD device preparation with the osism-ansible LVM plays, bootstrap and the Ceph client, host registration, configuration, the MON/MGR/crash services and the OSDs, pools and keys, CephFS/MDS and RGW, and the dashboard, followed by the validators. It states the prerequisites that cfg-cookiecutter generates (the dedicated cephadm SSH key, no ceph-ansible container, ceph_version in the global configuration on the latest track). The existing steps become "Deployment with ceph-ansible", for OSISM 10 and earlier and for clusters kept on ceph-ansible; the RGW integration into OpenStack and the key persistence are shared and referenced from the new section. The order is the one a full cephadm Tentacle deployment was validated with. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
Start the OSISM 11 release notes with what an operator has to know or do: new installations only, OpenStack 2026.1, Ceph deployed with cephadm on Tentacle and what that changes in configuration and commands, the aes256k cephx keys and the kernel client limitation they bring, Ceph validators that now fail on a failed validation, and the 2026.1 changes operators touch. Entries sit under "Next" until the release date is known; the series is added to the index with the release. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
ideaship
force-pushed
the
osism-11-docs
branch
from
October 1, 2026 18:44
86d3fa3 to
cd97184
Compare
OSISM 11 refuses a deployment whose host names are inconsistent, which is a new way for a bootstrap to stop. An operator who hits it sees only the failure message, and the names are decided before the deployment runs, so the note has to be readable by someone who has not started yet. Describe the condition without the implementation: the name the kernel reports against the name a lookup returns, case, resolvability, and collisions across the inventory. Name the three lookups that break, since "some things disagree" does not convey that each one is fatal on its own. State that the choice is free now and not later. nova records the name it first saw and has no rename path, which is what makes this a pre-deployment decision rather than something to fix afterwards. Assisted-by: Claude:claude-opus-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
OSISM 11 refuses to bootstrap hosts whose names are inconsistent, and the release note describes that refusal. It reaches the wrong reader: someone planning a deployment is in the configuration guide, choosing the very names the check will judge, and the inventory page said nothing about them. State the rule where the decision is made. One form throughout, short or fully qualified; the combination that breaks is fully qualified inventory names without hostname_use_fqdn, where each machine answers to one name while the network answers with another. Name the three things that break, because "components may disagree" does not convey that each one is fatal by itself. List the other conditions the bootstrap checks -- length, case, collisions, resolvability -- so the page describes what is enforced rather than only the headline case. The collision example is two fully qualified names differing after the first label, which is the one an inventory can walk into without anything looking wrong. Say that the choice is made before deploying, since nova stores the name it first saw for a compute and cannot rename one. Assisted-by: Claude:claude-opus-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
osism apply cephadm-*plays in order — OSD device preparation with the osism-ansible LVM plays, bootstrap and the Ceph client, host registration, configuration, MON/MGR/crash and OSDs, pools and keys, CephFS/MDS and RGW, the dashboard, and the validators. It lists the prerequisites cfg-cookiecutter generates. The existing steps become "Deployment with ceph-ansible", for OSISM 10 and earlier and for clusters kept on ceph-ansible.docs/release-notes/osism-11.md, with what an operator has to know or do for OSISM 11, under "Next" until the release date is known. The index row is added with the release.Notes for review
The step order is the one a full cephadm + Tentacle deployment was validated with.
yarn buildpasses with no broken links or anchors.The release notes describe changes from these, which have to land for the text to be true:
Part of
🤖 Generated with Claude Code