-
Notifications
You must be signed in to change notification settings - Fork 151
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
feat: introduces features fluent interface #668
feat: introduces features fluent interface #668
Conversation
Extracts the fluent interface for Features from PR opendatahub-io#605. This allows other components to configure cluster resources using this interface before the original PR gets merged. No changes to the reconcile logic have been introduced.
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.
This file exists solely to make //go:embed
happy. As #605 is using templates I thought I would make this part available as the "core" functionality so it's easier for others to use if necessary. But can be deleted if e.g. @israel-hdez does not need it yet.
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.
Most likely, I'll need the folder.
I've seen other projects (which I no longer remember), use a .keep
empty file to force git to keep the folder. It is just a suggestion. I'm file keeping this unused template with the same goal.
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 tried with .gitkeep
but //go:embed
fails if you have only such files. Thus the template. I should have mention it earlier :)
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 only quickly scanned the code, since I've already read the code at #605.
It seems to contain the baseline that we can use for minimal OSSM and Serverles installation, as prereqs for KServe.
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.
Most likely, I'll need the folder.
I've seen other projects (which I no longer remember), use a .keep
empty file to force git to keep the folder. It is just a suggestion. I'm file keeping this unused template with the same goal.
pkg/feature/feature.go
Outdated
return nil | ||
} | ||
|
||
func convertToRFC1123Subdomain(input string) string { |
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.
not sure i understand why need this
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.
Each feature is named using just a string, see here for example.
In order to have this in objectMeta.Name
we have to convert it to follow this RFC (it simply replaces non-alphanumeric characters with a hyphen), otherwise, it will error complaining about wrong naming.
Thanks for bringing it up, as I realized this implementation doesn't really ensure all of it. It should make sure that the name:
- contain no more than 63 characters
- contain only lowercase alphanumeric characters, '-' or '.'
- start with an alphanumeric character
- end with an alphanumeric character
Using the example above this object will be named "opendatahub-create-service-mesh-routing-resources-for-dashboard" if opendatahub
is app namespace. This way it's easy to see which tracker object is used for where and by which feature.
If you agree this is the right naming approach I will enhance the logic to fulfill all the points above.
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.
Reworked in 3f5efbd
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.
ok, i see.
guess the string is just something meaningful to represent the component and servicemesh?
if the limitation of 63 chars from k8s will be applied, just thinking to have something can be useful for ODH (default namespace opendatahub" as 10 chars) and downstream (default namespace 21 chars)
create-service-mesh-routing-resources-for-dashboard (44 chars) will work in ODH, but not downstream
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.
guess the string is just something meaningful to represent the component and servicemesh?
well... it's the name which should somewhat reveal it's reason to exist :) we might want to extend the .Spec
to have .AppNamespace
instead but I'm not quite sure.
create-service-mesh-routing-resources-for-dashboard (44 chars) will work in ODH, but not downstream
it will be truncated to 63 chars, I guess that is fine at this point. WDYT?
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.
yeah, i saw the new test cases you added there. just need to be mindful when we set the value later on.
we should make it something like "dashboard-create-service-mesh-routing-resources", so the important part "dashboard" wont be truncated
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.
That's really a great point! That got me thinking that maybe .Spec
should have extra fields such as Component
, Namespace
and thus be more useful. I will think a bit more and provide improvements as a separate chunk if that works for you.
/test opendatahub-operator-e2e |
- adds additional conditions - adds tests
it is a leftover from KfDef plugin code
should update https://github.com/maistra/opendatahub-operator/blob/features_dsl/Makefile#L66 to new version? |
It's the same in the target branch Line 66 in c9aa358
It might be that my local
but in my case it returns:
|
so, we still want to use 1.24.1, right? if so, we will not need the changes e.g bundle.Dockerfile |
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.
/lgtm
@zdtsw I will address both in the follow-up PR. |
/lgtm add approval based on new commit is after rebase from incubation branch |
/approved |
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: zdtsw 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 |
ref #666 |
Extracts the fluent interface for Features from PR opendatahub-io#605. This allows other components to configure cluster resources using this approach before the original PR gets merged. (cherry picked from commit adb6658)
Description
Extracts the fluent interface for Features from PR #605. This allows other components to configure cluster resources using this apprach before the original PR gets merged.
No changes to the reconcile logic have been introduced.
How Has This Been Tested?
Merge criteria: