Upstream sync #129
Merged
Upstream sync #129
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…e negatives Signed-off-by: Joe Lanford <[email protected]> Upstream-repository: operator-registry Upstream-commit: 95c5e3bca1ac3abb3bf00f6b7345ddbd047e1524
Signed-off-by: Ben Luddy <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: e731c70a5cd62ab1cab7658f1d17f810f525cd8e
Signed-off-by: Ankita Thomas <[email protected]> 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 <[email protected]> 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 <[email protected]> Co-authored-by: Alexander Greene <[email protected]> Signed-off-by: Ben Luddy <[email protected]> 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 <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 8c8b18bacbc8033ef9d2a8847e730b3aa17247e6
Signed-off-by: Zvi Cahana <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 04b665cea41b2ee63bf89b5ca01712f1214f2a52
Signed-off-by: Zvi Cahana <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: fd344476b1d04b9439590c5fd0da81d7efc3b600
Signed-off-by: Zvi Cahana <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 93ece2a5618ee578c918bf6e5e0ad57d536ad85c
Signed-off-by: Zvi Cahana <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: b393fc5a2a6371261c99cabb009266c95047d047
Signed-off-by: Zvi Cahana <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 303608dbe3c9cbfe4679bafc43a6acafea9f7e9e
Signed-off-by: Evan <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 48115e0f7fce4beb9f50d2d7fd7e2f59380186f8
Also ensure that properties are rendered in a consistent ordering Signed-off-by: Joe Lanford <[email protected]> Upstream-repository: operator-registry Upstream-commit: bb92cc88e4678faa723bac4a8f11d5451c66854b
Signed-off-by: Joe Lanford <[email protected]> Upstream-repository: operator-registry Upstream-commit: c6eae74a1bdec836b5c4ca6b225389e199166c98
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 <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 804875c45c6337d95313f7e4a68982c77e30f614
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 <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 608d6bf1991cdc671a94848e884290a4bc4d9804
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 <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 1ebebdb37af7c64b800ff7ec3a04ddd0cccc2de7
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 <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 9d14698a1330c690d6960f89d6b4db0571001194
The catalog deployment template only sets the readiness and liveness probes to HTTPS Scheme if the values.catalog.tlsKeyPath and values.catalog.tlsCertPath configurations are provided. These values should be set when the values.catalog.tlsSecret configuration is set The olm deployment template is also updated to use HTTPS when values.olm.tlsSecret is set. Signed-off-by: Alexander Greene <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: d49ce6af813089f176d0f101bf55df4dba25c5d9
…shift#138) Upstream-repository: api Upstream-commit: a3fa2bd8d7c7f540824cda1b06f6677f198cfbb8
… discovery in case of 404 not found errors when applying installplan steps. Upstream-repository: operator-lifecycle-manager Upstream-commit: c2674279c862b3b8264efddc931eee250c52beb5
The olm deployment template will only use HTTPS when values.olm.tlsSecret is set in the values.yaml file. Signed-off-by: Alexander Greene <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: f1a3e5d917a8c7dc73c30a97a4099571c999f630
Update catalog operator manifest chart template to include variable for new opmImage argument Upstream-repository: operator-lifecycle-manager Upstream-commit: 0ec7aca77a4cc0074a9d74a4bde50c574af7aea9
Problem: The getMetricsFromPod function assumes that metrics are exposed on port 8080. This function fails to retrieve metrics from the olm or catalog operator when the port is changed. Solution: Name the port in each of the deployments and update the getMetricsFromPod function to infer the port number from the deployments. Signed-off-by: Alexander Greene <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 08a1d4b2f06fda1a6d6b4cadf779e1ce2259af3e
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kevinrizza The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/test e2e-aws-olm |
|
/retest |
|
I'm going to preemptively tag this given the upgrade e2e has passed - hopefully any substantial errors are weeded out in the e2e-aws-olm test. /lgtm |
|
/test e2e-aws-olm |
11 tasks
anik120
pushed a commit
to anik120/operator-framework-olm
that referenced
this pull request
Dec 9, 2021
Upstream-repository: api Upstream-commit: f0e01e74c12537cccf8f9dfc6f76b0d4393b0572
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.