profile
viewpoint
Evan Cordell ecordell Red Hat New York

aquasecurity/manifesto 163

Use Manifesto to store and query metadata for container images.

coreos/grafiti 34

Tag and remove AWS Resources with Automation

ecordell/chaostools 4

Educational software for the investigation of chaos.

cavalryjim/yeartogo 1

StartupBus Miami Project

coreos-inc/apostille 1

Quay's Image Signing Service

ecordell/ActionSheetPicker 1

Quickly reproduce the dropdown UIPickerView / ActionSheet functionality from Safari on iPhone/ iOS / CocoaTouch.

ecordell/aws-sdk-for-ios 1

Official mirror of the AWS SDK for iOS. For more information on the AWS SDK for iOS, see our web site:

ecordell/chargify_api_ares 1

A Chargify API wrapper for Ruby using ActiveResource

dinhxuanvu/operator-lifecycle-manager 0

A management framework for extending Kubernetes with Operators

push eventoperator-framework/operator-registry

Evan Cordell

commit sha 1c3ef5613f7d3c49defaa9d9886d38ec1f9cf5ad

Update upstream-builder.Dockerfile

view details

push time in 5 hours

PR opened operator-framework/operator-registry

set group permissions on /tmp

<!--

Before making a PR, please read our contributing guidelines https://github.com/operator-framework/operator-lifecycle-manager/blob/master/CONTRIBUTING.md Note: Make sure your branch is rebased to the latest upstream master.

-->

Description of the change:

Motivation for the change:

Reviewer Checklist

  • [ ] Implementation matches the proposed design, or proposal is updated to match implementation
  • [ ] Sufficient unit test coverage
  • [ ] Sufficient end-to-end test coverage
  • [ ] Docs updated or added to /docs
  • [ ] Commit messages sensible and descriptive

<!--

Note: If this PR is fixing an issue make sure to add a note saying: Closes #<ISSUE_NUMBER>

-->

+3 -0

0 comment

1 changed file

pr created time in 5 hours

create barnchoperator-framework/operator-registry

branch : ecordell-patch-1

created branch time in 5 hours

Pull request review commentoperator-framework/operator-registry

Bug 1883905: (fix) concurrent writes during image pulls

 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}

if unpackImage were updated to return an unpackedImage, this whole goroutine could just be:

go func(bundle registry.BundleKey, img *registry.ImageInput) {
  unpacked <- unpackImage(ctx, reg, image.SimpleReference(bundle.BundlePath))
}
gallettilance

comment created time in 9 hours

PullRequestReviewEvent

Pull request review commentoperator-framework/operator-registry

Bug 1883905: (fix) concurrent writes during image pulls

 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

it's only hit once per goroutine, but it's still concurrent access to a map

gallettilance

comment created time in 10 hours

PullRequestReviewEvent

Pull request review commentoperator-framework/enhancements

Update Operator-Status enhancement

 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.

What OLM behavior changes if Ready=true vs. Ready=false?

I understood "supported conditions" to be things that would affect OLM behavior (i.e. Upgradeable=false prevents upgrade)

That's not to say an author couldn't write a Ready status. But it's more likely useful for the operator to communicate more detailed status via its own CRs (i.e. connection state to cloud accounts).

awgreene

comment created time in 11 hours

PullRequestReviewEvent

pull request commentoperator-framework/enhancements

Add "Upgrading" status to the condition CR

checks the readiness probe to find out if the upgrade is done.

The conditions described in #42 are designed to replace the readiness probe check. Operators using that feature will not be upgraded based on their readiness probe status

nunnatsa

comment created time in 12 hours

PullRequestReviewEvent

Pull request review commentoperator-framework/olm-docs

Update site to improve navigation

 ----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>

is this intentional? converting the copy over to sdk?

anik120

comment created time in a day

PullRequestReviewEvent
PullRequestEvent

pull request commentoperator-framework/operator-registry

Bug 1883560: Clean up /tmp/directory in the operator-registry image

/hold

this will break mac and windows builds

akram

comment created time in a day

pull request commentoperator-framework/enhancements

Add "Upgrading" status to the condition CR

It may help to think of Upgradeable=False as Interruptible=False.

In other words, OLM does not care what the operator is actually doing (in this case, it sounds like upgrading some operands). It only cares that it should not move on to the next update for the operator, because that would interrupt some important work the current one is doing.

If an operator typically has migrations to perform, it should likely ship in the Upgradeable=False state, and only flip to true once it's had a chance to start up and check that everything is properly up to date.

Does that make sense?

nunnatsa

comment created time in a day

PR closed operator-framework/operator-registry

Reviewers
fix(dockerfile): clean out tmp directory after binaries are placed approved

<!--

Before making a PR, please read our contributing guidelines https://github.com/operator-framework/operator-lifecycle-manager/blob/master/CONTRIBUTING.md Note: Make sure your branch is rebased to the latest upstream master.

-->

Description of the change: Remove bins from /tmp after they've been moved into the correct location

Motivation for the change: The image was much larger than it needed to be.

Reviewer Checklist

  • [ ] Implementation matches the proposed design, or proposal is updated to match implementation
  • [ ] Sufficient unit test coverage
  • [ ] Sufficient end-to-end test coverage
  • [ ] Docs updated or added to /docs
  • [ ] Commit messages sensible and descriptive

<!--

Note: If this PR is fixing an issue make sure to add a note saying: Closes #<ISSUE_NUMBER>

-->

+1 -1

2 comments

1 changed file

ecordell

pr closed time in a day

pull request commentoperator-framework/operator-registry

fix(dockerfile): clean out tmp directory after binaries are placed

closing in favor of #460

ecordell

comment created time in a day

PR opened operator-framework/operator-registry

fix(dockerfile): clean out tmp directory after binaries are placed

<!--

Before making a PR, please read our contributing guidelines https://github.com/operator-framework/operator-lifecycle-manager/blob/master/CONTRIBUTING.md Note: Make sure your branch is rebased to the latest upstream master.

-->

Description of the change: Remove bins from /tmp after they've been moved into the correct location

Motivation for the change: The image was much larger than it needed to be.

Reviewer Checklist

  • [ ] Implementation matches the proposed design, or proposal is updated to match implementation
  • [ ] Sufficient unit test coverage
  • [ ] Sufficient end-to-end test coverage
  • [ ] Docs updated or added to /docs
  • [ ] Commit messages sensible and descriptive

<!--

Note: If this PR is fixing an issue make sure to add a note saying: Closes #<ISSUE_NUMBER>

-->

+1 -1

0 comment

1 changed file

pr created time in a day

create barnchecordell/operator-registry

branch : clean-tmp

created branch time in a day

pull request commentoperator-framework/enhancements

Add "Upgrading" status to the condition CR

Hi @nunnatsa -

The issue you're describing is what the enhancement intends to address.

  • Issue: How can OLM distinct between an upgrade process that was not started yet, and one that was already completed.

The way that this is addressed in the original enhancement is by setting Upgradeable=false rather than Upgrading=true.

In the example here, you would simply set:

  apiVersion: operators.coreos.com/v1
  kind: Condition
  metadata:
    name: foo-operator-zdgen-asdf 
    namespace: operators
  status:
    conditions:
    - type: "Upgradeable" # The name of the `foo` OLM Supported Condition.
      status: "False"   # The operator is now performing upgrade.
      reason: "migration"
      message: "The operator is performing a migration to version v2.3.4"
      lastTransitionTime: "2020-08-24T23:15:55Z"

This tells OLM it that should not upgrade the operator itself (upgradeable=false)n because it is currently performing an upgrade.

nunnatsa

comment created time in a day

Pull request review commentoperator-framework/operator-lifecycle-manager

Annotate CSVs with the properties used during dependency resolution.

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

Shouldn't this be in NewOperator*FromCSV?

benluddy

comment created time in 2 days

PullRequestReviewEvent

pull request commentopenshift/origin

[WIP] Adjust wait duration for marketplace test

/lgtm /approve

dinhxuanvu

comment created time in 2 days

pull request commentoperator-framework/operator-lifecycle-manager

Bug 1880359: [release-4.5] Bump 1.18.9

/refresh

ecordell

comment created time in 5 days

pull request commentoperator-framework/operator-lifecycle-manager

Bug 1880359: [release-4.5] Bump 1.18.9

/bugzilla refresh

ecordell

comment created time in 5 days

PR opened operator-framework/operator-lifecycle-manager

Bug 1880359: [release-4.5] Bump 1.18.9

<!--

Before making a PR, please read our contributing guidelines https://github.com/operator-framework/operator-lifecycle-manager/blob/master/CONTRIBUTING.md

Note: Make sure your branch is rebased to the latest upstream master.

-->

Description of the change: Cherry pick of #1775

Motivation for the change:

Reviewer Checklist

  • [ ] Implementation matches the proposed design, or proposal is updated to match implementation
  • [ ] Sufficient unit test coverage
  • [ ] Sufficient end-to-end test coverage
  • [ ] Docs updated or added to /docs
  • [ ] Commit messages sensible and descriptive

<!--

Note: If this PR is fixing an issue make sure to add a note saying: Closes #<ISSUE_NUMBER>

-->

+3262 -566

0 comment

74 changed files

pr created time in 5 days

create barnchecordell/operator-lifecycle-manager

branch : 1.18.9

created branch time in 5 days

pull request commentoperator-framework/operator-lifecycle-manager

Bug 1882077: Bump k8s dependencies to v0.18.9

/cherry-pick release-4.5

njhale

comment created time in 5 days

pull request commentopenshift/release

Bug 1874751: OKD: build marketplace package from Dockerfile.okd

/retest

vrutkovs

comment created time in 5 days

pull request commentopenshift/release

Bug 1874751: OKD: build marketplace package from Dockerfile.okd

/lgtm /approve

vrutkovs

comment created time in 5 days

pull request commentoperator-framework/olm-docs

Implement Algolia search

/lgtm

anik120

comment created time in 5 days

PullRequestReviewEvent
PullRequestReviewEvent

issue openedoperator-framework/operator-lifecycle-manager

[RRE] Support downgrade graphs

Feature Request

Is your feature request related to a problem? Please describe. If an operator gets updated to a particular version, there is no way to downgrade.

Describe the solution you'd like

A general downgrade procedure may be unsafe (how will an operator consumer know if downgrade is safe to attempt?)

But if there were a way to add downgrade edges, in a similar way to upgrade edges, an operator author could provide a supported downgrade path when they believe it to be safe.

created time in 6 days

PullRequestReviewEvent

pull request commentoperator-framework/operator-marketplace

Bug 1873546: Increase registry delay for large payloads

/cherry-pick release-4.4

kevinrizza

comment created time in 6 days

pull request commentopenshift/origin

Bug 1881060: don't wait for an OLM operator to succeed on non-amd64

/hold cancel

ecordell

comment created time in 6 days

push eventecordell/origin

Evan

commit sha d8ebfbee61845d2c939f0f4c778334a6e731694a

don't wait for an OLM operator to succeed on non-amd64 until we have a good multi-arch operator available for test

view details

push time in 6 days

pull request commentopenshift/origin

Bug 1881060: don't wait for an OLM operator to succeed on non-amd64

/hold

not sure that checking runtime arch will indicate the target cluster arch. depends on how non-amd64 arches are tested.

ecordell

comment created time in 6 days

PR opened openshift/origin

Bug 1881060: don't wait for an OLM operator to succeed on non-amd64

until we have a good multi-arch operator available for test, skip the check that waits for an operator to succeed.

+12 -4

0 comment

1 changed file

pr created time in 6 days

create barnchecordell/origin

branch : skip-olm-check-non-amd64

created branch time in 6 days

pull request commentoperator-framework/operator-registry

fix the comments of LabelDependency in the type definition

/lgtm /approve /ok-to-test

dongwenjuan

comment created time in 6 days

PR opened gallettilance/operator-registry

fix tests

<!--

Before making a PR, please read our contributing guidelines https://github.com/operator-framework/operator-lifecycle-manager/blob/master/CONTRIBUTING.md Note: Make sure your branch is rebased to the latest upstream master.

-->

Description of the change:

Motivation for the change:

Reviewer Checklist

  • [ ] Implementation matches the proposed design, or proposal is updated to match implementation
  • [ ] Sufficient unit test coverage
  • [ ] Sufficient end-to-end test coverage
  • [ ] Docs updated or added to /docs
  • [ ] Commit messages sensible and descriptive

<!--

Note: If this PR is fixing an issue make sure to add a note saying: Closes #<ISSUE_NUMBER>

-->

+1 -12

0 comment

2 changed files

pr created time in 7 days

create barnchecordell/operator-registry

branch : force-bundle-no-pull

created branch time in 7 days

Pull request review commentoperator-framework/operator-registry

Bug 1880501: Adding overwrite-latest flag to index add

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

You shouldn't need Csv.GetName - that's what Name is, which is already public

gallettilance

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentoperator-framework/operator-registry

Bug 1880501: Adding overwrite-latest flag to index add

 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,

do we need to distinguish which ones are "overwrites" up front?

gallettilance

comment created time in 8 days

Pull request review commentoperator-framework/operator-registry

Bug 1880501: Adding overwrite-latest flag to index add

 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)

I think we want the remove / add to happen in a single transaction.

It would also be nice to not need to thread through the "overwriteImages" separately everywhere. is there a way we can we push the overwrite option down to loadManifestReplaces (or call loadManifestsReplaceOverwrite if overwrite is set, etc), so that we only need to worry about overwriting when we try to insert and it fails because it already exists?

gallettilance

comment created time in 8 days

Pull request review commentoperator-framework/operator-registry

Bug 1880501: Adding overwrite-latest flag to index add

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

why did this change to public?

gallettilance

comment created time in 8 days

Pull request review commentoperator-framework/operator-registry

Bug 1880501: Adding overwrite-latest flag to index add

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

same: why did these become public?

gallettilance

comment created time in 8 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentoperator-framework/olm-docs

Implement Algolia search

Should the search work on the preview site?

anik120

comment created time in 9 days

Pull request review commentoperator-framework/olm-docs

Update doc to clarify steps to receive updates to CatalogSource

 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) 

This is still kind of weird - we have catalog polling to get updates automatically, so linking to a doc that doesn't mention that at all seems misleading.

anik120

comment created time in 9 days

PullRequestReviewEvent

pull request commentoperator-framework/olm-docs

Add docs for dependency resolution

@anik120 Address your feedback and moved to Concepts. At some point I'd like to revisit organization but that's probably the best fit for now

I hear the feedback on the "ADD" constraint - if it's okay, I'd like to merge the doc as-is and then come back with a follow up PR to think about how to better explain that / make it less surprising.

ecordell

comment created time in 9 days

push eventecordell/olm-docs

Evan

commit sha 68d82add88222590303b6566eb2affebc5b73512

add doc on dependency resolution

view details

push time in 9 days

issue commentoperator-framework/operator-lifecycle-manager

[RFE] Provide procedure for hot-fixing an operator

Have you run into issues modifying a CSV directly? Any changes made there should be synced to the deployment correctly. I believe the workflow you're looking for is already supported, but I'd like to hear if there's something you've tried that didn't work.

cdjohnson

comment created time in 9 days

push eventecordell/olm-docs

Evan

commit sha 267bac9cacd4499b07d390beb2dc87930205f37d

add doc on dependency resolution

view details

push time in 9 days

PullRequestReviewEvent

pull request commentoperator-framework/operator-registry

Add test to verify empty bundles in addition does not break

this a safe, test-only change, marking with valid-bug

shawn-hurley

comment created time in 9 days

PR closed operator-framework/operator-registry

Reviewers
chore(deps): bump to kube 1.19 approved do-not-merge/hold lgtm triage/unresolved
+31234 -7922

8 comments

450 changed files

awgreene

pr closed time in 9 days

pull request commentoperator-framework/operator-registry

chore(deps): bump to kube 1.19

This will be available for reference if we need it, but I think we'll be skipping to 1.20 in the coming weeks - closing for now.

awgreene

comment created time in 9 days

push eventecordell/olm-docs

Evan

commit sha 6c4db47742504d4a42ce44d4d8a069af3db1d99d

add doc on dependency resolution

view details

push time in 9 days

push eventecordell/olm-docs

Evan

commit sha e408d461e3a10fbd659ac7fd928e22a79f491e08

add doc on dependency resolution

view details

push time in 9 days

push eventecordell/olm-docs

Evan Cordell

commit sha 175b16f84084c55e35694569648ea3437b05fe3d

Update content/en/docs/Reference/dependency-resolution.md Co-authored-by: Haseeb Tariq <hasbro17@gmail.com>

view details

push time in 9 days

Pull request review commentoperator-framework/olm-docs

Add docs for dependency resolution

+---+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`".

It might help to have an example that pulls in two operator dependencies, so it's more clear?

ecordell

comment created time in 9 days

PullRequestReviewEvent

push eventecordell/olm-docs

Evan Cordell

commit sha 8715437fb31ce3f4a0e0d39dd85b4e499842129c

Update content/en/docs/Reference/dependency-resolution.md Co-authored-by: Haseeb Tariq <hasbro17@gmail.com>

view details

push time in 9 days

push eventecordell/olm-docs

Evan Cordell

commit sha 3f968d8032fb4c777b64aaba1e2e6e04486c4c2a

Update content/en/docs/Reference/dependency-resolution.md Co-authored-by: Haseeb Tariq <hasbro17@gmail.com>

view details

push time in 9 days

push eventecordell/olm-docs

Evan Cordell

commit sha 3db9573b50952650f72f8812b976b9a118438cf7

Update content/en/docs/Reference/dependency-resolution.md Co-authored-by: Haseeb Tariq <hasbro17@gmail.com>

view details

push time in 9 days

push eventecordell/olm-docs

Evan Cordell

commit sha 7486237cf9ae02b21a0e9e1dd10d4e3e76b36028

Update content/en/docs/Reference/dependency-resolution.md Co-authored-by: Haseeb Tariq <hasbro17@gmail.com>

view details

push time in 9 days

push eventecordell/olm-docs

Evan Cordell

commit sha 65aec40026196a8288c6ab1df4abfba8817eaf29

Update content/en/docs/Reference/dependency-resolution.md Co-authored-by: Haseeb Tariq <hasbro17@gmail.com>

view details

push time in 9 days

push eventecordell/olm-docs

Evan Cordell

commit sha 20613f14d9351780c189a06802f891394240cd35

Update content/en/docs/Reference/dependency-resolution.md Co-authored-by: Haseeb Tariq <hasbro17@gmail.com>

view details

push time in 9 days

create barnchecordell/olm-docs

branch : depresdocs

created branch time in 12 days

PullRequestReviewEvent

Pull request review commentoperator-framework/api

feat: bundle object validation

+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%"))+		}+	}
	if minAvailable != nil && minAvailable.StrVal == "100%" {
		result.Add(errors.ErrInvalidObject(pdb, "minAvailable field cannot be set to 100%"))
	}
exdx

comment created time in 12 days

pull request commentoperator-framework/operator-lifecycle-manager

BUG 1872584: Fix conversion webhooks

/approve

awgreene

comment created time in 13 days

pull request commentoperator-framework/operator-registry

Bug 1878163: Updating Dockerfile baseimages to mach ocp-build-data config

/hold cancel

thanks for confirming @sosiouxme

openshift-bot

comment created time in 13 days

pull request commentoperator-framework/operator-lifecycle-manager

Bug 1875247: Add package check for the channel head querying

I think most of this was addressed with #1735, do we want to keep this open to address error messages / etc?

jianzhangbjz

comment created time in 14 days

push eventecordell/origin

Evan

commit sha 40f9776b970e7385c75b9d5856208642422dfdb9

omit openshift-marketplace from best-effort qos check catalog pods come from outside the release payload

view details

push time in 15 days

pull request commentopenshift/origin

Bug 1857928: Re-enable olm tests

/retest

ecordell

comment created time in 15 days

more