Document MultiKueue migration to ClusterProfile accessProviders

[kahirokunn]

What type of PR is this?

/kind kep
/area multikueue

What this PR does / why we need it:

Updates KEP-693 to document MultiKueue's migration from ClusterProfile credentialsProviders to accessProviders.

The Cluster Inventory API renamed the provider concept because the old credentialProviders field actually carries cluster access information rather than credential material. The new accessProviders field is now the preferred API, and credentialProviders is deprecated:

• rename the credential provider field cluster-inventory-api#23 introduced the rename direction.
• Rename credentials to access cluster-inventory-api#52 propagated the rename from credentials to access in the Cluster Inventory API code.

The Cluster Inventory API still keeps compatibility for the deprecated field today, but that compatibility is expected to be removed in the future:

• Remove credential provider compatibility cluster-inventory-api#65 tracks removal of credential provider compatibility.

Because MultiKueue consumes ClusterProfile access information, this KEP update records the intent to migrate before the deprecated Cluster Inventory API field is removed. The KEP now describes multiKueue.clusterProfile.accessProviders as the preferred MultiKueue configuration field, keeps credentialsProviders as a deprecated compatibility field, and records the precedence rule when both fields define the same provider name.

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

This is a KEP-only follow-up for the API shape being implemented in #12011.

AI disclosure: This PR was written in part with the assistance of generative AI.

Does this PR introduce a user-facing change?

NONE

Summary by CodeRabbit

• Documentation
  • Updated MultiKueue ClusterProfile configuration documentation with a new accessProviders field for cluster access provisioning
  • Deprecated credentialsProviders field in favor of accessProviders while maintaining backward compatibility
  • Documented precedence rules and migration guidelines for configurations using both provider fields

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue canceled.

Name	Link
🔨 Latest commit	1178c49
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-kueue/deploys/6a27da54d4461200093f871e

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kahirokunn
Once this PR has been reviewed and has the lgtm label, please assign mimowo for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request updates the KEP-693 README to document a ClusterProfile API schema migration: introducing an accessProviders configuration field while retaining credentialsProviders as a deprecated backward-compatible field. The changes include type definitions, precedence rules, and updated authentication flow terminology.

Changes

ClusterProfile API Schema Migration

Layer / File(s)	Summary
ClusterProfile configuration schema update keps/693-multikueue/README.md	Added accessProviders list to ClusterProfile API example, introduced ClusterProfileAccessProvider type with Name and ExecConfig, made ClusterProfileCredentialsProvider a type alias, and documented precedence rules stating accessProviders takes priority when both provider fields are set; status.accessProviders is preferred on the API side while status.credentialProviders remains supported.
Authentication flow terminology update keps/693-multikueue/README.md	Updated authentication flow step to reference matching an "access provider" from the controller's configured access-provider list when invoking the credential plugin.
Implementation history and cleanup keps/693-multikueue/README.md	Added 2026-06-09 implementation history entry documenting accessProviders configuration support and credentialsProviders deprecation; removed trailing whitespace.

🎯 2 (Simple) | ⏱️ ~8 minutes

🐰 A schema refactor, clean and bright,
Access providers now take flight!
Old credentials fade away,
New compatibility saves the day. ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Document MultiKueue migration to ClusterProfile accessProviders' directly and clearly summarizes the main change: documenting the migration from credentialsProviders to accessProviders in the KEP-693 README.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@keps/693-multikueue/README.md`:
- Around line 296-299: The README claims
`accessProviders`/`status.accessProviders` as the preferred source but the
codebase still validates and uses
`credentialsProviders`/`status.credentialProviders`; either change the prose to
state this is a planned/stack-dependent migration (explicitly note that
validation and controller wiring still rely on `credentialsProviders` and
`status.credentialProviders`) or update the implementation to match the doc by
switching validation and controller logic to prefer
`accessProviders`/`status.accessProviders`; specifically, modify the code paths
referenced (apis/config/v1beta2/configuration_types.go,
pkg/config/validation.go, and
pkg/controller/admissionchecks/multikueue/controllers.go) to read/validate
`accessProviders` and `status.accessProviders` (ensuring name precedence
semantics where `accessProviders` wins) or else adjust the README text to
clearly scope the change as migration-only and mention the existing fields
(`credentialsProviders`/`status.credentialProviders`) remain authoritative until
code is updated.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9d3d46f9-c49b-4ae1-8386-baeacf81e089

📥 Commits

Reviewing files that changed from the base of the PR and between f924f8e and 1178c49.

📒 Files selected for processing (1)

• keps/693-multikueue/README.md

[mimowo]

cc @hdp617 @olekzabl @kshalot

[kshalot]

/lgtm

Thank you for aligning this!

[k8s-ci-robot]

LGTM label has been added.

Details

Git tree hash: da19f51fae24a9cdb6edfaa75ec8616839a36601

[kshalot]

Although let's hold off merging this until #12011 is merged. I doubt the implementation will change much, so the KEP diff will likely stay the same, but just in case.

[hdp617]

I'm just curious why combining providers from both fields instead validate that they should be mutually exclusive.

[hdp617]

/lgtm

Thank you for making this change. Just a quick question re. the behavior when both are specified.

[k8s-ci-robot]

@hdp617: changing LGTM is restricted to collaborators

Details

In response to this:

/lgtm

Thank you for making this change. Just a quick question re. the behavior when both are specified.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.