As mentioned above, the template-level
.InstallRepos functions return a list of repo objects that can be used for further template expansion. The repo object contains its own fields and functions that can be used for template expansion.
|The tag that uniquely identifies one repository definition. The template-level
.Repos function takes a list of tags and returns repos that exactly match them.
|A list of operating systems (in distro-release format) that this repository supports. The template-level
.MachineRepos function matches this field against the current
.Machine.OS field to determine which templates are applicable to a machine.
|The URL to the top of the repository in question. For yum-style repos, it can either point directly to a specific repository (in which case
.Components fields must not be present), or point to a location that contains an appropriately mirrored repo tree for the OS in question (in which case it cannot be used as an
InstallSource or a
.Components must be set). For apt-style repos, it must point to the top level of the repository (the level that has
pool as subdirectories), and
.Components must always be defined.
|An optional field that can be used to determine what kind of packages the repository returns. It is normally autodetected based on the operating system the repo is being used in.
|The type of repository this is. It is optional, and is normally inferred based on the operating system the repo is being used in.
|A boolean value that determines whether this repository should be used as a package source during OS installation. You should have at most one of these per OS install you wish to support.
|A boolean value that determines whether this repository should be used as a source of security updates that should be applied during an OS install.
|A string that corresponds to the OS release version or codename. This must be present for apt-style repos.
|A list of strings that map to any sub-repositories available as part of this repository. Examples are
non-free for apt-based repos.
|A helper function that refers back to the top-level template rendering context.
|A helper function that joins the
.Components list into a space-seperated string.
|A helper function that returns an appropriately formatted URL for the passed component.
|A helper function that returns the repo in a format suitable for inclusion in an unattented OS installation file (kickstart, preseed, etc.) The format returned is currently hardcoded depending on the OS type of the machine. That restriction will be lifted in future versions of dr-provision.
|A helper function that returns the repo in a format suitable for direct inclusion into a repo definition file (
/etc/yum.repos.d/some.repo, etc). The format returned is currently hardcoded based on the OS type of the machine. That restriction will be lifted in future versions of dr-provision.
Expanding Package Repositories¶
To expand the repos suitable for OS installation, use:
To expand the repos suitable for post-install package management, use:
By default, local package repositories provided by exploded OS install media is made available as a set of extra repositories that override matching install repositories from the package-repositories param.
These extra repositories will always be present if the ISO associated with a bootenv has been uploaded to DRP. They are treated as if you defined a custom entry in the
package-repositories param that pointed back to the location the ISO exploded to + the location we expect the package repositories on the ISO to be at. They will always behave as if they were install sources.