-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skuznets/bump all #567
Skuznets/bump all #567
Conversation
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
Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: b1ac5a476159b02db42a1022f1ec81ff4441a2d9
When an OperatorGroup creates a ClusterRole, it's based directly on the OG name with a suffix, this causes two issues: 1. same-named OGs in different namespaces overwrite each others CRs 2. there are some very important CRs that could be overwritten by OG Tests added. Signed-off-by: Per Goncalves da Silva <[email protected]> Signed-off-by: Todd Short <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 306cd60d8f204ce80c065bade124ff4eb353151a
Signed-off-by: Todd Short <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 20fbc301102f7553496c4be7d01b6e519c811179
Signed-off-by: Andy Goldstein <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 530ca9ceb959ba1a517d231499840e0156b53a19
Signed-off-by: Jordan Keister <[email protected]> Upstream-repository: operator-registry Upstream-commit: eaebcf63f94dabdabc3a25ceeeedcb26aaa11d79 Signed-off-by: Steve Kuznetsov <[email protected]>
30504fb
to
c906ded
Compare
Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 44935f1e276ea25a4d1e5efcc82867e5e84f7324 Signed-off-by: Steve Kuznetsov <[email protected]>
Signed-off-by: Steve Kuznetsov <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 662ff51f6fe113fd06d00823ddfff6586754276b Signed-off-by: Steve Kuznetsov <[email protected]>
Signed-off-by: Steve Kuznetsov <[email protected]>
Signed-off-by: Steve Kuznetsov <[email protected]>
c906ded
to
4579920
Compare
/retest |
2 similar comments
/retest |
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dinhxuanvu, stevekuznetsov 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 |
@stevekuznetsov: all tests passed! 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. |
No description provided.