Skip to content

docs(decisions): raise CSB-portability ADR as PROPOSED (split from #569) - #575

Open
wz-gsa wants to merge 2 commits into
mainfrom
feat/oracle-csb-portability-adr
Open

docs(decisions): raise CSB-portability ADR as PROPOSED (split from #569)#575
wz-gsa wants to merge 2 commits into
mainfrom
feat/oracle-csb-portability-adr

Conversation

@wz-gsa

@wz-gsa wz-gsa commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Context

Split out of #569 per @pburkholder's review: "The PROPOSED ADR should be a separate
PR since it's distinct from the work we've already undertaken."

This is the RDSBaseline engine abstraction + structured-YAML idea, raised as
PROPOSED. It is one ADR, one file.

Why PROPOSED and not Accepted

The ADR says plainly that main does not do this, and I verified that against
the tree rather than asserting it:

It also states the precondition honestly: accepting this requires a decision that
hasn't been made — whether cloud.gov is migrating RDS brokerage to the CSB at all.
Building a portability abstraction for a migration that may not happen is speculative
generality, and the incremental imperative path is currently shipping working
hardening faster. That tradeoff is written into the ADR rather than glossed.

One accuracy correction over the original draft

The version in #569 claimed per-engine YAML baselines under services/rds/baselines/
as current state. That's true only on the long-lived integration branch
feat/oracle-19c-stig-brokered-rds (baselines.go plus oracle19c/parameters.yml,
options.yml, log_exports.yml) — not on main. The ADR now distinguishes the
two, and notes that the branch's baseline-data loading is not the same thing as the
engine interface this ADR proposes. Worth having straight, since a Proposed ADR that
overstates existing state is the same failure mode as an Accepted one doing it.

Added: an explicit disposition requirement

The ADR ends by saying it should be Accepted, rejected, or superseded as part of
deciding the CSB migration question — not left indefinitely Proposed. If the
migration is ruled out, it should be marked Rejected with that reason recorded,
so a speculative abstraction isn't carried forward as open intent. Otherwise this is
exactly the kind of record that sits in limbo for a year and then gets cited as though
it were a plan.

Notes for review

Refs #519, #568


🤖 AI-assisted (OpenCode). Human review required before merge.

Split out of $569 per review: the RDSBaseline engine + structured YAML idea is
distinct from the work already undertaken, so it should not ride along inside an
ACCEPTED record.

Status is PROPOSED and the ADR says plainly that main does not do this. Verified
against the tree rather than asserted: RDSBaseline is absent from main, and Oracle
config there is imperative Go (services/rds/oracle_tls.go, landed in $564).

One accuracy correction over the original draft. It claimed per-engine YAML
baselines under services/rds/baselines/ as current state; that is true only on the
long-lived integration branch feat/oracle-19c-stig-brokered-rds (baselines.go plus
oracle19c/parameters.yml, options.yml, log_exports.yml), not on main. The ADR now
distinguishes the two and notes that the branch's baseline-data loading is not the
engine interface this ADR proposes.

Also adds an explicit disposition requirement: this should be Accepted, rejected,
or superseded as part of deciding the CSB migration question, not left Proposed
indefinitely. If the migration is ruled out it should be marked Rejected with that
reason recorded, so a speculative abstraction is not carried as open intent.

Note the cross-link to ADR-0001 resolves only once $569 merges; docs/decisions/
does not exist on main yet. No README is added here, to avoid conflicting with
$569's.

Refs $519, $568
@wz-gsa
wz-gsa requested a review from a team as a code owner August 31, 2026 19:40
wz-gsa added a commit that referenced this pull request Sep 2, 2026
…asing)

Both of @pburkholder's inline suggestions on #569:

- "SQL assessment" -> "SQL hardening" in the decision statement. More accurate:
  the overlay's hardening/sql/ scripts remediate, and the assessment is the InSpec
  controls, so "hardening" is the right noun for what sits alongside the profile.
- "cloud.gov" -> "Cloud.gov". Noted the feedback that this gets miscased often; the
  ADR text is now consistent (the rest of the file already used Cloud.gov, so this
  was the single outlier).

The same lowercase form appears once on the #575 branch
(ADR-0002-oracle-baseline-csb-portability.md line 50) and will be fixed there
rather than crossing branches.
Same review point @pburkholder raised on #569: "cloud.gov" -> "Cloud.gov".
Single occurrence on this branch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant