func populate(ctx context.Context, loader registry.Load, graphLoader registry.Gr 				if err != nil { 					return err 				}-				cleanups := make(chan func(), 1)-				errs := make(chan error, 1)+				type unpackedImage struct {+					to      image.Reference+					from    string+					cleanup func()+					err     error+				}+				unpacked := make(chan unpackedImage) 				for bundle := range bundles {-					if _, ok := overwriteImageMap[img.Bundle.Package]; !ok {-						overwriteImageMap[img.Bundle.Package] = make(map[image.Reference]string, 0)-					} 					// parallelize image pulls 					go func(bundle registry.BundleKey, img *registry.ImageInput) { 						if bundle.CsvName != img.Bundle.Name { 							to, from, cleanup, err := unpackImage(ctx, reg, image.SimpleReference(bundle.BundlePath))-							if err != nil {-								errs <- err-							}-							cleanups <- cleanup-							overwriteImageMap[img.Bundle.Package][to] = from+							unpacked <- unpackedImage{to: to, from: from, cleanup: cleanup, err: err}

 func populate(ctx context.Context, loader registry.Load, graphLoader registry.Gr 				if err != nil { 					return err 				}-				cleanups := make(chan func(), 1)-				errs := make(chan error, 1)+				type unpackedImage struct {+					to      image.Reference+					from    string+					cleanup func()+					err     error+				}+				unpacked := make(chan unpackedImage) 				for bundle := range bundles {-					if _, ok := overwriteImageMap[img.Bundle.Package]; !ok {-						overwriteImageMap[img.Bundle.Package] = make(map[image.Reference]string, 0)-					} 					// parallelize image pulls 					go func(bundle registry.BundleKey, img *registry.ImageInput) { 						if bundle.CsvName != img.Bundle.Name { 							to, from, cleanup, err := unpackImage(ctx, reg, image.SimpleReference(bundle.BundlePath))-							if err != nil {-								errs <- err-							}-							cleanups <- cleanup-							overwriteImageMap[img.Bundle.Package][to] = from+							unpacked <- unpackedImage{to: to, from: from, cleanup: cleanup, err: err} 						} else {-							overwriteImageMap[img.Bundle.Package][to] = from+							unpacked <- unpackedImage{to: to, from: from, cleanup: func() { return }, err: nil}+							// safe because this case is only hit once

 The `Upgradeable` condition might be useful when: - An operator is about to start a critical process and should not be upgraded until after the process is completed. - The operator is performing a migration of CRs that must be completed before the operator is ready to be upgraded. +#### Ready++The `Ready` "OLM Supported Condition" allows an operator to communicate its readiness to OLM. By default, OLM will move a CSV in the `Succeeded` Phase to the `Failed` phase if the deployments [Readiness Probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes) is not true.++The `Ready` condition might be useful when:++- An operator wants to change its Readiness Probe status to 'false' to communicate information to a cluster admin but does not want OLM to move the operator into the failed state.

 ----title: About-linkTitle: About+title: Build+linkTitle: Build menu:   main:     weight: 10  ---- <section class="of-masthead of-masthead--subpage">-  <h1 class="of-heading of-heading--xl">About OLM</h1>+  <h1 class="of-heading of-heading--xl">Building Operators using the Operator SDK</h1>

 func WithChannel(channel string) OperatorPredicate {  func WithPackage(pkg string) OperatorPredicate { 	return func(o *Operator) bool {+		for _, p := range o.Properties() {

 type Bundle struct { 	Package      string 	Channels     []string 	BundleImage  string-	csv          *ClusterServiceVersion+	Csv          *ClusterServiceVersion

 type Dependencies struct {  // DirectoryPopulator loads an unpacked operator bundle from a directory into the database. type DirectoryPopulator struct {-	loader      Load-	graphLoader GraphLoader-	querier     Query-	imageDirMap map[image.Reference]string+	loader          Load+	graphLoader     GraphLoader+	querier         Query+	imageDirMap     map[image.Reference]string+	overwriteDirMap map[string]map[image.Reference]string+	overwrite       bool } -func NewDirectoryPopulator(loader Load, graphLoader GraphLoader, querier Query, imageDirMap map[image.Reference]string) *DirectoryPopulator {+func NewDirectoryPopulator(loader Load, graphLoader GraphLoader, querier Query, imageDirMap map[image.Reference]string, overwriteDirMap map[string]map[image.Reference]string, overwrite bool) *DirectoryPopulator { 	return &DirectoryPopulator{-		loader:      loader,-		graphLoader: graphLoader,-		querier:     querier,-		imageDirMap: imageDirMap,+		loader:          loader,+		graphLoader:     graphLoader,+		querier:         querier,+		imageDirMap:     imageDirMap,+		overwriteDirMap: overwriteDirMap,

 func (i *DirectoryPopulator) loadManifests(imagesToAdd []*ImageInput, mode Mode) 		// same package linearly. 		var err error 		var validImagesToAdd []*ImageInput++		for pkg := range i.overwriteDirMap {+			err := i.loader.RemovePackage(pkg)

 type Bundle struct { 	Package      string 	Channels     []string 	BundleImage  string-	csv          *ClusterServiceVersion+	Csv          *ClusterServiceVersion

 type ImageInput struct { 	metadataDir      string 	to               image.Reference 	from             string-	annotationsFile  *AnnotationsFile+	AnnotationsFile  *AnnotationsFile

 With the new installPlan in the approve state, the `my-operator.v0.2.0` CSV will ## How do I know when an update is available for an operator  It is possible to identify when there is a newer version of an operator available by inspecting the status of the operator's subscription. The value associated with the `currentCSV` field is the newest version that is known to OLM, and `installedCSV` is the version that is installed on the cluster.+To receive newer versions of an operator in a Catalog that has been updated to include the new versions, please see [Receiving updates to your installed operator](/docs/advanced-tasks/updating-an-operator) 

+---+title: "Dependency Resolution"+linkTitle: "Dependency Resolution"+date: 2020-09-18+weight: 12+---++Much like system or language package managers, OLM can resolve dependencies to fulfill an operator's runtime requirements. ++A typical example is an operator that requires the use of some other Operator's APIs:++{{<mermaid>}}+graph TD;+    e(FooOperator) --> |Provides|ec(Kind: Foo<br/>apiVerson: foogroup.io/foo/v1alpha1);+    v(BarOperator)--> |Provides|vs(Kind: Bar<br/>apiVersion: bargroup.io/bar/v1alpha1);+    v--> |Requires|ec;+    +    classDef foo fill:#8addf2,stroke:#333,stroke-width:4px;+    classDef bar fill:#ffcc26,stroke:#333,stroke-width:4px;+    classDef baz fill:#ff7452,stroke:#333,stroke-width:4px;++    class e,ec foo;+    class v,vs bar;+    +    linkStyle default fill:none,stroke-width:2px;+{{</mermaid>}}++Installing `BarOperator` with OLM will automatically install `FooOperator` as well - assuming there are no other conflicts. ++This is made possible with two types of data:++ - **Properties** - typed metadata about the operator that constutes the public interface for it in the dependency resolver. Examples include the GVKs of the APIs provided by the operator and the SemVer version of the operator+ - **Constraints** or **Dependencies** - an operator's requirements that should be satisfied by other operators (that may or may not have already been installed) or the target cluster. These act as queries / filters over all available operators and constrain the selection when resolving or installing. Examples include requiring a specific API to be available on the cluster, or expecting a particular operator with a particular version to be installed.+++Under the hood, these properties and constraints are converted into a system of boolean formulas and handed to a [SAT-solver](https://en.wikipedia.org/wiki/Boolean_satisfiability_problem), which does the heavy lifting of determining what operators should be installed.++## Declaring Properties++Properties cannot be directly declared by an operator author. Instead, they are derived from the existing metadata provided in the CSV.++All operators in a catalog will have these properties:++ - `olm.package` - includes the name of the package and the version of the operator+ - `olm.gvk` - one property is present for each "provided" API from the ClusterServiceVersion.++A future release of OLM will support explicit property creation.++## Declaring Dependencies++Dependencies are declared by including a `dependencies.yaml` file in the `metadata` directory of the operator bundle. For more information on bundles and the their format, see the [bundle docs](https://github.com/operator-framework/operator-registry/blob/master/docs/design/operator-bundle.md).++Currently, only two types of constraints are supported:++ - `olm.gvk` - declare a requirement on an API+ - `olm.package` - declare a requirement on a specific package / version range+++Here's an example of a `dependencies.yaml`:++```yaml+dependencies:+- type: olm.package+  value:+    packageName: prometheus+    version: ">0.27.0"+- type: olm.gvk+  value:+    group: etcd.database.coreos.com+    kind: EtcdCluster+    version: v1beta2+```++***Note***: The `version` field above follows the [SemVer 2.0 Spec](https://semver.org/) for version ranges, and specifically uses [blang/semver](https://github.com/blang/semver) to parse.++The resolver sees these constraints as (assuming this is for `FooOperator v1.0.0`):++ - If `FooOperator v1.0.0` is picked, there must also be a an operator picked that provides `EtcdCluster`.+ - If `FooOperator v1.0.0` is picked, there must also be a an operator picked from `prometheus` package with version `>0.27.0`.++This looks (and is) straightforward, but it's worth looking at how this is handled at runtime in [Understanding Preferences](#Understanding-Preferences).++## Understanding Preferences++Often, there will be many options that equally satisfy a dependency. The dependency resolver will make choices about which one best fits the requirements of the requested operators - but as an operator author or a user, it can be important to understand how choices are made so that dependency resolution is unsurprising.++### Catalog Priority ++On cluster, OLM reads `CatalogSource`s to know what operators are available for installation. +++```yaml+apiVersion: "operators.coreos.com/v1alpha1"+kind: "CatalogSource"+metadata:+  name: "my-operators"+  namespace: "operators"+spec:+  sourceType: grpc+  image: example.com/my/operator-index:v1+  displayName: "My Operators"+  priority: 100+```++`CatalogSource` has a `priority` field, which is used by the resolver to know how to prefer options for a dependency. ++There are two rules that govern catalog preference:++ - Options in higher-priority catalogs are preferred to options in lower-priority catalogs+ - Options in the same catalog as the depender are preferred to any other catalogs.++#### Example - Same catalog preferred to all others++{{<mermaid>}}+graph TD+    subgraph Catalog A - Priority 0+    e(FooOperator<br /><br />Provides: Foo) +    v(BarOperator<br /><br />Provides: Bar<br />Requires: Foo)+    end+    +    subgraph Catalog B - Priority 50+        e2(FooOperatorAlt<br /><br />Provides: Foo) +    end+    +    classDef foo fill:#8addf2,stroke:#333,stroke-width:4px;+    classDef fooSelected fill:#8addf2,stroke:green,stroke-width:4px;+    classDef bar fill:#ffcc26,stroke:#333,stroke-width:4px;+    classDef baz fill:#ff7452,stroke:#333,stroke-width:4px;++    class e fooSelected;+    class e2 foo;+    class v,vs bar;+    +    linkStyle default fill:none,stroke-width:2px;+{{</mermaid>}}++Installing `BarOperator` will install `FooOperator`, not `FooOperatorAlt`, even though `FooOperatorAlt` is in a catalog with higher priority++#### Example - Higher priority is preferred+++{{<mermaid>}}+graph TD+    subgraph Catalog A - Priority 0+      v(BarOperator<br /><br />Provides: Bar<br />Requires: Foo)+    end+    +    subgraph Catalog B - Priority 50+        e2(FooOperator<br /><br />Provides: Foo) +    end+    +    subgraph Catalog C - Priority 100+        e3(FooOperatorAlt<br /><br />Provides: Foo) +    end+    +    classDef foo fill:#8addf2,stroke:#333,stroke-width:4px;+    classDef fooSelected fill:#8addf2,stroke:green,stroke-width:4px;+    classDef bar fill:#ffcc26,stroke:#333,stroke-width:4px;+    classDef baz fill:#ff7452,stroke:#333,stroke-width:4px;++    class e3 fooSelected;+    class e2 foo;+    class v,vs bar;+    +    linkStyle default fill:none,stroke-width:2px;+{{</mermaid>}}++Installing `BarOperator` will install `FooOperatorAlt`, not `FooOperator`.++### Channel Ordering++An operator package in a catalog is a collection of update channels that a user can subscribe to in a cluster. Channels may be used to provide a particular stream of updates for a minor release (i.e. `1.2`, `1.3`) or a simple release frequency (`stable`, `fast`).++It is likely that a dependency may be satisfied by operators in the same package, but different channels. For example, `version 1.2` of an operator may exist in both `stable` and `fast`.++Each package has a default channel, which is always preferred to non-default channels. If no option in the default channel can satisfy a dependency, options are considered from the remaining channels in lexicographic order of the channel name. ++A future release of OLM will allow customizing the sort preference for channels.++### Ordering within a Channel++There are almost always multiple options to satisfy a dependency within a single channel - most operators in one package and channel provide the same set of APIs, for example.++When a user creates a subscription, they indicate which channel to recieve updates from - this immediately reduces the search to just that one channel. But within the channel, it is likely that many operators satsify a dependency.++Within a channel, "newer" operators are preferred - that is, operators that are higher up in the update graph. If the head of a channel satisfies a dependency, it will be tried first.++### Other Constraints++In addition to the constraints supplied by package dependencies, OLM adds a couple of extra constraints to represent the desired user state and enforce resolution invariants.++#### Subscription constraint++Subscriptions are user-supplied constraints for the resolver. They declare the intent to either install a new operator if it is not already on the cluster, or to keep an existing operator updated.++Much in the same way a dependency constraint filters the set of operators that can be installed to satisfy a dependency, a subscription constraint filters the set of operators that can satisfy a subscription.++##### Example - New Operator++In this example, all operators highlighted in green are options to satisfy the subscription constraint, because no operator has yet been installed.++{{<mermaid>}}+graph TD+   +    subgraph Cluster+      s(Subscription<br /><br />package: foo<br />channel: stable)+    end+    +    subgraph Catalog+        stable(package: foo<br />channel: stable) --> e2+        e2(FooOperator v1.2.3) +        e3(FooOperator v1.2.2) +        e4(FooOperator v1.2.1) +        e5(FooOperator v1.2.0) +        e6(FooOperator v1.1.0) +        e2 --> e3+        e3 --> e4+        e3 --> e5+        e4 --> e5+        e5 --> e6+    end+    +    classDef foo fill:#8addf2,stroke:#333,stroke-width:4px;+    classDef fooSelected fill:#8addf2,stroke:green,stroke-width:4px;+    classDef bar fill:#ffcc26,stroke:#333,stroke-width:4px;+    classDef baz fill:#ff7452,stroke:#333,stroke-width:4px;++    class s foo;+    class e2,e3,e4,e5,e6 fooSelected;+    class e2 foo;+    class v,vs bar;+    +    linkStyle default fill:none,stroke-width:2px;+{{</mermaid>}}++##### Example - Operator Updates++In this example, only operators that can update from the currently installed operator are options for the subscription constraint. ++{{<mermaid>}}+graph TD+   +    subgraph Cluster+      s(Subscription<br /><br />package: foo<br />channel: stable)+      o(ClusterServiceVersion<br /><br />FooOperator v1.2.0)+    end+    +    subgraph Catalog+        stable(package: foo<br />channel: stable) --> e2+        e2(FooOperator v1.2.3) +        e3(FooOperator v1.2.2) +        e4(FooOperator v1.2.1) +        e5(FooOperator v1.2.0) +        e6(FooOperator v1.1.0) +        e2 --> e3+        e3 --> e4+        e3 --> e5+        e4 --> e5+        e5 --> e6+    end+    +    classDef foo fill:#8addf2,stroke:#333,stroke-width:4px;+    classDef fooSelected fill:#8addf2,stroke:green,stroke-width:4px;+    classDef bar fill:#ffcc26,stroke:#333,stroke-width:4px;+    classDef baz fill:#ff7452,stroke:#333,stroke-width:4px;++    class s,o foo;+    class e3,e4 fooSelected;+    class v,vs bar;+    +    linkStyle default fill:none,stroke-width:2px;+{{</mermaid>}}++Like dependencies, subscription constraints have preference as well. OLM will choose the newest (closest to the head of the channel) operator that satisfies the subscription constraint. In this example, `FooOperator v1.2.2` would be chosen first.++#### Package constraint++Within a namespace, no two operators may come from the same package.+++#### Operator Minimization++In the case that there is more than one valid solution, the solution that installs the fewest operators is preferred.++## Best Practices++### Depend on APIs++Operators may add or remove apis at any time - always specify an `olm.gvk` dependency on any APIs your operator requires.++### Set a minimum version++The kubernetes [documentation on api changes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#readme) describes what changes are allowed for kube-style operator APIs. These versioning conventions allow an operator to update an API without bumping the `apiVersion`, as long as the api is backwards-compatible.++For operator dependencies, this means that knowing the `apiVersion` of a dependency may not be enough to ensure the dependent operator works as intended. ++For example:++ - `FooOperator v1.0` provides `v1alpha1` of `Foo`+ - `FooOperator v1.0.1` adds a new field `spec.bar` to `Foo`, but still at `v1alpha1`++Your operator may require the ability to write `spec.bar` into `Foo`. An `olm.gvk` constraint alone is not enough for OLM to determine that you need `FooOperator v1.0.1` and not `FooOperator v1.0`.++Whenever possible, if a specific operator that provides an API is known ahead of time, specify an additional `olm.package` constraint to set a minimum.++### Omit a maximum version, or allow a very wide range++Because operators provide cluster-scoped resources (ApiServices, CRDs), an operator that specifies a small window for a dependency may unnecessarily constrain updates for other consumers of that dependency.++A maximum version should not be set whenever possible, or should be set to a very wide semantic range (i.e. `>1.0.0 <2.0.0`) to prevent conflicts with other operators.++Unlike with conventional package managers, operator authors explicitly encode that updates are safe via OLM's channels. If an update is available for an existing subscription, it comes with the operator provider's promise that it can update from the previous version. Setting a maximum version for a dependency overrides the dependency author's update stream by unnecessarily truncating it at a particular upper bound.++Maximum versions can and should be set, however, if there are known incompatibilties that must be avoided. Note that specific versions can be omitted with the version range syntax, e.g. `> 1.0.0 !1.2.1` ++## Caveats++These are some things to be cautious of when specifying dependencies.++### No compound constraints ("AND")++There is not a way to specify an "AND" relationship between constraints. In other words, there is no way to say: "this operator depends on another operator that both provides `Foo` api and has version `>1.1.0`".

+package internal++import (+	"encoding/json"+	"github.com/operator-framework/api/pkg/validation/errors"+	interfaces "github.com/operator-framework/api/pkg/validation/interfaces"++	policyv1beta1 "k8s.io/api/policy/v1beta1"+	rbacv1 "k8s.io/api/rbac/v1"+	schedulingv1 "k8s.io/api/scheduling/v1"+	"k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"+)++var ObjectValidator interfaces.Validator = interfaces.ValidatorFunc(validateObjects)++const (+	PodDisruptionBudgetKind     = "PodDisruptionBudget"+	PriorityClassKind           = "PriorityClass"+	RoleKind                    = "Role"+	ClusterRoleKind             = "ClusterRole"+	PodDisruptionBudgetAPIGroup = "policy"+	SCCAPIGroup                 = "security.openshift.io"+)++var defaultSCCs = map[string]struct{}{+	"privileged":       {},+	"restricted":       {},+	"anyuid":           {},+	"hostaccess":       {},+	"hostmount-anyuid": {},+	"hostnetwork":      {},+	"node-exporter":    {},+	"nonroot":          {},+}++func validateObjects(objs ...interface{}) (results []errors.ManifestResult) {+	for _, obj := range objs {+		switch u := obj.(type) {+		case *unstructured.Unstructured:+			switch u.GroupVersionKind().Kind {+			case PodDisruptionBudgetKind:+				results = append(results, validatePDB(u))+			case PriorityClassKind:+				results = append(results, validatePriorityClass(u))+			case RoleKind:+				results = append(results, validateRBAC(u))+			case ClusterRoleKind:+				results = append(results, validateRBAC(u))+			}+		}+	}+	return results+}++// validatePDB checks the PDB to ensure the minimum and maximum budgets are set to reasonable levels.+// See https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-pod-disruption-budgets.md#limitations-on-pod-disruption-budgets+func validatePDB(u *unstructured.Unstructured) (result errors.ManifestResult) {+	pdb := policyv1beta1.PodDisruptionBudget{}++	b, err := u.MarshalJSON()+	if err != nil {+		result.Add(errors.ErrInvalidParse("error converting unstructured", err))+		return+	}++	err = json.Unmarshal(b, &pdb)+	if err != nil {+		result.Add(errors.ErrInvalidParse("error unmarshaling poddisruptionbudget", err))+		return+	}++	/*+	   maxUnavailable field cannot be set to 0 or 0%.+	   minAvailable field cannot be set to 100%.+	*/++	maxUnavailable := pdb.Spec.MaxUnavailable+	if maxUnavailable != nil {+		if maxUnavailable.IntVal == 0 || maxUnavailable.StrVal == "0%" {+			result.Add(errors.ErrInvalidObject(pdb, "maxUnavailable field cannot be set to 0 or 0%"))+		}+	}++	minAvailable := pdb.Spec.MinAvailable+	if minAvailable != nil {+		if minAvailable.StrVal == "100%" {+			result.Add(errors.ErrInvalidObject(pdb, "minAvailable field cannot be set to 100%"))+		}+	}