-
Notifications
You must be signed in to change notification settings - Fork 66
✨ Add support for deploying OCI helm charts in OLM v1 #1971
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
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,9 +26,11 @@ import ( | |
|
||
ocv1 "github.com/operator-framework/operator-controller/api/v1" | ||
"github.com/operator-framework/operator-controller/internal/operator-controller/authorization" | ||
"github.com/operator-framework/operator-controller/internal/operator-controller/features" | ||
"github.com/operator-framework/operator-controller/internal/operator-controller/rukpak/bundle/source" | ||
"github.com/operator-framework/operator-controller/internal/operator-controller/rukpak/preflights/crdupgradesafety" | ||
"github.com/operator-framework/operator-controller/internal/operator-controller/rukpak/util" | ||
imageutil "github.com/operator-framework/operator-controller/internal/shared/util/image" | ||
) | ||
|
||
const ( | ||
|
@@ -209,6 +211,17 @@ func (h *Helm) buildHelmChart(bundleFS fs.FS, ext *ocv1.ClusterExtension) (*char | |
if err != nil { | ||
return nil, err | ||
} | ||
if features.OperatorControllerFeatureGate.Enabled(features.HelmChartSupport) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We've been trying to put the feature checks in main. Wdyt about refactoring to have another implementation of the BundleToHelmChart converter that accepts chart bundles, or maybe that can route between different bundle types? Then if the feature gate is enabled, use that one? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do not have any concerns with having feature checks in main. I think that would be the ideal scenario as it would allow for feature-gated functionality to be tested at build time. Trying to look at the issue from afar, our challenge in this case is we are trying to run tests on a feature gated function, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We are working towards to it We will use the experimental CRD and have all feature flags enabled for our e2e tests. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @OchiengEd I think in order to do it properly, we'll need some architectural changes to the applier. As it is now, it assumes it will be receiving a registry+v1 bundle FS. As the code is now, we are expanding the scope of the applier to also identify the bundle type and produce a chart accordingly. I think we should pivot and instead of the applier having a The In the main function, we can then configure the HelmChartGetter to either include (or not) the the interface implementation that deals with Helm bundles. Alternatively, we compose have two HelmChartGetters, one with the standard implementation for registry+v1 bundles and another that uses the standard implementation and extends it by basically the code you have here (e.g. first check whether its a helm chart fs, if not, then just use the standard implementation). The same pattern could be used for the Cache. If the flag is set, configure it one way, if not, configure it another. Breaking it down like this makes it easy to test independently and you don't even need to rely on flags being set or not for (unit) testing. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To keep momentum, I'll approve this for now and maybe we could work together on a refactor as a fast follow. |
||
meta := new(chart.Metadata) | ||
if ok, _ := imageutil.IsBundleSourceChart(bundleFS, meta); ok { | ||
return imageutil.LoadChartFSWithOptions( | ||
bundleFS, | ||
fmt.Sprintf("%s-%s.tgz", meta.Name, meta.Version), | ||
imageutil.WithInstallNamespace(ext.Spec.Namespace), | ||
) | ||
} | ||
} | ||
OchiengEd marked this conversation as resolved.
Show resolved
Hide resolved
camilamacedo86 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
return h.BundleToHelmChartConverter.ToHelmChart(source.FromFS(bundleFS), ext.Spec.Namespace, watchNamespace) | ||
} | ||
|
||
|
Uh oh!
There was an error while loading. Please reload this page.
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.
@OchiengEd
Here: https://github.com/operator-framework/operator-controller/pull/1724/files
@perdasilva added a demo and the doc under the docs/draft for another alpha feature
It would be very nice if we could do your demo within and add the doc for that. Such as it was done in this PR. However, I am okay with it being a follow-up.
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.
I would be for adding documentation and a demo as a follow up.