Skip to content

Commit cd2e995

Browse files
Merge pull request #289 from perdasilva/sync_04_13
Downstream Sync 04.13
2 parents 698c231 + 3f18e09 commit cd2e995

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

51 files changed

+3146
-192
lines changed

Diff for: go.mod

+1-1
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ require (
1212
github.com/mikefarah/yq/v3 v3.0.0-20201202084205-8846255d1c37
1313
github.com/onsi/ginkgo v1.16.5
1414
github.com/openshift/api v0.0.0-20200331152225-585af27e34fd
15-
github.com/operator-framework/api v0.12.0
15+
github.com/operator-framework/api v0.14.1-0.20220413143725-33310d6154f3
1616
github.com/operator-framework/operator-lifecycle-manager v0.0.0-00010101000000-000000000000
1717
github.com/operator-framework/operator-registry v1.17.5
1818
github.com/sirupsen/logrus v1.8.1

Diff for: manifests/0000_50_olm_00-operatorgroups.crd.yaml

+9
Original file line numberDiff line numberDiff line change
@@ -39,6 +39,8 @@ spec:
3939
spec:
4040
description: OperatorGroupSpec is the spec for an OperatorGroup resource.
4141
type: object
42+
default:
43+
upgradeStrategy: Default
4244
properties:
4345
selector:
4446
description: Selector selects the OperatorGroup's target namespaces.
@@ -82,6 +84,13 @@ spec:
8284
items:
8385
type: string
8486
x-kubernetes-list-type: set
87+
upgradeStrategy:
88+
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."
89+
type: string
90+
default: Default
91+
enum:
92+
- Default
93+
- TechPreviewUnsafeFailForward
8594
status:
8695
description: OperatorGroupStatus is the status for an OperatorGroupResource.
8796
type: object

Diff for: staging/api/crds/operators.coreos.com_operatorgroups.yaml

+9
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,8 @@ spec:
3737
spec:
3838
description: OperatorGroupSpec is the spec for an OperatorGroup resource.
3939
type: object
40+
default:
41+
upgradeStrategy: Default
4042
properties:
4143
selector:
4244
description: Selector selects the OperatorGroup's target namespaces.
@@ -80,6 +82,13 @@ spec:
8082
items:
8183
type: string
8284
x-kubernetes-list-type: set
85+
upgradeStrategy:
86+
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."
87+
type: string
88+
default: Default
89+
enum:
90+
- Default
91+
- TechPreviewUnsafeFailForward
8392
status:
8493
description: OperatorGroupStatus is the status for an OperatorGroupResource.
8594
type: object

Diff for: staging/api/crds/zz_defs.go

+1-1
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

Diff for: staging/api/pkg/operators/v1/operatorgroup_test.go

+70
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
package v1
2+
3+
import (
4+
"testing"
5+
6+
"github.com/stretchr/testify/require"
7+
)
8+
9+
func TestUpgradeStrategy(t *testing.T) {
10+
tests := []struct {
11+
description string
12+
og *OperatorGroup
13+
expected UpgradeStrategy
14+
}{
15+
{
16+
description: "NoSpec",
17+
og: &OperatorGroup{},
18+
expected: UpgradeStrategyDefault,
19+
},
20+
{
21+
description: "NoUpgradeStrategy",
22+
og: &OperatorGroup{
23+
Spec: OperatorGroupSpec{},
24+
},
25+
expected: UpgradeStrategyDefault,
26+
},
27+
{
28+
description: "NoUpgradeStrategy",
29+
og: &OperatorGroup{
30+
Spec: OperatorGroupSpec{
31+
UpgradeStrategy: "",
32+
},
33+
},
34+
expected: UpgradeStrategyDefault,
35+
},
36+
{
37+
description: "NonSupportedUpgradeStrategy",
38+
og: &OperatorGroup{
39+
Spec: OperatorGroupSpec{
40+
UpgradeStrategy: "foo",
41+
},
42+
},
43+
expected: UpgradeStrategyDefault,
44+
},
45+
{
46+
description: "DefaultUpgradeStrategy",
47+
og: &OperatorGroup{
48+
Spec: OperatorGroupSpec{
49+
UpgradeStrategy: "Default",
50+
},
51+
},
52+
expected: UpgradeStrategyDefault,
53+
},
54+
{
55+
description: "UnsafeFailForwardUpgradeStrategy",
56+
og: &OperatorGroup{
57+
Spec: OperatorGroupSpec{
58+
UpgradeStrategy: "TechPreviewUnsafeFailForward",
59+
},
60+
},
61+
expected: UpgradeStrategyUnsafeFailForward,
62+
},
63+
}
64+
65+
for _, tt := range tests {
66+
t.Run(tt.description, func(t *testing.T) {
67+
require.EqualValues(t, tt.expected, tt.og.UpgradeStrategy())
68+
})
69+
}
70+
}

Diff for: staging/api/pkg/operators/v1/operatorgroup_types.go

+56
Original file line numberDiff line numberDiff line change
@@ -24,8 +24,29 @@ const (
2424
MutlipleOperatorGroupCondition = "MultipleOperatorGroup"
2525
MultipleOperatorGroupsReason = "MultipleOperatorGroupsFound"
2626
OperatorGroupServiceAccountReason = "ServiceAccountNotFound"
27+
28+
// UpgradeStrategyDefault configures OLM such that it will only allow
29+
// clusterServiceVersions to move to the replacing phase to the succeeded
30+
// phase. This effectively means that OLM will not allow operators to move
31+
// to the next version if an installation or upgrade has failed.
32+
UpgradeStrategyDefault UpgradeStrategy = "Default"
33+
34+
// UpgradeStrategyUnsafeFailForward configures OLM such that it will allow
35+
// clusterServiceVersions to move to the replacing phase from the succeeded
36+
// phase or from the failed phase. Additionally, OLM will generate new
37+
// installPlans when a subscription references a failed installPlan and the
38+
// catalog has been updated with a new upgrade for the existing set of
39+
// operators.
40+
//
41+
// WARNING: The UpgradeStrategyUnsafeFailForward upgrade strategy is unsafe
42+
// and may result in unexpected behavior or unrecoverable data loss unless
43+
// you have deep understanding of the set of operators being managed in the
44+
// namespace.
45+
UpgradeStrategyUnsafeFailForward UpgradeStrategy = "TechPreviewUnsafeFailForward"
2746
)
2847

48+
type UpgradeStrategy string
49+
2950
// OperatorGroupSpec is the spec for an OperatorGroup resource.
3051
type OperatorGroupSpec struct {
3152
// Selector selects the OperatorGroup's target namespaces.
@@ -45,6 +66,29 @@ type OperatorGroupSpec struct {
4566
// Static tells OLM not to update the OperatorGroup's providedAPIs annotation
4667
// +optional
4768
StaticProvidedAPIs bool `json:"staticProvidedAPIs,omitempty"`
69+
70+
// UpgradeStrategy defines the upgrade strategy for operators in the namespace.
71+
// There are currently two supported upgrade strategies:
72+
//
73+
// Default: OLM will only allow clusterServiceVersions to move to the replacing
74+
// phase from the succeeded phase. This effectively means that OLM will not
75+
// allow operators to move to the next version if an installation or upgrade
76+
// has failed.
77+
//
78+
// TechPreviewUnsafeFailForward: OLM will allow clusterServiceVersions to move to the
79+
// replacing phase from the succeeded phase or from the failed phase.
80+
// Additionally, OLM will generate new installPlans when a subscription references
81+
// a failed installPlan and the catalog has been updated with a new upgrade for
82+
// the existing set of operators.
83+
//
84+
// WARNING: The TechPreviewUnsafeFailForward upgrade strategy is unsafe and may result
85+
// in unexpected behavior or unrecoverable data loss unless you have deep
86+
// understanding of the set of operators being managed in the namespace.
87+
//
88+
// +kubebuilder:validation:Enum=Default;TechPreviewUnsafeFailForward
89+
// +kubebuilder:default=Default
90+
// +optional
91+
UpgradeStrategy UpgradeStrategy `json:"upgradeStrategy,omitempty"`
4892
}
4993

5094
// OperatorGroupStatus is the status for an OperatorGroupResource.
@@ -76,6 +120,7 @@ type OperatorGroup struct {
76120
metav1.ObjectMeta `json:"metadata"`
77121

78122
// +optional
123+
// +kubebuilder:default={upgradeStrategy:Default}
79124
Spec OperatorGroupSpec `json:"spec"`
80125
Status OperatorGroupStatus `json:"status,omitempty"`
81126
}
@@ -98,6 +143,17 @@ func (o *OperatorGroup) BuildTargetNamespaces() string {
98143
return strings.Join(ns, ",")
99144
}
100145

146+
// UpgradeStrategy returns the UpgradeStrategy specified or the default value otherwise.
147+
func (o *OperatorGroup) UpgradeStrategy() UpgradeStrategy {
148+
strategyName := o.Spec.UpgradeStrategy
149+
switch {
150+
case strategyName == UpgradeStrategyUnsafeFailForward:
151+
return strategyName
152+
default:
153+
return UpgradeStrategyDefault
154+
}
155+
}
156+
101157
// IsServiceAccountSpecified returns true if the spec has a service account name specified.
102158
func (o *OperatorGroup) IsServiceAccountSpecified() bool {
103159
if o.Spec.ServiceAccountName == "" {

Diff for: staging/operator-lifecycle-manager/CONTRIBUTING.md

+7-6
Original file line numberDiff line numberDiff line change
@@ -31,8 +31,8 @@ This is a rough outline of what a contributor's workflow looks like:
3131
- Identify or create an issue.
3232
- Create a topic branch from where to base the contribution. This is usually the master branch.
3333
- Make commits of logical units.
34-
- Make sure commit messages are in the proper format (see below).
35-
- Ensure all relevant commit messages contain a valid sign-off message (see below).
34+
- Make sure commit messages are in the proper format ([see below][commit-messages]).
35+
- Ensure all relevant commit messages contain a valid sign-off message ([see below][commit-messages]).
3636
- Push changes in a topic branch to a personal fork of the repository.
3737
- Submit a pull request to the operator-framework/operator-lifecycle-manager repository.
3838
- 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
4747

4848
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.
4949

50-
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/).
50+
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/).
5151

5252
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.
5353

@@ -62,19 +62,19 @@ In addition to the linked style documentation, OLM formats Golang packages using
6262

6363
Please follow this style to make the OLM project easier to review, maintain and develop.
6464

65-
### Sign-off ([DCO][DCO])
65+
### Commit Messages and Sign-off ([DCO][DCO])
6666

6767
A [sign-off][sign-off] is a line towards the end of a commit message that certifies the commit author(s).
6868

69-
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.
69+
For more information on the structuring of commit messages, read the information in the [DCO][dco] application that the OLM projects uses.
7070

7171
## Documentation
7272

7373
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.
7474

7575
The OLM documentation mainly lives in the [operator-framework/olm-docs][olm-docs] repository.
7676

77-
[operator_framework]: https://groups.google.com/forum/#!forum/operator-framework
77+
[operator_framework]: <https://groups.google.com/forum/#!forum/operator-framework>
7878
[dco]: <https://developercertificate.org/>
7979
[owners]: <https://github.com/operator-framework/operator-lifecycle-manager/blob/master/OWNERS>
8080
[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
8484
[sign-off]: <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff>
8585
[goimports]: <https://pkg.go.dev/golang.org/x/tools/cmd/goimports>
8686
[gofmt]: <https://pkg.go.dev/cmd/gofmt>
87+
[commit-messages]: <https://github.com/operator-framework/operator-lifecycle-manager/blob/master/CONTRIBUTING.md#commit-messages-and-sign-off-dco>

Diff for: staging/operator-lifecycle-manager/README.md

+10-8
Original file line numberDiff line numberDiff line change
@@ -10,9 +10,10 @@
1010

1111
User documentation can be found on the [OLM website][olm-docs].
1212

13+
1314
## Overview
1415

15-
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/).
16+
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].
1617

1718
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:
1819

@@ -47,13 +48,13 @@ Operators can behave like managed service providers. Their user interface on the
4748

4849
## Getting Started
4950

50-
Check the [Getting Started][olm-getting-started] section.
51+
Check out the [Getting Started][olm-getting-started] section in the docs.
5152

5253
### Installation
5354

5455
Install OLM on a Kubernetes cluster by following the [installation guide][installation-guide].
5556

56-
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).
57+
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).
5758

5859
## User Interface (Running the console Locally)
5960

@@ -96,13 +97,14 @@ Learn more about the components used by OLM by reading about the [architecture]
9697

9798
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.
9899

99-
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)
100+
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),
101+
[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)
100102

101103
## Descriptors
102104

103105
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.
104106

105-
[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)
107+
[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)
106108

107109
## Dependency Resolution
108110

@@ -129,7 +131,7 @@ OLM has the concept of catalogs, which are repositories of application definitio
129131

130132
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).
131133

132-
Example: [etcd package](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/etcd.package.yaml)
134+
Example: [etcd package](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/etcd.package.yaml)
133135

134136
Users can subscribe to channels and have their operators automatically updated when new versions are released.
135137

@@ -154,7 +156,7 @@ Catalogs are served internally over a grpc interface to OLM from [operator-regis
154156

155157
## Samples
156158

157-
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).
159+
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).
158160

159161
## Community and how to get involved
160162

@@ -194,6 +196,6 @@ Operator Lifecycle Manager is under Apache 2.0 license. See the [LICENSE][licens
194196
[operator-framework-community]: https://github.com/operator-framework/community
195197
[operator-framework-communication]: https://github.com/operator-framework/community#get-involved
196198
[operator-framework-meetings]: https://github.com/operator-framework/community#meetings
197-
[contributor-documentation]: https://olm.operatorframework.io/docs/contribution-guidelines/
199+
[contributor-documentation]: ./CONTRIBUTING.md
198200
[olm-getting-started]: https://olm.operatorframework.io/docs/getting-started/
199201
[installation-guide]: doc/install/install.md

0 commit comments

Comments
 (0)