Repository navigation
ROX-36856: delete the Compliance 1.0 implementation tree - #23446
Draft
taimurhafeez wants to merge 7 commits into
Draft
taimurhafeez wants to merge 7 commits into
taimurhafeez wants to merge 7 commits into
Conversation
Unregister the v1 ComplianceService and ComplianceManagementService and drop the /api/compliance/export/csv route, making the Compliance 1.0 API surface unreachable. This is the first backend cut; the now-orphaned central/compliance tree is deleted in follow-ups. /api/splunk/ta/compliance is kept as a stub returning 410 Gone rather than being deleted outright. The acceptance criteria require existing Splunk TA Compliance feed configurations to fail closed: a 404 is liable to be retried as transient by a modular input, and an empty 200 would be indexed as "no compliance findings" -- both hide the removal. The stub no longer takes a datastore, which decouples central/splunk from central/compliance so that tree can be removed independently. qa-tests-backend's ComplianceTest exercises only the removed v1 API, so it is deleted along with the service and object classes that became orphaned with it. This change was partially generated with the help of an AI agent. Co-Authored-By: Claude Opus 5
The previous CHANGELOG entry pointed Splunk TA users at Compliance v2 as the replacement. That is accurate for the gRPC/REST APIs but misleading for the feed: there is no v2 Splunk feed (RFE-9120 / RFE-6372, out of scope here), so a reader would expect to reconfigure the TA and keep receiving data. This also matters more than it first appears for Compliance Operator users. CO results reach the retired feed through the pre-v2 bridge (central/complianceoperator/manager -> GetMachineConfigs -> compliance domain -> MachineConfigResults in v1 storage), so retiring it stops CO results reaching Splunk even though the Compliance Operator itself is unaffected. Split the entry in two and say outright that no Splunk replacement exists. This change was partially generated with the help of an AI agent. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Removes the Compliance 1.0 engine now that nothing calls it: the API surface went in #23360, the service layer in #23399 and the GraphQL resolvers in #23438. This deletes the code those PRs orphaned. Deleted: central/compliance/ (the standards, checks and aggregation engine), central/scrape/ (node scraping existed only to feed it), and the pre-v2 Compliance Operator bridge under central/complianceoperator/{manager,pipelines,checkresults,profiles, rules,scans,scansettingbinding}/ which funnelled Compliance Operator results into v1 storage. Only v2/ remains there; Compliance v2 is untouched. Two things the diff does not explain: - The MsgFromSensor_ScrapeUpdate case is gone from the sensor connection handler. Older sensors can still send it, so it now falls through to the event pipeline and is dropped there. Reserving the proto fields belongs to the follow-up that cuts the Sensor side; the message is inert either way once the controller is gone. - The search service's aggregator dependency is removed outright rather than stubbed. It only ever served the COMPLIANCE autocomplete category, so a stub would have been unreachable code. The five Compliance 1.0 Postgres tables survive this PR. GORM AutoMigrate never drops, so they need an explicit migration. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Skipping CI for Draft Pull Request. |
Contributor
🚀 Build Images ReadyImages are ready for commit 1e4ac30. To use with deploy scripts: export MAIN_IMAGE_TAG=5.1.x-284-g1e4ac30f5c |
3 of 9 tasks
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
1 participant
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.
Description
Fourth backend cut of Compliance 1.0 removal (ROX-36856). The previous PRs removed the callers; this deletes the implementation they orphaned. 338 files, −28,405 lines, 1 insertion.
central/splunkimportscentral/complianceuntil #23399, and the GraphQL resolvers do until #23438. Review against those, not master.Deleted
central/compliance/central/scrape/central/complianceoperator/{manager,pipelines}/central/complianceoperator/{checkresults,profiles,rules,scans,scansettingbinding}/scale/tests/compliance_test.gocentral/complianceoperator/v2/is untouched, and so is everyv2-suffixed sensor pipeline. Compliance v2 is not affected by this PR.Three judgement calls worth a look
MsgFromSensor_ScrapeUpdateno longer has a case in the sensor connection handlereventPipeline.Runand is dropped there. This is deliberate: the message is inert once the controller is gone, and reserving the proto fields belongs to the follow-up PR that cuts the Sensor side. Flagging it because it is the one behavioural change here rather than a pure deletion.Aggregatordependency is removed outright, not stubbedWithAggregator, the builder field and theserviceImplfield all go. Its only consumer was theSearchCategory_COMPLIANCEautocomplete entry, so a stub would have been unreachable code on a public builder interface.COMPLIANCE_STANDARDandCOMPLIANCE_CONTROLdropped from the global index options mapcentral/compliance/standards/index. They are 1.0-only categories, distinct from anything v2 registers.Not in this PR
compliance/collection/compliance_checks/and the scrape path insensor/common/compliance/, plus reservingScrapeConfig/TriggerRunincompliance_iservice.proto.compliance_{configs,domains,run_metadata,run_results,strings}plus the five v1 Compliance Operator tables (compliance_operator_{check_results,profiles,rules,scans,scan_setting_bindings}) that surfaced when the datastores above turned out to be orphaned. These are distinct from v2's tables.resources.Complianceis intentionally untouched — it is shared with Compliance v2 and is a customer-visible permission name.User-facing documentation
No CHANGELOG entry. #23399 already covers the Compliance 1.0 removal for release notes; this PR deletes code that is unreachable by the time it lands.
Testing and quality
Automated testing
Pure deletion, so no new tests. The tests that went are the ones belonging to the deleted packages.
central/sensor/service/connection/mocks/connection.gois regenerated output — theScrapesmethod and its import are gone because the interface method is.How I validated my change
go build ./...— passgo vet ./...— passgo vet -tags test ./...— pass, type-checking thetest-tagged files the way CI does. The only output is pre-existingcopies lock valuenoise from generated easyjson inpkg/compliance/compress, which this branch does not touch.go test -tags test ./central/...— all pass exceptcentral/clusters/zip, which panics ininit()viatestutils.MustBeInTest. I reproduced that in a clean worktree at the base commit, so it is pre-existing and unrelated.grepsweep forcentral/compliance/,central/scrapeand each deletedcomplianceoperatorsubpackage across Go and non-Go files (yaml, sh, Makefile, json) — zero hits.gofmt— clean.central/graphql/resolvers/generated.gois deliberately left as the generator emits it; it is not gofmt-clean on master either, and formatting it by hand would break thecheck-generated-filesregeneration diff.🤖 Co-Generated with Claude Code