Sync with upstream master branches#122
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ankitathomas The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
|
/retest |
…e negatives Signed-off-by: Joe Lanford <joe.lanford@gmail.com> Upstream-repository: operator-registry Upstream-commit: 95c5e3bca1ac3abb3bf00f6b7345ddbd047e1524
Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: e731c70a5cd62ab1cab7658f1d17f810f525cd8e
Signed-off-by: Ankita Thomas <ankithom@redhat.com> Upstream-repository: operator-registry Upstream-commit: 9e88b877c8324d5fd027e512ad845b344cc4168a
Operator dependencies are expressed as properties, but there was initially a notion of dependencies as distinct from properties. For that reason, catalog-operator must support existing catalog images that serve separate Bundle.dependencies and Bundle.properties fields by translating the three legacy dependency types (olm.label, olm.package, and olm.gvk) into their corresponding properties. Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: c918a85eb7ef0c1ea58ebf27fabd8d2393afe9b3
TLS can still be enabled via flags, but it now applies to all three APIs since there is a single HTTP server per operator process. The -profiling flag is deprecated and does nothing. The profiling APIs are now always enabled, but they refuse to serve clients that do not present a verifiable certificate (see the new flag -client-ca). This effectively disables the profiling APIs when served over HTTP. Co-authored-by: Vu Dinh <vudinh@outlook.com> Co-authored-by: Alexander Greene <agreene@redhat.com> Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: f9381e0ce8e0addeb1abf55d44146a5e6e57074a
This line creates an info-level logger, writes a trace-level log to it, and discards the logger reference. This looks like cruft and is responsible for some heap churn. Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 8c8b18bacbc8033ef9d2a8847e730b3aa17247e6
Signed-off-by: Zvi Cahana <zvic@il.ibm.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 04b665cea41b2ee63bf89b5ca01712f1214f2a52
Signed-off-by: Zvi Cahana <zvic@il.ibm.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: fd344476b1d04b9439590c5fd0da81d7efc3b600
Signed-off-by: Zvi Cahana <zvic@il.ibm.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 93ece2a5618ee578c918bf6e5e0ad57d536ad85c
Signed-off-by: Zvi Cahana <zvic@il.ibm.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: b393fc5a2a6371261c99cabb009266c95047d047
Signed-off-by: Zvi Cahana <zvic@il.ibm.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 7c481a1c43f999656953c380dcb35e4df3d27df3
The "multiple channel head" error that can be returned from channel sorting has been a source of confusion for users. The error message now explains that a unique replacement chain is required in order to define the relative order between channel entries, and it also provides an abbreviated list of all replacement chains identified, in the form "head...tail" or "singleton". Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 639102545cb6faabe9a1f30970dffca93bfb058a
A behavior was added with the intention of preventing the installation of channel entries that are skipped by other entries, but in practice it was omitting entries that were replaced by skipped entries. This is fixed. There are now unit test cases and one higher-level test for this behavior. Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 0bb8c1ea9741071830711e3517f39e264f561154
The function that generated the selector had been returning a selector that matches everything. There was no functional impact because there's an additional client-side filter that discards objects based on CSV.IsCopied(). Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 0f58a2c7d78cceb22e8ccf6b3b00c1520987a7d4
Only the main controller (i.e., the controller responsible for reconciling ClusterServiceVersions) needs to watch copied ClusterServiceVersions. The OperatorCondition and Operator controllers -- which coincidentally maintain separate caches -- are not interested in copied CSVs, so all copied CSVs can be excluded via from their cache using a label selector. Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: e641e7695c944b3a1eef6ce425cd748f2843ddc9
Currently when an InstallPlan fails, due to bundle unpacking error
is pending due to errors like invalid operatorgroup, or pending bundle unpacking job
the reason is propagated to the Subscription that owns it. The message for the failure is
however missing from the Subscription condition.
eg
```
kind: Subscription
status:
conditions:
- lastTransitionTime: "2021-07-07T17:55:20Z"
reason: Installing
status: "True"
type: InstallPlanPending
```
This PR propagates the message assosiated with the reason in the InstallPlan
condition when an InstallPlan is either pending, or has failed permanantly.
eg
```
kind: Subscription
status:
conditions:
- lastTransitionTime: "2021-07-07T17:55:20Z"
message: no operator group found that is managing this namespace
reason: Installing
status: "True"
type: InstallPlanPending
```
Signed-off-by: Anik Bhattacharjee <anikbhattacharya93@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 303608dbe3c9cbfe4679bafc43a6acafea9f7e9e
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
/retest |
1 similar comment
|
/retest |
|
Can we also include commits introduced by operator-framework/operator-lifecycle-manager#2270? |
|
/retest |
Signed-off-by: Evan <cordell.evan@gmail.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 48115e0f7fce4beb9f50d2d7fd7e2f59380186f8
Whe building the subscription condition message, check if the status of the InstallPlan is available before iterating through bundle lookup conditions. Also update string returned to include spaces between multiple messages. Signed-off-by: Alexander Greene <greene.al1991@gmail.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 804875c45c6337d95313f7e4a68982c77e30f614
Add special handling for version shorthand commonly used in pipelines for Red Hat operator catalogs. Allows unquoted short versions to be used when specifying an operator's compatibility with versions of OpenShift; e.g. "olm.maxOpenShiftVersion": 4.8. Without this, OLM will only recognize quoted maxOpenShiftVersion properties; e.g. "olm.maxOpenShiftVersion": "4.8". Signed-off-by: Nick Hale <njohnhale@gmail.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 1ebebdb37af7c64b800ff7ec3a04ddd0cccc2de7
The Operator adoption controller reads metadata.ownerReferences and metadata.labels to adopt Operator components, and the Operator controller itself maintains a list of component references in status.components.refs. For APIs without a status.conditions field, these references are equivalent to v1 ObjectReferences, and can be constructed using only the component's metadata. For APIs that do have a status.conditions field, the references are augmented with that information. Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 608d6bf1991cdc671a94848e884290a4bc4d9804
kube_deps is not used for pinning kube dependencies anymore the other scripts were used for older ways that olm integrated with openshift and are no longer needed Upstream-repository: operator-lifecycle-manager Upstream-commit: d918d71be9c8b752f3172b08e4c993823df95767
This should unblock our use for metadata-only watches for the moment. Signed-off-by: Ben Luddy <bluddy@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 9d14698a1330c690d6960f89d6b4db0571001194
c2211ae to
31420eb
Compare
|
@ankitathomas: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
This PR downstreams all new commits in tracked upstream master branches since #116. The commits messages are tagged with upstream metadata and nested vendor/OWNERS files are cleaned up. Merge commits are skipped to avoid cherry-picking empty commits. Cherry-picked with on https://gist.github.com/ankitathomas/8edb94bd3feb963c7304ad39eebdaf62#file-cherrypick_all-sh