Skip to content

Latest commit

 

History

History
197 lines (135 loc) · 6.9 KB

ocm_bootstrap_package.md

File metadata and controls

197 lines (135 loc) · 6.9 KB

ocm bootstrap package — Bootstrap Component Version

Synopsis

ocm bootstrap package [<options>] <action> {<component-reference>} {<resource id field>}

Aliases

package, pkg, componentversion, cv, component, comp, c

Options

      --config stringToString   driver config (default [])
  -C, --create-env string       create local filesystem contract to call executor command locally
  -c, --credentials string      credentials file
  -h, --help                    help for package
      --lookup stringArray      repository name or spec for closure lookup fallback
  -o, --outputs string          output file/directory
  -p, --parameters string       parameter file
      --repo string             repository name or spec

Description

Use the simple TOI bootstrap mechanism to execute actions for a TOI package resource based on the content of an OCM component version and some command input describing the dedicated installation target.

The package resource must have the type toiPackage. This is a simple YAML file resource describing the bootstrapping of a dedicated kind of software. See also the topic ocm toi-bootstrapping.

This resource finally describes an executor image, which will be executed in a container with the installation source and (instance specific) user settings. The container is just executed, the framework make no assumption about the meaning/outcome of the execution. Therefore, any kind of actions can be described and issued this way, not only installation handling.

The first matching resource of this type is selected. Optionally a set of identity attribute can be specified used to refine the match. This can be the resource name and/or other key/value pairs (<attr>=<value>).

If no output file is provided, the yaml representation of the outputs are printed to standard out. If the output file is a directory, for every output a dedicated file is created, otherwise the yaml representation is stored to the file.

If no credentials file name is provided (option -c) the file TOICredentials is used, if present. If no parameter file name is provided (option -p) the file TOIParameters is used, if present.

Using the credentials file it is possible to configure credentials required by the installation package or executor. Additionally arbitrary consumer ids can be forwarded to executor, which might be required by accessing blobs described by external access methods.

The credentials file uses the following yaml format:

  • credentials map[string]CredentialsSpec

    The resolution of credentials requested by the package (by name).

  • forwardedConsumers []ForwardSpec (optional)

    An optional list of consumer specifications to be forwarded to the OCM configuration provided to the executor.

The CredentialsSpec uses the following format:

  • consumerId map[string]string

    The consumer id used to look up the credentials.

  • consumerType string (optional) (default: partial)

    The type of the matcher used to match the consumer id.

  • reference yaml

    A generic credential specification as used in the ocm config file.

  • credentials map[string]string

    Direct credential fields.

One of consumerId, reference or credentials must be configured.

The ForwardSpec uses the following format:

  • consumerId map[string]string

    The consumer id to be forwarded.

  • consumerType string (optional) (default: partial)

    The type of the matcher used to match the consumer id.

If provided by the package it is possible to download template versions for the parameter and credentials file using the command ocm bootstrap configuration.

Using the option --config it is possible to configure options for the execution environment (so far only docker is supported). The following options are possible:

  • CLEANUP_CONTAINERS
  • DOCKER_DRIVER_QUIET
  • NETWORK_MODE
  • PULL_POLICY
  • USERNS_MODE

Using the option --create-env <toi root folder> it is possible to create a local execution environment for an executor according to the executor image contract (see ocm toi-bootstrapping). If the executor executable is built based on the toi executor support package, the executor can then be called locally with

<executor> --bootstraproot <given toi root folder>

If the --repo option is specified, the given names are interpreted relative to the specified repository using the syntax

<component>[:<version>]

If no --repo option is specified the given names are interpreted as located OCM component version references:

[<repo type>::]<host>[:<port>][/<base path>]//<component>[:<version>]

Additionally there is a variant to denote common transport archives and general repository specifications

[<repo type>::]<filepath>|<spec json>[//<component>[:<version>]]

The --repo option takes an OCM repository specification:

[<repo type>::]<configured name>|<file path>|<spec json>

For the Common Transport Format the types directory, tar or tgz is possible.

Using the JSON variant any repository types supported by the linked library can be used:

Dedicated OCM repository types:

  • ComponentArchive: v1

OCI Repository types (using standard component repository to OCI mapping):

  • CommonTransportFormat: v1
  • OCIRegistry: v1
  • oci: v1
  • ociRegistry


If a component lookup for building a reference closure is required the --lookup option can be used to specify a fallback lookup repository. By default, the component versions are searched in the repository holding the component version for which the closure is determined. For Component Archives this is never possible, because it only contains a single component version. Therefore, in this scenario this option must always be specified to be able to follow component references.

Examples

$ ocm toi bootstrap package ghcr.io/mandelsoft/ocm//ocmdemoinstaller:0.0.1-dev

SEE ALSO

Parents

  • ocm bootstrap — bootstrap components
  • ocm — Open Component Model command line client
Additional Links