Component Version
The ComponentVersion
API produces component descriptors for a specific component version.
Example
The following is an example of a ComponentVersion:
In the above example:
- A ComponentVersion named
podinfo
is created, indicated by the.metadata.name
field. - The ocm-controller checks the OCM repository every 10m0s, indicated by the
.spec.interval
field. - It retrieves the version matching the semver constraint specified by
.spec.version.semver
field. - The resolved component descriptor and version are written to the
.status.componentDescriptor
and.status.reconciledVersion
fields. - Whenever a new version is available that satisfies
.spec.version.semver
and is greater than.status.reconciledVersion
then the ocm-controller will fetch the new component version.
You can run this example by saving the manifest into componentversion.yaml
.
- Apply the resource to the cluster:
- Run
kubectl get componentversion
to see the ComponentVersion
- Run
- Run
kubectl describe componentversion podinfo
to see the ComponentVersion Status:
- Run
- View the ComponentDescriptor for this ComponentVersion by running
Writing a ComponentVersion spec
As with all other Kubernetes config, an ComponentVersion needs apiVersion
, kind
, and metadata
fields. The name of an ComponentVersion object must be a valid DNS subdomain name.
An ComponentVersion also needs a .spec
section.
Component
.spec.component
is a required field that specifies the name of the component.
Version
.spec.version.semver
specifies a semantic version constraint that is used to determine the specific component version or range of versions that will be reconciled.
Repository
.spec.repository
provides the necessary configuration for the ocm-controller
to access the OCI repository where the component version is stored.
URL
.spec.repository.url
is a required field that denoting the registry in which the OCM component is stored.
Secret Reference
.spec.repository.secretRef.name
is an optional field to specify a name reference to a Secret in the same namespace as the ComponentVersion, containing authentication credentials for the OCI repository.
This secret is expected to contain the keys username
and password
. You can create such a secret using kubectl
:
Service Account Name
.spec.serviceAccountName
is an optional field to specify a name reference to a Service Account in the same namespace as the ComponentVersion. The controller will fetch the image pull secrets attached to the service account and use them for authentication.
Public OCI Repository access
that for a publicly accessible OCI repository, you don’t need to provide a secretRef nor serviceAccountName.
Interval
.spec.interval
is a required field that specifies the interval at which the ComponentVersion must be reconciled.
After successfully reconciling the object, the ocm-controller requeues it for inspection after the specified interval. The value must be in a Go recognized duration string format, e.g. 10m0s
to reconcile the object every 10 minutes.
If the .metadata.generation
of a resource changes (due to e.g. a change to the spec), this is handled instantly outside the interval window.
Verify
.spec.verify
is an optional list of signatures that should be validated before the component version is marked as verified. A ComponentVersion that is not verified will not be consumed by downstream ocm-controller resources. Each signature item consists of a name
and a publicKey
.
Name
.spec.verify.[].name
is a required field that specifies the name of the signature that should be verified.
Public Key
.spec.verify.[].publicKey
is a required field that specifies a reference to a secret containing the public key that can be used to verify the signature. The key of the public key in the secret must match the name of the signature.
For example, the following ComponentVersion verifies two signatures:
The accompanying secret should be in the following format:
Suspend
.spec.suspend
is an optional field to suspend the reconciliation of a ComponentVersion. When set to true, the controller will stop reconciling the ComponentVersion. When the field is set to false or removed, it will resume.
Debugging ComponentVersions
There are several ways to gather information about a ComponentVersion for debugging purposes.
Describe the ComponentVersion
Describing an ComponentVersion using kubectl describe componentversion <repository-name>
displays the latest recorded information for the resource in the Status and Events sections:
Trace emitted Events
To view events for specific ComponentVersion(s), kubectl
events can be used in combination with --for
to list the Events for specific objects. For example, running:
outputs:
Besides being reported in Events, the reconciliation errors are also logged by the controller. You can use a tool such as stern in tandem with grep
to filter and refine the output of controller logs:
will output the following log stream:
ComponentVersion Status
Observed Generation
The ocm-controller reports an observed generation in the ComponentVersion’s .status.observedGeneration
. The observed generation is the latest .metadata.generation
which resulted in either a ready state, or stalled due to error it can not recover from without human intervention.
Conditions
ComponentVersion has various states during its lifecycle, reflected as Kubernetes Conditions. It can be reconciling while fetching the remote ComponentVersion or verifying signatures, it can be ready, or it can fail during reconciliation.
Component Descriptor
The status contains a reference to the component descriptor for the reconciled component version.
The following fields make up the reference:
name
: name of the reconciled component.version
: version of the reconciled component.extraIdentity
: additional identity attributes of the reconciled component.references
: a list of component references.componentDescriptorRef
: a reference to the ComponentDescriptor Kubernetes representation.
Reconciled Version
The reconciled version status field holds the specific version that was reconciled by the ocm-controller.