✨ Add support for deploying OCI helm charts in OLM v1 #1971
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1971 +/- ##
==========================================
+ Coverage 69.28% 73.77% +4.49%
==========================================
Files 79 81 +2
Lines 7051 7322 +271
==========================================
+ Hits 4885 5402 +517
+ Misses 1884 1584 -300
- Partials 282 336 +54
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
OchiengEd
force-pushed
the
helm_explorations
branch
from
3b36dfb to
272dcbf
Compare
OchiengEd
force-pushed
the
helm_explorations
branch
from
272dcbf to
39948a0
Compare
OchiengEd
force-pushed
the
helm_explorations
branch
4 times, most recently
from
6dfc6c0 to
059008d
Compare
|
When pulling a Helm chart with a provenance file, at this time we have chosen to skip pulling the layer to the cache filesystem since we have no logic in place at this time to verify the chart integrity. operator-controller/internal/shared/util/image/helm.go Lines 62 to 65 in 059008d |
OchiengEd
requested review from
joelanford,
camilamacedo86,
trgeiger and
kevinrizza
OchiengEd
force-pushed
the
helm_explorations
branch
from
059008d to
797bddb
Compare
OchiengEd
force-pushed
the
helm_explorations
branch
4 times, most recently
from
4b69de7 to
f33fe5c
Compare
|
Also added logic to inspect the contents of a operator-controller/internal/shared/util/image/helm.go Lines 97 to 135 in 059008d |
OchiengEd
force-pushed
the
helm_explorations
branch
2 times, most recently
from
959072a to
b569fb8
Compare
OchiengEd
force-pushed
the
helm_explorations
branch
from
b569fb8 to
9f59039
Compare
OchiengEd
force-pushed
the
helm_explorations
branch
from
9f59039 to
c08ce64
Compare
| ociImg, err := img.OCIConfig(ctx) | ||
| if err != nil { | ||
| return nil, time.Time{}, err | ||
| } | ||
|
|
||
| layerIter := iter.Seq[LayerData](func(yield func(LayerData) bool) { | ||
| for i, layerInfo := range img.LayerInfos() { | ||
| ld := LayerData{Index: i} | ||
| ld := LayerData{Index: i, MediaType: layerInfo.MediaType} |
There was a problem hiding this comment.
It is added with the helm chart, but I think it is OK to exist on the default code as well.
@tmshort @thetechnick WDYT?
OchiengEd
force-pushed
the
helm_explorations
branch
from
c08ce64 to
9b366d3
Compare
| switch layer.MediaType { | ||
| case registry.ChartLayerMediaType: | ||
| if err := storeChartLayer(dest, layer); err != nil { | ||
| return err | ||
| } | ||
| default: | ||
| if _, err := archive.Apply(ctx, dest, layer.Reader, applyOpts...); err != nil { | ||
| return fmt.Errorf("error applying layer[%d]: %w", layer.Index, err) | ||
| } |
There was a problem hiding this comment.
Should it not be protected behind the feature flag as well?
There was a problem hiding this comment.
The code will be unreachable as a result of the pullChart() function being wrapped around a feature gate. However, if we need to wrap that code as well, feel tree to let me know
operator-controller/internal/shared/util/image/pull.go
Lines 228 to 232 in 9b366d3
There was a problem hiding this comment.
I believe that all code should be categorised under a flag, allowing us to easily identify the purpose of each specific code for each alpha/beta feature. However, I think we can wait for others' input to see what they think about. My concern is:
What happens if we decide not to use the alpha/beta feature and want to delete it? If we decide not to promote feature A or B. How hard will it be if not all related code is not under the feature flag condition? But others might think that is OK
@perdasilva @tmshort WDYT?
There was a problem hiding this comment.
Similarly to my comment above about moving the feature flag checks to main, should we refactor this in a way that make the cache configurable as to the different layer media types and how they are handled?
There was a problem hiding this comment.
actually - the comment is below =P
| "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" |
There was a problem hiding this comment.
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.
I would be for adding documentation and a demo as a follow up.
OchiengEd
force-pushed
the
helm_explorations
branch
2 times, most recently
from
735a6d9 to
036e4c8
Compare
* added support for deploying OCI helm charts which sits behind the HelmChartSupport feature gate * extend the Cache Store() method to allow storing of Helm charts * inspect chart archive contents * added MediaType to the LayerData struct Signed-off-by: Edmund Ochieng <[email protected]>
OchiengEd
force-pushed
the
helm_explorations
branch
from
036e4c8 to
0dfea34
Compare
| @@ -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.
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?
Description
This pull request aims to add logic to OLM v1 for handling OCI Helm chart support. We expect more work to go into this feature as further discussion on this occurs on issue #962 and the Arbitrary Configuration RFC which may inform how
values.ymlwould be passed to Helm charts.Reviewer Checklist