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

🌱 Migrate Rukpak #1032

Merged
merged 1 commit into from
Jul 12, 2024
Merged

Conversation

dtfranz
Copy link
Contributor

@dtfranz dtfranz commented Jul 10, 2024

Moves rukpak code imported by operator-controller into the internal/ folder.

Fixes #997

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 10, 2024
Copy link

netlify bot commented Jul 10, 2024

Deploy Preview for olmv1 ready!

Name Link
🔨 Latest commit bf85b3c
🔍 Latest deploy log https://app.netlify.com/sites/olmv1/deploys/66914a8cf0571100098ef5c7
😎 Deploy Preview https://deploy-preview-1032--olmv1.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@@ -0,0 +1,244 @@
/*
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Commenting here to call specific attention to this file. How much more of the k8s stuff here can be removed? Do we need the json:"..." tags? Are we OK with the fact that I copied an autogenerated func into this file in order to maintain DeepCopy()?

@dtfranz dtfranz changed the title Migrate Rukpak 🌱 WIP: Migrate Rukpak Jul 10, 2024
@dtfranz
Copy link
Contributor Author

dtfranz commented Jul 10, 2024

General comment: there are likely some things copied over that are unused. I'll go through and make sure that's all removed.

Copy link

codecov bot commented Jul 10, 2024

Codecov Report

Attention: Patch coverage is 66.56347% with 216 lines in your changes missing coverage. Please review.

Project coverage is 73.46%. Comparing base (64f99f2) to head (bf85b3c).

Files Patch % Lines
internal/rukpak/source/image_registry.go 41.34% 44 Missing and 17 partials ⚠️
internal/rukpak/convert/registryv1.go 85.10% 23 Missing and 19 partials ⚠️
internal/rukpak/provisioner/plain/plain.go 60.00% 10 Missing and 10 partials ⚠️
internal/rukpak/source/unpacker.go 0.00% 19 Missing ⚠️
internal/rukpak/util/tar.go 47.05% 10 Missing and 8 partials ⚠️
...ak/preflights/crdupgradesafety/crdupgradesafety.go 70.17% 10 Missing and 7 partials ⚠️
...ternal/rukpak/bundledeployment/bundledeployment.go 0.00% 12 Missing ⚠️
internal/rukpak/util/fs.go 0.00% 10 Missing ⚠️
internal/rukpak/storage/localdir.go 73.33% 4 Missing and 4 partials ⚠️
internal/rukpak/util/util.go 80.00% 2 Missing and 2 partials ⚠️
... and 3 more
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1032      +/-   ##
==========================================
- Coverage   77.00%   73.46%   -3.55%     
==========================================
  Files          19       32      +13     
  Lines        1357     1986     +629     
==========================================
+ Hits         1045     1459     +414     
- Misses        222      368     +146     
- Partials       90      159      +69     
Flag Coverage Δ
e2e 55.84% <55.72%> (-0.61%) ⬇️
unit 45.01% <27.39%> (-8.86%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@dtfranz dtfranz force-pushed the migrate-rukpak branch 2 times, most recently from ecacb47 to 58cd0bf Compare July 10, 2024 23:30
@dtfranz
Copy link
Contributor Author

dtfranz commented Jul 10, 2024

General comment: there are likely some things copied over that are unused. I'll go through and make sure that's all removed.

I've removed everything I could find that was unused; see comparison here to see what I left out.

@joelanford
Copy link
Member

WDYT about dumping everything in under internal/rukpak for now so that it's more obvious in a first pass what came from rukpak and what changed in existing operator-controller code?

I'm very much in favor of moving our rukpak code directly into this repo, but I'm also feeling a little bit like we need to (in a future PR) step back and take stock of our suddenly sprawling codebase to see if there are obsolete abstractions (e.g. unpack + storage) and other ways to reduce our package count and tidy things up a bit.

@@ -280,7 +280,7 @@ func (r *ClusterExtensionReconciler) reconcile(ctx context.Context, ext *ocv1alp
case rukpaksource.StateUnpacked:
// TODO: Add finalizer to clean the stored bundles, after https://github.com/operator-framework/rukpak/pull/897
// merges.
if err := r.Storage.Store(ctx, ext, unpackResult.Bundle); err != nil {
if err := r.Storage.Store(ctx, ext.GetName(), unpackResult.Bundle); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this just because you realized we only need to store the name and not the whole struct?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, the thing we're actually storing is the unpackResult.Bundle, and ext was passed in purely for its identifier.

bd "github.com/operator-framework/operator-controller/internal/bundledeployment"
)

type Handler interface {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this maybe become less generic, so RegistryHandler perhaps?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, there's a good argument for that since we're only using one of the 3 types from rukpak.

manifestsDir = "manifests"
)

func HandleBundleDeployment(_ context.Context, fsys fs.FS, _ *bundledeployment.BundleDeployment) (*chart.Chart, chartutil.Values, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like a unit test on this with Bundle in/Chart out would be good. Just in case Helm bumps, etc, shift something on us

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right; and that brings up another larger issue for this PR: Rukpak was kind of infamous for testing with e2e tests instead of unit tests, so we can't bring over a lot of those tests as-is. Personally I think there's probably too much new code in this PR for adding unit tests for all of it and I'd prefer to open a new issue for that if you think that's reasonable.

Copy link
Contributor

@bentito bentito Jul 11, 2024

Choose a reason for hiding this comment

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

sounds good.to me. just need an issue for adding rukpakian related unit tests, to do later

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Created #1037

"path/filepath"
"strings"

"github.com/containerd/containerd/archive"
Copy link
Contributor

Choose a reason for hiding this comment

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

The focus here is just pull in the code, but maybe we should add an issue to make more use of containerd for the future? Seems like containerd has image operations that could simplify TLS and authentication handling, streamline pulling images, and optimize unpacking layers.

@dtfranz
Copy link
Contributor Author

dtfranz commented Jul 11, 2024

WDYT about dumping everything in under internal/rukpak for now so that it's more obvious in a first pass what came from rukpak and what changed in existing operator-controller code?

I'm very much in agreement with this and your other thought as well. Since I filtered out a lot of the types there's not currently much reason for the abstract types like storage to exist in the codebase.

For now at the very least I'll move everything into the rukpak subdir inside internal.

@dtfranz dtfranz marked this pull request as ready for review July 11, 2024 17:50
@dtfranz dtfranz requested a review from a team as a code owner July 11, 2024 17:50
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 11, 2024
@dtfranz dtfranz changed the title 🌱 WIP: Migrate Rukpak 🌱 Migrate Rukpak Jul 11, 2024
@tmshort
Copy link
Contributor

tmshort commented Jul 12, 2024

For now at the very least I'll move everything into the rukpak subdir inside internal.

This is what I originally did for the original integration (before we pulled everything back)

@tmshort
Copy link
Contributor

tmshort commented Jul 12, 2024

We might possibly want to remove rukpak references from .golangci.yaml, but not critical now. With this it appears that there are no references to the external operator-framework/rukpak repo any more.

@tmshort
Copy link
Contributor

tmshort commented Jul 12, 2024

Looks as though a lot of the original code was not pulled over (good), and necessary changes made to only support imagev1.

tmshort
tmshort previously approved these changes Jul 12, 2024
Copy link
Contributor

@tmshort tmshort left a comment

Choose a reason for hiding this comment

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

/lgtm

@tmshort
Copy link
Contributor

tmshort commented Jul 12, 2024

@dtfranz, you'll need to rebase due to go.mod changes....

Moves rukpak code imported by operator-controller into the internal/ folder.

Signed-off-by: dtfranz <dfranz@redhat.com>
@tmshort
Copy link
Contributor

tmshort commented Jul 12, 2024

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jul 12, 2024
@tmshort tmshort enabled auto-merge July 12, 2024 15:37
@tmshort tmshort added this pull request to the merge queue Jul 12, 2024
Merged via the queue into operator-framework:main with commit e5470e2 Jul 12, 2024
15 of 17 checks passed
perdasilva pushed a commit to LalatenduMohanty/operator-controller that referenced this pull request Aug 13, 2024
Moves rukpak code imported by operator-controller into the internal/ folder.

Signed-off-by: dtfranz <dfranz@redhat.com>
perdasilva pushed a commit to kevinrizza/operator-controller that referenced this pull request Aug 13, 2024
Moves rukpak code imported by operator-controller into the internal/ folder.

Signed-off-by: dtfranz <dfranz@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pull rukpak code into operator-controller
4 participants