Skip to content
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

Merged

Conversation

stevekuznetsov
Copy link
Contributor

No description provided.

tmshort and others added 30 commits September 22, 2023 10:30
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]>
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]>
@stevekuznetsov
Copy link
Contributor Author

/retest

2 similar comments
@stevekuznetsov
Copy link
Contributor Author

/retest

@dinhxuanvu
Copy link
Member

/retest

Copy link
Member

@dinhxuanvu dinhxuanvu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 25, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Sep 25, 2023

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 25, 2023
@openshift-ci-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD ab674aa and 2 for PR HEAD 4579920 in total

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Sep 26, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.