Skip to content

feat: support multiple InitTargets for the same WorkspaceType#20

Open
ifdotpy wants to merge 1 commit intokcp-dev:mainfrom
ifdotpy:fix/multi-inittarget-race
Open

feat: support multiple InitTargets for the same WorkspaceType#20
ifdotpy wants to merge 1 commit intokcp-dev:mainfrom
ifdotpy:fix/multi-inittarget-race

Conversation

@ifdotpy
Copy link
Copy Markdown
Contributor

@ifdotpy ifdotpy commented Apr 2, 2026 •
edited
Loading

Summary

Makes multiple InitTarget resources for the same WorkspaceType a first-class feature. The targetcontroller now keys controllers by WorkspaceType reference (path:name) instead of InitTarget UID. Sources from all matching InitTargets are aggregated into a single initialization pass, and the initializer is only removed after every source from every target is applied.

Why

Previously, the docs stated that only a single InitTarget per WorkspaceType was supported — a second InitTarget referencing the same WorkspaceType would race the first and one set of templates could be silently skipped. This change lets users compose bootstrapping behavior from independently authored InitTargets (e.g. RBAC, quotas, networking) without racing on the initializer.

Changes

  • internal/controller/targetcontroller: key controllers by WSType ref (path:name), track InitTarget names per WorkspaceType, aggregate provider returns all matching targets, only cancel the manager when the last target for a WorkspaceType is deleted.
  • internal/controller/initcontroller: InitTargetsProvider returns []*InitTarget instead of a single target; reconcile iterates sources from all of them.
  • Rename InitTargetProvider → InitTargetsProvider (plural) per review feedback.
  • docs/content/setup/development.md: update warning to reflect new behavior.

Backward compatibility

Fully backward compatible. A single InitTarget per WorkspaceType continues to work unchanged.

Fixes #17

Support multiple InitTargets for the same WorkspaceType. The init-agent now aggregates sources from all matching InitTargets into a single initialization pass.

@kcp-ci-bot kcp-ci-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has signed the DCO. labels Apr 2, 2026
@kcp-ci-bot
Copy link
Copy Markdown
Contributor

kcp-ci-bot commented Apr 2, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign xrstf 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:

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

@kcp-ci-bot kcp-ci-bot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Apr 2, 2026
@kcp-ci-bot
Copy link
Copy Markdown
Contributor

kcp-ci-bot commented Apr 2, 2026

Hi @ifdotpy. Thanks for your PR.

I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

@kcp-ci-bot kcp-ci-bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Apr 2, 2026
@xrstf
Copy link
Copy Markdown
Contributor

xrstf commented Apr 8, 2026

As per documentation

This means there can only be exactly one InitTarget in the entire kcp installation that refers
to a WorkspaceType. And only a single init-agent may process each InitTarget.

So if anything, I'd call this a feature, not a bugfix ;-)

@ifdotpy
Copy link
Copy Markdown
Contributor Author

ifdotpy commented Apr 8, 2026

As per documentation

This means there can only be exactly one InitTarget in the entire kcp installation that refers

to a WorkspaceType. And only a single init-agent may process each InitTarget.

So if anything, I'd call this a feature, not a bugfix ;-)

Haha, I do not mind at all :) I will rename it soon

xrstf
xrstf reviewed Apr 8, 2026
View reviewed changes
internal/controller/targetcontroller/controller.go Outdated
target := &initializationv1alpha1.InitTarget{}
if err := r.localClient.Get(ctx, types.NamespacedName{Name: name}, target); err != nil {
return nil, err
func (r *Reconciler) newInitTargetProvider(wstKey string) initcontroller.InitTargetProvider {
Copy link
Copy Markdown
Contributor

@xrstf xrstf Apr 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's rename this to newInitTargetsProvider (plural) (including the func type InitTargetProvider and all other refs

@ifdotpy
feat: support multiple InitTargets for the same WorkspaceType
07ed564 
Previously, init-agent documentation stated that only a single InitTarget
per WorkspaceType was supported — a second InitTarget referencing the
same WorkspaceType would race the first and one set of templates could
be silently skipped.

This change makes multiple InitTargets per WorkspaceType a first-class
feature. The targetcontroller now keys controllers by WorkspaceType
reference (path:name) instead of InitTarget UID. Sources from all
matching InitTargets are aggregated into a single initialization pass,
and the initializer is only removed after every source from every
target is applied.

- internal/controller/targetcontroller: key by WSType ref, track
  InitTarget names per key, aggregate provider returns all matching
  targets, cancel manager only when the last target is deleted.
- internal/controller/initcontroller: InitTargetsProvider returns
  []*InitTarget; reconcile iterates sources from all of them.
- Rename InitTargetProvider -> InitTargetsProvider (plural) per
  review feedback from @xrstf.

Fixes kcp-dev#17

Signed-off-by: Igor Fominykh <ifdotpy@gmail.com>
@ifdotpy ifdotpy force-pushed the fix/multi-inittarget-race branch from 8fa3a12 to 07ed564 Compare April 9, 2026 05:02
@ifdotpy ifdotpy changed the title fix: aggregate sources from multiple InitTargets for the same WorkspaceType feat: support multiple InitTargets for the same WorkspaceType Apr 9, 2026
@ifdotpy
Copy link
Copy Markdown
Contributor Author

ifdotpy commented Apr 9, 2026

Thanks for the review @xrstf!

Addressed:

  • Renamed to feat: and reworked the title/description to frame it as a supported feature
  • Renamed InitTargetProvider → InitTargetsProvider (plural) and all call sites
  • Updated docs/content/setup/development.md to reflect the new behavior

Force-pushed the amended commit with DCO signoff intact.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@xrstf xrstf xrstf left review comments

Assignees

No one assigned

Labels

dco-signoff: yes Indicates the PR's author has signed the DCO. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Multiple InitTargets for the same WorkspaceType: race condition causes skipped templates

3 participants

@ifdotpy @kcp-ci-bot @xrstf