Synchronize From Upstream Repositories #562
Closed
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
openshift-bot
added
approved
|
@openshift-bot: GitHub didn't allow me to request PR reviews from the following users: openshift/openshift-team-operator-ecosystem. Note that only openshift members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions 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. |
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: openshift-bot 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 |
1 similar comment
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: openshift-bot 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 |
This was referenced Sep 9, 2023
Closed
Closed
openshift-bot
force-pushed
the
synchronize-upstream
branch
from
5f78231 to
ce6d452
Compare
openshift-bot
force-pushed
the
synchronize-upstream
branch
from
ce6d452 to
87b2554
Compare
|
/test e2e-gcp-olm |
|
/retest |
Signed-off-by: Todd Short <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: ad4ac77284454a077ecccfc6740f180bbb58e6f4
Signed-off-by: Jordan Keister <[email protected]> Upstream-repository: operator-registry Upstream-commit: dba1e1052875cbf3850058120c8eb7a1c8a5d11c
Fixes path join issue Signed-off-by: Todd Short <[email protected]> Upstream-repository: operator-registry Upstream-commit: 7f37952d54699439d27e0dc27c1a5778cdb101ec
…t#290) Fixes path join issue Signed-off-by: Todd Short <[email protected]> Upstream-repository: api Upstream-commit: 775e6c6534b89dde01826627ceb570c16ab6768f
Fixes path join issue Signed-off-by: Todd Short <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: a827c02a0530c0b0532630662dda423773cc5ed9
We won't be setting a memory limit, so udpate the doc. Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: api Upstream-commit: 44b1863648b50fde3d71e02ffd2c1b47cc348fed
It's not allowed for core components to have memory limits, to ensure that that source of crash-looping pods does not occur to the core payload. Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: ff0baf43e041332c8d20540c8b0c7a22ca5e65bd
Using a full LIST+WATCH is an optimization, with trade-offs. Holding the state of the world for CRDs in memory when we rarely, if ever, actually need to access them is a bad use of that trade-off, especially when the sum total size of CRDs on even the most basic cluster is O(20MiB). Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 12437b3dc94ae1756ac8c036261391214bf60cff
…gs (#3012) The alerting consistency guide [1] requires the following: `Alerts SHOULD include a namespace label indicating the alert's source.` This change updates the expression of InstallPlanStepAppliedWithWarnings to aggregate the result by namespace. [1] https://github.com/openshift/enhancements/blob/master/enhancements/monitoring/alerting-consistency.md Signed-off-by: Simon Pasquier <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 2976198c8e22837af8b7ade704212a536fa37071
If status is modified, the operator must set status to proper values. This ensures that accidents cannot permanently reset status and gives a clear indication that the operator is "live". This came up as important when operators were NOT live, during cert rotations and we had no indication of problems. Signed-off-by: Luis Sanchez <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 0dbf79d283438b09c40a08429e9c8028a1a0dfbc
* add a round-tripper to ensure we label non-OLM resources This round-tripper is added to our *rest.Config when it's possible to detect that we're in a CI environment. Developers should set $CI=true to get this behavior locally. Signed-off-by: Steve Kuznetsov <[email protected]> * *: label non-OLM resources Today, our controllers use un-filtered LIST+WATCH calls to monitor the state of the cluster. For OLM-specific resource types, that's fine, since we need to know (for instance) about every CSV. For non-OLM resource groups, though, that is needlessly wasteful in memory consumption and makes our controller's footprint scale with the size of the cluster itself, irrespective of the usage of OLM. Adding a label to every resource we create is the first step in being able to filter down all of those requests to only those objects with our label. Signed-off-by: Steve Kuznetsov <[email protected]> --------- Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 9e7031f2c0fae1391150d2efca603612f09bf141
… (#1138) Signed-off-by: Jordan Keister <[email protected]> Upstream-repository: operator-registry Upstream-commit: 56771f76adbefa30190c4199d1cc970299f3ef04
Problem: Creating a catalogSource with a period in the name is valid as the Kuberenetes API catalogSources to adhere to the following naing conventions: - Start and end with a lower case alphanumeric character - Consist only of alphanumeric characters, `.`, or `-` Unfortunately, the service created by OLM for the catalogSource must adhere to the following naming conventions: - Start and end with a lower case alphanumeric character - Consist only of alphanumeric characters or `-` This causes OLM to constantly recreate the catalogSource as the service it attempts to create is rejected from the Kubernetes API service due to the `.` in the name. Solution: When naming the service, replace all instances of `.` in the name with `-`. Signed-off-by: Alexander Greene <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 6e0d407d468ce1dda4223cc7b322e255a2144bfb
Signed-off-by: Jordan Keister <[email protected]> Upstream-repository: operator-registry Upstream-commit: d02b0b68acab6bb218b431bed70b3703ffc168ab
Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: c55c24d67005ec370ae9cf45c6c5350db90e2161
* *: filter informers when preconditions are met When we can detect at startup time that all of the objects we're about to look at have the labels we're expecting, we can filter our informer factories upfront. Signed-off-by: Steve Kuznetsov <[email protected]> * test/e2e: improvements Signed-off-by: Steve Kuznetsov <[email protected]> --------- Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: c0c61fe3d6ee5e1f1ee77c0e892858167126505b
…penshift#293) As the file-based catalog schemas mature, the couping between `opm` and the catalog data is effectively removed. We can take advantage of this new property in the system to not require that a server binary exist in the catalog index image, and remove many of the pain-points that come from using the embedded server binary. Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: api Upstream-commit: 039d150defbba9f1e8cd63cf8655556c90434a2d
This commit uses a shared buffer in a shared decoder for the ListBundles call, which should reduce our memory footprint when we're asked for this data. I also changed the sorting of the key-set to be an explicit call to sort.Slice, instead of an implicit side-effect from sets.New().List(). Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-registry Upstream-commit: 5ca4a9f7dcb7be737b18f952f72a3a4dc195d841
Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: api Upstream-commit: bb012a3b9b2573023a6cee00c0ea2badb413022e
Incrementing the operator-registry version ref to resolve a cve in a transient dependency. Updating golang-migrate removes a dependency to mongo-driver. Resolves GHSA-f6mq-5m25-4r72 Signed-off-by: kevinrizza <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 03d2bf01b79a6db20a0ff8ea778ca2d03c0924f5
Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: api Upstream-commit: 28c6773d2b746559369035cfa3d211360706a247
… (#3029) * go.mod: update the api dependency Signed-off-by: Steve Kuznetsov <[email protected]> * controller/registry: implement content extraction for catalog sources Signed-off-by: Steve Kuznetsov <[email protected]> --------- Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: ed03be342d0a93dc118df13d81a77ff85b80f985
Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 5c9ae5a284da563051d4df977190f9a8b3e257f9
Signed-off-by: Per Goncalves da Silva <[email protected]> Co-authored-by: Per Goncalves da Silva <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 3c1daa9d67e4511c3a81e3938628d3ac4fd1287d
Bumps [github.com/cyphar/filepath-securejoin](https://github.com/cyphar/filepath-securejoin) from 0.2.3 to 0.2.4. - [Release notes](https://github.com/cyphar/filepath-securejoin/releases) - [Commits](cyphar/filepath-securejoin@v0.2.3...v0.2.4) Upstream-repository: operator-lifecycle-manager Upstream-commit: 46f4f895cac1777c977400293f334cfc552103d9 --- updated-dependencies: - dependency-name: github.com/cyphar/filepath-securejoin dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
When a CSV is processed, it is assumed that the InstallPlan has already run, or that a user that's creating a CSV as their entrypoint into the system has otherwise met all the preconditions for the CSV to exist. As part of validating these preconditions, the CSV logic today uses cluster-scoped listers for all RBAC resources. sets up an in-memory authorizer for these, and queries the CSV install strategie's permissions against those. We would like to restrict the amount of memory OLM uses, and part of that is not caching the world. For the above approach to work, all RBAC objects fulfilling CSV permission preconditions would need to be labelled. In the case that a user is creating a CSV manually, this will not be the case. We can use the SubjectAccessReview API to check for the presence of permissions without caching the world, but since a PolicyRule has slices of verbs, resources, subjects, etc and the SAR endpoint accepts but one of each, there will be (in the general case) a combinatorical explosion of calls to issue enough SARs to cover the full set of permissions. Therefore, we need to limit the amount of times we take that action. A simple optimization is to check for permissions created directly by OLM, as that's by far the most common entrypoint into the system (a user creates a Subscription, that triggers an InstallPlan, which creates the RBAC). As OLM chose to name the RBAC objects with random strings of characters, it's not possible to look at a list of permissions in a CSV and know which resources OLM would have created. Therefore, this PR adds a label to all relevant RBAC resources with the hash of their content. We already have the name of the CSV, but since CSV content is ostensibly mutable, this is not enough. Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 8eb4f3e5cb786c47b137c6650c2c530718bc7906
openshift-bot
force-pushed
the
synchronize-upstream
branch
from
87b2554 to
a16d98e
Compare
|
/retest |
|
/retest |
|
@openshift-bot: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions 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. |
|
Managed to break the bot with missing commits, superseded by #567 |
|
/close |
|
@stevekuznetsov: Closed this PR. In response to this:
Instructions 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. |
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.
The staging/ and vendor/ directories have been synchronized from the upstream repositories, pulling in the following commits:
This pull request is expected to merge without any human intervention. If tests are failing here, changes must land upstream to fix any issues so that future downstreaming efforts succeed.
/cc @openshift/openshift-team-operator-runtime
/cc @openshift/openshift-team-operator-ecosystem