---
tags: Deprecated
---
# DEPRECATION NOTE
This document is deprecated. Please refer to the following for upt-to-date image-builder documentation:

https://github.com/airshipit/images/blob/master/image-builder/README.md

# Image Builder

Image Builder consuming the declarative Image Builder ability to create QCOW from declarative #1
* define airshipctl that will drive imagebuilder https://github.com/airshipit/airshipctl/issues/248
* define documents , what is the host profile https://github.com/airshipit/airshipctl/issues/249
* https://review.opendev.org/#/c/730777/83/image-builder/assets/tests/preconfig/main.yaml. - OS Stuff
* https://review.opendev.org/#/c/730777/83/image-builder/assets/playbooks/roles/iso/defaults/main.yaml. - ISO
* https://review.opendev.org/#/c/730777/83/image-builder/assets/playbooks/roles/img/defaults/main.yaml - QCOW
* https://review.opendev.org/#/c/730777/83/image-builder/assets/playbooks/roles/multistrap/defaults/main.yaml - PACKAGES

GOAL:
- Files should be specified in a common locatiom . such as Node Profile. i.e. common function
- Could files are separated by area :
- The files are all CR's
- And the data under spec is formatted in the expected ansible format. As the examples linked above.
- Networking
- Software
- OS Kernel (Grub/sysctl)
- Distro packages
- Cloud Init ?
- Drivers (i.e. driver)
- Storage:
Partitions
Sizes etc.

LIFECYCLE OF using Node Profile
* Manage / Edit the Node Profile function
* Run airshipctl to create new image
* Create a new Ansible VAR stuff
* Need to agree on what this looks like ...
* example of vars file: [https://raw.githubusercontent.com/openstack/openstack-helm-infra/master/tools/images/kubeadm-aio/assets/opt/playbooks/vars.yaml](https://raw.githubusercontent.com/openstack/openstack-helm-infra/master/tools/images/kubeadm-aio/assets/opt/playbooks/vars.yaml)
* Airshipctl has to do is take the list of variable caataogue from the NodeProfile function and transpose into the appropriate vars file .
* Run the image builder
* There is a new Image NodeProfile(x)
* Take the Image NodeProfile(X) , store that in some registry
* This mean a new URL for the image?
* Need to go in update the VariableCatalogue for specific Images that match the NodeProfile
* BMH should be properly consuming the right image, give the appropriate , the hostgenerator and the replacement.
* How does this relate to ViNO ?

## AirshipImage CR
Yaml document injected into container:

kind: AirshipImage/v1
name: base
spec:
    container:
      volume: ./examples:/config
      image: dukov/image_gen:latest
      containerRuntime: docker
      privileged: false
    builder:
      userDataFileName: user-data
      networkConfigFileName : network-config
      outputMetadataFileName: output-metadata.yaml
      action: #(could be one of build-root, build-iso, build-qcow)
    params:
        #dict containing vars.yaml for ansible to consume
        networking:
            ......
        software:
            ......
        storage:
            ......

apiVersion: airshipit.org/v1alpha1
kind: ImageConfiguration
metadata:
  name: build-qcow-data-plane
  labels:
    airshipit.org/deploy-k8s: "false"
spec:
    image:
      type: iso
      outputFileName: data-plane.qcow2
    container:
      containerRuntime: docker
      image: quay.io/airshipit/image-builder:latest-data-plane
      volume: /srv/iso:/config
      params:
        isobuilder:
          userDataFileName: user-data
          networkConfigFileName : network-config
          outputMetadataFileName: output-metadata.yaml
          action: #(could be one of build-root, build-iso, build-qcow)
        qcowbuilder:
            ....
    params:
        networking:
            ......
        software:
            ......
        storage:
            ......       

Gaps to be discussed
Missing with this approach, we are missing :

### Aspects of the Flow
- How do I declare the information I need. Function == CR
- Airship Image CR is build for a Particular NodeProfile.
- How do I deliver that information to the ImageBuilder
- i.e AirshipImage YAML defined above is similar to teh ISOBuilder presented via a mount to the image builder.
- Image Builder can plaster the AirshipImage YAML into the image.
- As part of the Image Builder tasks, it will copy the AirshipImage into the image into a specified location /etc/imagebuilder/meta
- Deliver AirshipImage CR into teh cluster where they are used
- I.e. AirshipImage could exists per Types of Nodes, i.e. COntrol Plane vs Worker, and VM vs Baremetal, etc...

### Structure of the Function to CR

Relation between document set and AirshipImage CR

Possible approaches
Declare a function :
build .../fuction/AirshipImage

CR
../type/.controlplane
resources:
image/

Consume from within the type images specific location. Multiple image type, that feed proper overrides.

../type/controlplane/image
k....yaml
resources: .../.../AirshipImage
patches:
Stuff that build the control image alteration
../type/workers/image
k....yaml
resources: .../.../AirshipImage
patches:
Stuff that build the control image alteration

__________________

Alternatve, images are discting functions with multiple flavors leveragng each other when appropriate.

build .../function/images/AirshipImageUbuntu
build .../function/images/AirshipImageUbuntuCP
resources : ../AirshipImageUbuntu
patches:...
build .../fuction/AirshipImageUbuntuWORKER
resources : ../AirshipImageUbuntu
patches
build .../fuction/AirshipImageRHEL

### Validation
- How do we ensure what is been passed to the image complies with some business rules
- Given that the information is in an AirshipImage CR, the resources can be validated via the BAU kind api server-based approach. This doesn't apply business/semantic validation.
- ...

- Given that user interacts with document model , how is the user supposed to understand which values are valid or not.
- CR validation will identify Data Type problems
- The ImageBuilder execution will identify problems with the data provided.

### Airshipctl interaction

- Does anything in the AirshipImage CR needs to be encrypted at rest
::: warning :::
GAP: Do we need a way for airshipctl secrets to selectively not decrypt something by default.

- Currently the information we know in teh AirshipImage that is secret is the root password.
- However when we deploy via CAPI the root should be altered .

We need airshipctl <subcommand> <what enrty point for the AirshipImage CR> <which imagebuilder image version im using>
airshipctl phase run <Appropriate Image Phase>

#### Phase Document per Image Type

    apiVersion: airshipit.org/v1alpha1
    kind: Phase
    metadata:
      name: bootstrap
    config:
      executorRef:
        apiVersion: airshipit.org/v1alpha1
        kind: ImageConfiguration
        name: isogen
      documentEntryPoint: airshipctl/manifests/site/test-site/ephemeral/bootstrap
  

#### Executor Document .. TBD if we need more than one.

    apiVersion: airshipit.org/v1alpha1
    kind: ImageConfiguration
    metadata:
      name: isogen
      labels:
        airshipit.org/deploy-k8s: "false"
    builder:
      networkConfigFileName: network-config
      outputMetadataFileName: output-metadata.yaml
      userDataFileName: user-data
    container:
      containerRuntime: docker
      image: quay.io/airshipit/isogen:latest-ubuntu_focal
      volume: /srv/iso:/config

- How do we relate the Node Profile to the appropriate BMH
- Through the image URL of course
- AirshipImage CR is in the deployed host

### Misc Questions:
1. Have we consider existing tooling, in particular: https://www.packer.io ?
- It can be coupled with things like ansible to build custom images.
- They also support cloud specific image generation. If we ever went down the route of deploying images customized for a particular cloud, say azure or gcp, packer has cloud specific plugins.

### Image Builder Phases
Currently the Image Builder docker file builds teh rootfs , by execting some ansiible tasks within teh docker build process. See https://review.opendev.org/maintenance.html#/c/730777/84/image-builder/Dockerfile.ubuntu_bionic

To avoid a two phase integration, the proposal is we will have two phases associated with the iumage builder.

#### Container Building Phase
These phase will simple create the image that represents a rootfs
It wil need to consume a ***AirshipImageRootFS CR or AirshipImage CR*** that delivers the appropriate declared data needed by the Docker file rn ansible roles.
See :
RUN ansible-playbook -i /opt/assets/playbooks/inventory.yaml /opt/assets/playbooks/base-chroot.yaml
https://review.opendev.org/#/c/730777/84/image-builder/assets/playbooks/roles/multistrap/defaults/main.yaml
RUN ansible-playbook -i /opt/assets/playbooks/inventory.yaml /opt/assets/playbooks/base-preconfig.yaml
https://review.opendev.org/#/c/730777/84/image-builder/assets/playbooks/roles/preconfig/defaults/main.yaml

It will also imply that these phase has its own exector that simple knows how to build a docker container and feed it the appropriate source data.

#### QCOW/ISO Building Phase
These phase will have its own exector that knows how to :
- Execute a docker container
- feed it the appropriate data ***AirshipImage*** .