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.

Datos de origen

Repositorio
openshift/installer
Última actividad en el origen
18 de septiembre de 2026 a las 18:31
Idioma detectado de SKILL.md
inglés
Estrellas
1559
Forks
1527

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
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 ```
Ver en GitHub