Downstream Sync 04.13

go.mod

@@ -12,7 +12,7 @@ require (
 	github.com/mikefarah/yq/v3 v3.0.0-20201202084205-8846255d1c37
 	github.com/onsi/ginkgo v1.16.5
 	github.com/openshift/api v0.0.0-20200331152225-585af27e34fd
-	github.com/operator-framework/api v0.12.0
+	github.com/operator-framework/api v0.14.1-0.20220413143725-33310d6154f3
 	github.com/operator-framework/operator-lifecycle-manager v0.0.0-00010101000000-000000000000
 	github.com/operator-framework/operator-registry v1.17.5
 	github.com/sirupsen/logrus v1.8.1

manifests/0000_50_olm_00-operatorgroups.crd.yaml

@@ -39,6 +39,8 @@ spec:
             spec:
               description: OperatorGroupSpec is the spec for an OperatorGroup resource.
               type: object
+              default:
+                upgradeStrategy: Default
               properties:
                 selector:
                   description: Selector selects the OperatorGroup's target namespaces.
@@ -82,6 +84,13 @@ spec:
                   items:
                     type: string
                   x-kubernetes-list-type: set
+                upgradeStrategy:
+                  description: "UpgradeStrategy defines the upgrade strategy for operators in the namespace. There are currently two supported upgrade strategies: \n Default: OLM will only allow clusterServiceVersions to move to the replacing phase from the succeeded phase. This effectively means that OLM will not allow operators to move to the next version if an installation or upgrade has failed. \n TechPreviewUnsafeFailForward: OLM will allow clusterServiceVersions to move to the replacing phase from the succeeded phase or from the failed phase. Additionally, OLM will generate new installPlans when a subscription references a failed installPlan and the catalog has been updated with a new upgrade for the existing set of operators. \n WARNING: The TechPreviewUnsafeFailForward upgrade strategy is unsafe and may result in unexpected behavior or unrecoverable data loss unless you have deep understanding of the set of operators being managed in the namespace."
+                  type: string
+                  default: Default
+                  enum:
+                    - Default
+                    - TechPreviewUnsafeFailForward
             status:
               description: OperatorGroupStatus is the status for an OperatorGroupResource.
               type: object

staging/api/crds/operators.coreos.com_operatorgroups.yaml

@@ -37,6 +37,8 @@ spec:
             spec:
               description: OperatorGroupSpec is the spec for an OperatorGroup resource.
               type: object
+              default:
+                upgradeStrategy: Default
               properties:
                 selector:
                   description: Selector selects the OperatorGroup's target namespaces.
@@ -80,6 +82,13 @@ spec:
                   items:
                     type: string
                   x-kubernetes-list-type: set
+                upgradeStrategy:
+                  description: "UpgradeStrategy defines the upgrade strategy for operators in the namespace. There are currently two supported upgrade strategies: \n Default: OLM will only allow clusterServiceVersions to move to the replacing phase from the succeeded phase. This effectively means that OLM will not allow operators to move to the next version if an installation or upgrade has failed. \n TechPreviewUnsafeFailForward: OLM will allow clusterServiceVersions to move to the replacing phase from the succeeded phase or from the failed phase. Additionally, OLM will generate new installPlans when a subscription references a failed installPlan and the catalog has been updated with a new upgrade for the existing set of operators. \n WARNING: The TechPreviewUnsafeFailForward upgrade strategy is unsafe and may result in unexpected behavior or unrecoverable data loss unless you have deep understanding of the set of operators being managed in the namespace."
+                  type: string
+                  default: Default
+                  enum:
+                    - Default
+                    - TechPreviewUnsafeFailForward
             status:
               description: OperatorGroupStatus is the status for an OperatorGroupResource.
               type: object

staging/api/pkg/operators/v1/operatorgroup_test.go

@@ -0,0 +1,70 @@
+package v1
+
+import (
+	"testing"
+
+	"github.com/stretchr/testify/require"
+)
+
+func TestUpgradeStrategy(t *testing.T) {
+	tests := []struct {
+		description string
+		og          *OperatorGroup
+		expected    UpgradeStrategy
+	}{
+		{
+			description: "NoSpec",
+			og:          &OperatorGroup{},
+			expected:    UpgradeStrategyDefault,
+		},
+		{
+			description: "NoUpgradeStrategy",
+			og: &OperatorGroup{
+				Spec: OperatorGroupSpec{},
+			},
+			expected: UpgradeStrategyDefault,
+		},
+		{
+			description: "NoUpgradeStrategy",
+			og: &OperatorGroup{
+				Spec: OperatorGroupSpec{
+					UpgradeStrategy: "",
+				},
+			},
+			expected: UpgradeStrategyDefault,
+		},
+		{
+			description: "NonSupportedUpgradeStrategy",
+			og: &OperatorGroup{
+				Spec: OperatorGroupSpec{
+					UpgradeStrategy: "foo",
+				},
+			},
+			expected: UpgradeStrategyDefault,
+		},
+		{
+			description: "DefaultUpgradeStrategy",
+			og: &OperatorGroup{
+				Spec: OperatorGroupSpec{
+					UpgradeStrategy: "Default",
+				},
+			},
+			expected: UpgradeStrategyDefault,
+		},
+		{
+			description: "UnsafeFailForwardUpgradeStrategy",
+			og: &OperatorGroup{
+				Spec: OperatorGroupSpec{
+					UpgradeStrategy: "TechPreviewUnsafeFailForward",
+				},
+			},
+			expected: UpgradeStrategyUnsafeFailForward,
+		},
+	}
+
+	for _, tt := range tests {
+		t.Run(tt.description, func(t *testing.T) {
+			require.EqualValues(t, tt.expected, tt.og.UpgradeStrategy())
+		})
+	}
+}

staging/api/pkg/operators/v1/operatorgroup_types.go

@@ -24,8 +24,29 @@ const (
 	MutlipleOperatorGroupCondition       = "MultipleOperatorGroup"
 	MultipleOperatorGroupsReason         = "MultipleOperatorGroupsFound"
 	OperatorGroupServiceAccountReason    = "ServiceAccountNotFound"
+
+	// UpgradeStrategyDefault configures OLM such that it will only allow
+	// clusterServiceVersions to move to the replacing phase to the succeeded
+	// phase. This effectively means that OLM will not allow operators to move
+	// to the next version if an installation or upgrade has failed.
+	UpgradeStrategyDefault UpgradeStrategy = "Default"
+
+	// UpgradeStrategyUnsafeFailForward configures OLM such that it  will allow
+	// clusterServiceVersions to move to the  replacing phase from the succeeded
+	// phase or from the failed phase. Additionally, OLM will generate new
+	// installPlans when a subscription references a failed installPlan and the
+	// catalog has been updated with a new upgrade for the existing set of
+	// operators.
+	//
+	// WARNING: The UpgradeStrategyUnsafeFailForward upgrade strategy is unsafe
+	// and may result in unexpected behavior or unrecoverable data loss unless
+	// you have deep understanding of the set of operators being managed in the
+	// namespace.
+	UpgradeStrategyUnsafeFailForward UpgradeStrategy = "TechPreviewUnsafeFailForward"
 )
 
+type UpgradeStrategy string
+
 // OperatorGroupSpec is the spec for an OperatorGroup resource.
 type OperatorGroupSpec struct {
 	// Selector selects the OperatorGroup's target namespaces.
@@ -45,6 +66,29 @@ type OperatorGroupSpec struct {
 	// Static tells OLM not to update the OperatorGroup's providedAPIs annotation
 	// +optional
 	StaticProvidedAPIs bool `json:"staticProvidedAPIs,omitempty"`
+
+	// UpgradeStrategy defines the upgrade strategy for operators in the namespace.
+	// There are currently two supported upgrade strategies:
+	//
+	// Default: OLM will only allow clusterServiceVersions to move to the replacing
+	// phase from the succeeded phase. This effectively means that OLM will not
+	// allow operators to move to the next version if an installation or upgrade
+	// has failed.
+	//
+	// TechPreviewUnsafeFailForward: OLM will allow clusterServiceVersions to move to the
+	// replacing phase from the succeeded phase or from the failed phase.
+	// Additionally, OLM will generate new installPlans when a subscription references
+	// a failed installPlan and the catalog has been updated with a new upgrade for
+	// the existing set of operators.
+	//
+	// WARNING: The TechPreviewUnsafeFailForward upgrade strategy is unsafe and may result
+	// in unexpected behavior or unrecoverable data loss unless you have deep
+	// understanding of the set of operators being managed in the namespace.
+	//
+	// +kubebuilder:validation:Enum=Default;TechPreviewUnsafeFailForward
+	// +kubebuilder:default=Default
+	// +optional
+	UpgradeStrategy UpgradeStrategy `json:"upgradeStrategy,omitempty"`
 }
 
 // OperatorGroupStatus is the status for an OperatorGroupResource.
@@ -76,6 +120,7 @@ type OperatorGroup struct {
 	metav1.ObjectMeta `json:"metadata"`
 
 	// +optional
+	// +kubebuilder:default={upgradeStrategy:Default}
 	Spec   OperatorGroupSpec   `json:"spec"`
 	Status OperatorGroupStatus `json:"status,omitempty"`
 }
@@ -98,6 +143,17 @@ func (o *OperatorGroup) BuildTargetNamespaces() string {
 	return strings.Join(ns, ",")
 }
 
+// UpgradeStrategy returns the UpgradeStrategy specified or the default value otherwise.
+func (o *OperatorGroup) UpgradeStrategy() UpgradeStrategy {
+	strategyName := o.Spec.UpgradeStrategy
+	switch {
+	case strategyName == UpgradeStrategyUnsafeFailForward:
+		return strategyName
+	default:
+		return UpgradeStrategyDefault
+	}
+}
+
 // IsServiceAccountSpecified returns true if the spec has a service account name specified.
 func (o *OperatorGroup) IsServiceAccountSpecified() bool {
 	if o.Spec.ServiceAccountName == "" {

staging/operator-lifecycle-manager/CONTRIBUTING.md

@@ -31,8 +31,8 @@ This is a rough outline of what a contributor's workflow looks like:
 - Identify or create an issue.
 - Create a topic branch from where to base the contribution. This is usually the master branch.
 - Make commits of logical units.
-- Make sure commit messages are in the proper format (see below).
-- Ensure all relevant commit messages contain a valid sign-off message (see below).
+- Make sure commit messages are in the proper format ([see below][commit-messages]).
+- Ensure all relevant commit messages contain a valid sign-off message ([see below][commit-messages]).
 - Push changes in a topic branch to a personal fork of the repository.
 - Submit a pull request to the operator-framework/operator-lifecycle-manager repository.
 - Wait and respond to feedback from the maintainers listed in the OWNERS file.
@@ -47,7 +47,7 @@ It can be helpful after submitting a PR to self-review your changes. This allows
 
 When opening PRs that are in a rough draft or WIP state, prefix the PR description with `WIP: ...` or create a draft PR. This can help save reviewer's time by communicating the state of a PR ahead of time. Draft/WIP PRs can be a good way to get early feedback from reviewers on the implementation, focusing less on smaller details, and more on the general approach of changes.
 
-When contributing changes that require a new dependency, check whether it's feasable to directly vendor that code [without introducing a new dependency](https://go-proverbs.github.io/).
+When contributing changes that require a new dependency, check whether it's feasible to directly vendor that code [without introducing a new dependency](https://go-proverbs.github.io/).
 
 Each PR must be labeled with at least one "lgtm" label and at least one "approved" label before it can be merged. Maintainers that have approval permissions are listed in the "approvers" column in the root [OWNERS][owners] file.
 
@@ -62,19 +62,19 @@ In addition to the linked style documentation, OLM formats Golang packages using
 
 Please follow this style to make the OLM project easier to review, maintain and develop.
 
-### Sign-off ([DCO][DCO])
+### Commit Messages and Sign-off ([DCO][DCO])
 
 A [sign-off][sign-off] is a line towards the end of a commit message that certifies the commit author(s).
 
-For more information on the structuring of commit messages, read the information in the [DCO](https://github.com/apps/dco) application that the OLM projects uses.
+For more information on the structuring of commit messages, read the information in the [DCO][dco] application that the OLM projects uses.
 
 ## Documentation
 
 If the contribution changes the existing APIs or user interface it must include sufficient documentation to explain the use of the new or updated feature.
 
 The OLM documentation mainly lives in the [operator-framework/olm-docs][olm-docs] repository.
 
-[operator_framework]: https://groups.google.com/forum/#!forum/operator-framework
+[operator_framework]: <https://groups.google.com/forum/#!forum/operator-framework>
 [dco]: <https://developercertificate.org/>
 [owners]: <https://github.com/operator-framework/operator-lifecycle-manager/blob/master/OWNERS>
 [issues]: <https://github.com/operator-framework/operator-lifecycle-manager/issues>
@@ -84,3 +84,4 @@ The OLM documentation mainly lives in the [operator-framework/olm-docs][olm-docs
 [sign-off]: <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff>
 [goimports]: <https://pkg.go.dev/golang.org/x/tools/cmd/goimports>
 [gofmt]: <https://pkg.go.dev/cmd/gofmt>
+[commit-messages]: <https://github.com/operator-framework/operator-lifecycle-manager/blob/master/CONTRIBUTING.md#commit-messages-and-sign-off-dco>

staging/operator-lifecycle-manager/README.md

@@ -10,9 +10,10 @@
 
 User documentation can be found on the [OLM website][olm-docs].
 
+
 ## Overview
 
-This project is a component of the [Operator Framework](https://github.com/operator-framework), an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the [introduction blog post](https://operatorhub.io/what-is-an-operator) and learn about practical use cases at [OLM-Book](https://operator-framework.github.io/olm-book/).
+This project is a component of the [Operator Framework](https://github.com/operator-framework), an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the [introduction blog post](https://operatorhub.io/what-is-an-operator) and learn about practical use cases at the [OLM website][olm-docs].
 
 OLM extends Kubernetes to provide a declarative way to install, manage, and upgrade Operators and their dependencies in a cluster. It provides the following features:
 
@@ -47,13 +48,13 @@ Operators can behave like managed service providers. Their user interface on the
 
 ## Getting Started
 
-Check the [Getting Started][olm-getting-started] section.
+Check out the [Getting Started][olm-getting-started] section in the docs.
 
 ### Installation
 
 Install OLM on a Kubernetes cluster by following the [installation guide][installation-guide].
 
-For a complete end-to-end example of how OLM fits into the Operator Framework, see the [Operator Framework Getting Started Guide](https://github.com/operator-framework/getting-started). Also, see [Getting Started on OperatorHub.io](https://operatorhub.io/getting-started).
+For a complete end-to-end example of how OLM fits into the Operator Framework, see the [Operator Framework website](https://operatorframework.io/about/) and the [Getting Started guide on OperatorHub.io](https://operatorhub.io/getting-started).
 
 ## User Interface (Running the console Locally)
 
@@ -96,13 +97,14 @@ Learn more about the components used by OLM by reading about the [architecture]
 
 OLM standardizes interactions with operators by requiring that the interface to an operator be via the Kubernetes API. Because we expect users to define the interfaces to their applications, OLM currently uses CRDs to define the Kubernetes API interactions.
 
-Examples: [EtcdCluster CRD](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/0.9.4/etcdclusters.etcd.database.coreos.com.crd.yaml), [EtcdBackup CRD](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/0.9.4/etcdbackups.etcd.database.coreos.com.crd.yaml)
+Examples: [EtcdCluster CRD](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/0.9.4/etcdclusters.etcd.database.coreos.com.crd.yaml), 
+[EtcdBackup CRD](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/0.9.4/etcdbackups.etcd.database.coreos.com.crd.yaml)
 
 ## Descriptors
 
 OLM introduces the notion of “descriptors” of both `spec` and `status` fields in kubernetes API responses. Descriptors are intended to indicate various properties of a field in order to make decisions about their content. For example, this can drive connecting two operators together (e.g. connecting the connection string from a mysql instance to a consuming application) and be used to drive rich interactions in a UI.
 
-[See an example of a ClusterServiceVersion with descriptors](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/0.9.2/etcdoperator.v0.9.2.clusterserviceversion.yaml)
+[See an example of a ClusterServiceVersion with descriptors](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/0.9.2/etcdoperator.v0.9.2.clusterserviceversion.yaml)
 
 ## Dependency Resolution
 
@@ -129,7 +131,7 @@ OLM has the concept of catalogs, which are repositories of application definitio
 
 Catalogs contain a set of Packages, which map “channels” to a particular application definition. Channels allow package authors to write different upgrade paths for different users (e.g. alpha vs. stable).
 
-Example: [etcd package](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/etcd.package.yaml)
+Example: [etcd package](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/etcd.package.yaml)
 
 Users can subscribe to channels and have their operators automatically updated when new versions are released.
 
@@ -154,7 +156,7 @@ Catalogs are served internally over a grpc interface to OLM from [operator-regis
 
 ## Samples
 
-To explore any operator samples using the OLM, see the [https://operatorhub.io/](https://operatorhub.io/) and its resources in [Community Operators](https://github.com/operator-framework/community-operators/tree/master/upstream-community-operators).
+To explore any operator samples using the OLM, see the [https://operatorhub.io/](https://operatorhub.io/) and its resources in [Community Operators](https://github.com/k8s-operatorhub/community-operators/tree/main/operators).
 
 ## Community and how to get involved
 
@@ -194,6 +196,6 @@ Operator Lifecycle Manager is under Apache 2.0 license. See the [LICENSE][licens
 [operator-framework-community]: https://github.com/operator-framework/community
 [operator-framework-communication]: https://github.com/operator-framework/community#get-involved
 [operator-framework-meetings]: https://github.com/operator-framework/community#meetings
-[contributor-documentation]: https://olm.operatorframework.io/docs/contribution-guidelines/
+[contributor-documentation]: ./CONTRIBUTING.md
 [olm-getting-started]: https://olm.operatorframework.io/docs/getting-started/
 [installation-guide]: doc/install/install.md