Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

feature: mutate spec object references for other published resources

未关闭
  • 哪里不对？
#23 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
go, kubernetes
领域
backend-api-design, distributed-systems

调研方向

从 PublishedResources API 以及在 #19 中重新启用的 mutation 阶段开始。跟踪已发布资源的重命名规则是如何表示的，以及如何识别诸如 spec.configRef.name 这样的引用。完成的标准是 API 能够声明目标资源，并且同步对象对被引用的资源使用转换后的名称。

由索引模型根据 Issue 内容生成。

描述

kind/feature
Feature Description

For namespaced resources, syncing from kcp to a Kubernetes cluster (3D space to 2D space, in a way) is usually not a problem because our default resource renaming rules put everything under its own namespace, so e.g. related resources such as Secrets do not create problems with their naming (a secretRef in an object pointing to my-secret is not creating conflicts because everything will happen in a generated namespace of the format WORKSPACE-NAMESPACE [with hashes, but you get the idea]).

This is however not possible with cluster-scoped resources in general, plus referencing other published resources would also create similar problems. Think of the following manifests that I want to create in kcp with both being synced down to a service provider cluster:

apiVersion: service/v1
kind: Config # a cluster-scoped resource
metadata:
  name: my-config
spec: {}
---
apiVersion: service/v1
kind: ServiceInstance # a namespace-scoped resource
metadata:
  name: my-instance
  namespace: my-namespace
spec:
  configRef:
    name: my-config # a reference to my Config object from above

What is needed is a way to describe object references like this (basically say: spec.configRef.name in the ServiceInstance kind is a reference to another resource that is within the realm of the api-syncagent) in PublishedResources.

Since the api-syncagent knows about the renaming rules of other resources published via PublishedResources, it should mutate spec.configRef.name to the name that it translated the my-config object to. So on the service provider side, these objects should look somewhat like this:

apiVersion: service/v1
kind: Config # a cluster-scoped resource
metadata:
  name: iuc6yffea77crveb-7505d64a54e061b7acd5
spec: {}
---
apiVersion: service/v1
kind: ServiceInstance # a namespace-scoped resource
metadata:
  name: my-instance
  namespace: org-ucdyfdsa7trvfa-sdadsjdjwwewads
spec:
  configRef:
    name: iuc6yffea77crveb-7505d64a54e061b7acd5 # a reference to my Config object from above
Proposed Solution

I'm not fully clear on how the API should look, but most likely a PublishedResource should have a way to mark object references and define what resource is being referenced here. The api-syncagent would need to hold an internal representation of all renaming rules depending on resources, and would then use those rules in the mutation phase we recently re-enabled in #19.

Alternative Solutions

No response

Want to contribute?
  • I would like to work on this issue.
Additional Context

No response

主要语言
Go
星标
25
派生
30
平均合并
5 天 18 小时
30 天内合并 PR
1

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

kcp-dev/api-syncagent 的其他 Issue

查看 kcp-dev/api-syncagent 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。