---
# System prepended metadata

title: Image Config

---

# Image Config

Currently `ImageConfig` is mapped to `OSConfig` and then applied to an OS Pipeline, more or less 1:1.

`ImageConfig` expresses what configuraiton to apply. We would like to change the logic and instead express the intent, as various high-level abstractions.

Example: the `EC2Environment`, say, knows what NPT servers and settings should be applied in EC2 images. So in the OS Pipeline serialization we query the `Environment` to decide which ones to apply. As long as the enivornment for each cloud platform has the right information, we will end up with the right settings in each of the image types for the platform. This is different from how it is now, where each of the image types for the platform in question would need to set the right NTP options, so the knowledge is represented once per image type, rather than only once.

Getting the abstractions right might not be obvious in all the cases. The below is a first draft to get a feel for it. We may want to change/add abstractions to get something that better models reality.

## NTP

If this is configured by the user, use only that (mixing and matching NTP servers is a bad idea).

Otherwise, this should be configured in the environment. Each cloud provider likely have their own guidelines.

* EC2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html
* Azure: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/time-sync
* GCP: https://cloud.google.com/compute/docs/instances/configure-ntp
* others?

## RHSMConfig

We should probably have a top-level abstraction that express how we connect back to RH.

## Sysconfig

Defaults set for RHEL9. Override defined for some image types, but mostly redundant. Exceptions:

* Kernel name for azure and gcp. `kernel` v `kernel-core`. Mistake?
* On EC2 networking configuariton is defined in terms of ifcfg. Mistake?

Introduce new abstractions:
* Kernel config (part of the workload or something more fundamental?)
* Networking (likely part of the environment)

## Modprobe

Each platform should declare modules to blacklist.

## Cloud init

Default user should perhaps be configured in the environment? Logging / Telemetry in the platform?

## Dracut

 * Added modules should be part of the platform
 * On EC2 we add sgdisk, presumably to grow the disk. Is this right? Should it be on more platforms? Should we make this part of the platform?

## Logind

Number of virtual terminals feels like a platform thing.

## sshd

Probably should be configured as part of the environment.

## WAAgent / GCPGuestAgent

Part of the environment? Depends a bit what the options do.

## Udev rules

This fiddles with the hardware, should be part of the platform.


