Skip to content
This repository has been archived by the owner on Aug 12, 2024. It is now read-only.

[Add] Support for other Install strategies #772

Conversation

varshaprasad96
Copy link
Member

This PR removes the requirement that AllNamespace mode should be supported always in a registry+v1 format.

It does so by:

  1. Adding a field to specify watch namespaces in Bundle Template.
  2. While converting from registryV1 to plain bundle, we now generate roles for all specified targetNamespaces which are being watched.

@varshaprasad96 varshaprasad96 requested a review from a team as a code owner December 15, 2023 20:24
Copy link

codecov bot commented Dec 15, 2023

Codecov Report

Attention: 9 lines in your changes are missing coverage. Please review.

Comparison is base (b4e9976) 20.62% compared to head (2a7a6c7) 20.73%.

Files Patch % Lines
internal/convert/registryv1.go 10.00% 8 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #772      +/-   ##
==========================================
+ Coverage   20.62%   20.73%   +0.11%     
==========================================
  Files          14       14              
  Lines        1086     1085       -1     
==========================================
+ Hits          224      225       +1     
+ Misses        812      811       -1     
+ Partials       50       49       -1     

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

@varshaprasad96 varshaprasad96 changed the title [Add] Support for other Install modes [Add] Support for other Install strategies Dec 15, 2023
Copy link
Member

@ncdc ncdc left a comment

Choose a reason for hiding this comment

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

Will you also be adding the annotation part in this PR?

api/v1alpha1/bundle_types.go Outdated Show resolved Hide resolved
internal/convert/registryv1.go Show resolved Hide resolved
This PR removes the requirement that
AllNamespace mode should be supported always
in a registry+v1 format.

It does so by:
1. Adding a field to specify watch namespaces
   in Bundle Template.
2. While converting from registryV1 to plain bundle,
   we now generate roles for all specified targetNamespaces
   which are being watched.

Signed-off-by: Varsha Prasad Narsing <[email protected]>
@@ -189,9 +189,6 @@ func Convert(in RegistryV1, installNamespace string, targetNamespaces []string)
supportedInstallModes.Insert(string(im.Type))
}
}
if !supportedInstallModes.Has(string(v1alpha1.InstallModeTypeAllNamespaces)) {
return nil, fmt.Errorf("AllNamespace install mode must be enabled")
}
if targetNamespaces == nil {
Copy link
Member

Choose a reason for hiding this comment

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

Would you mind changing this to check for len=0 instead please?

Comment on lines +168 to 170
func Simple(in RegistryV1, watchNamespaces []string) (*Plain, error) {
return Convert(in, "", watchNamespaces)
}
Copy link
Member

Choose a reason for hiding this comment

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

I think I'd just drop the Simple function at this point.

Comment on lines +59 to +61
// +kubebuilder:validation:Optional
// watchNamespaces indicates which namespaces the operator should watch.
WatchNamespaces []string `json:"watchNamespaces,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

Hmm. I had imagined that we'd put this on the BundleDeployment, not the Bundle. But the wrinkle with needing to generate extra RBAC during the conversion means this is essential information in that step.

One possible solution here would be to make a registry BundleDeployment provisioner and move the conversion logic there. If we did that, we could probably make the Bundle provisioner super generic and reusable for registry/plain/helm/etc. Basically it would just be a "give me the filesystem with no format-specific validation" provisioner. And then the BD would be the place for registry/plain/helm to have separate provisioners and do whatever specific validation was necessary.

From an API design standpoint, I argue that configuration of the templating of the bundle belongs in the BundleDeployment.

All of this highlights the weird dichotomy between Bundle and BundleDeployment, and I think it's another good reason to move to a single API for "source/template/apply" like the Carvel App API. I think moving toward a super-generic Bundle provisioner gets us more aligned with that concept anyway, so perhaps that would be a good step in that direction?

What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

I missed this was on Bundle and not BundleDeployment. +100 to getting rid of Bundle. @varshaprasad96 if you're around this week and want help, please let me know.

Copy link
Member Author

@varshaprasad96 varshaprasad96 Dec 18, 2023

Choose a reason for hiding this comment

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

@joelanford @ncdc fair. The reason for having this on template, was to be able to pass this to bundle provisioner which handles the conversion. If we move that logic to Bundle, there doesn't seem to be much value in having a separate API.

I think it's another good reason to move to a single API for "source/template/apply" like the Carvel App API

Removing Bundle would change the BundleDeployment API, we would need an alpha2? Nevertheless, I'll get a draft PR ready, and we can discuss the specifics of the API there.

Copy link
Member

Choose a reason for hiding this comment

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

Yes to alpha2

@varshaprasad96
Copy link
Member Author

Closing in favour of #802

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants