Skip to main content

install-config-changes

Rules for modifying the install-config format. Use when making any changes in the `pkg/types` package or its subpackages.

来源信息

仓库
openshift/installer
最近来源活动
2026年9月18日 18:31
检测到的 SKILL.md 语言
英语
星标
1,558
Forks
1,529

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
install-config-changes
description
Rules for modifying the install-config format. Use when making any changes in the `pkg/types` package or its subpackages.
user-invocable
false
## Deprecating existing fields NEVER remove fields from or rename fields in the install-config. When modifying an existing field, update the comment to note that it is deprecated. Change the name of the existing Golang struct field to prepend `Deprecated`, but do NOT change the json tag. Convert data from deprecated fields in the `pkg/types/conversion` package. ## Versioning Do not update the install-config version. ## Default values If a new field has a default value, set it once in `SetInstallConfigDefaults()` (or one of the platform-specific functions it calls out to, if the field is platform-specific) rather than everywhere that the field is referenced. ## Validation Add validation code for any new field in `pkg/types/validation` (or `pkg/types/<platform>/validation` for platform-specific fields). ## Consider the agent-based method The agent-based installation method uses the same install-config format, but all of the data must be passed through assisted-service using the cluster-manifests defined in `pkg/asset/agent/manifests`. (assisted-service uses this data to internally generate another install-config.) New fields are not automatically passed through. When adding a new field, you MUST ensure that it is correctly handled in agent-based installs. Use the following steps in order: ### Check for a non-supported platform If the new field is platform-specific, check the list of platforms in `agent.IsSupportedPlatform()`. If the platform is not supported for agent-based installations then no agent-specific changes are required. ### Use an existing cluster-manifest field The new field may already exist in one of the cluster-manifest types. Try fetching the latest version of the `github.com/openshift/assisted-service/api` module to see. If an equivalent field already exists, populate it using data from the install-config. Sometimes this requires type or string conversion. ### Use an install-config override Fields that do not have a first-class representation in the cluster-manifests can nonetheless be passed through to the install-config generated by assisted-service via the install-config overrides annotation on the `AgentClusterInstall` manifest. For this to work though, the field must first exist in the [assisted-service's local copy of the install-config struct](https://raw.githubusercontent.com/openshift/assisted-service/refs/heads/master/internal/installcfg/installcfg.go). ### Warn about ignored fields At the absolute minimum, any fields that are ignored by the agent-based method MUST generate a warning in the validation of `agent.OptionalInstallConfig` iff they are set to a non-default value. ## Regenerate the CRD When any part of a struct (including comments!) is modified, you must regenerate the CRD (and the deepcopy methods) using the command: ```bash go generate ./pkg/types/installconfig.go ```
在 GitHub 查看