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

feat: introduces features fluent interface #668

Merged
merged 12 commits into from
Nov 1, 2023

Conversation

bartoszmajsak
Copy link
Contributor

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:

  • The commits are squashed in a cohesive manner and have meaningful messages.
  • Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
  • The developer has manually tested the changes and verified that the changes work

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.
Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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 :)

Copy link
Contributor

@israel-hdez israel-hdez left a 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.

components/dashboard/dashboard.go Outdated Show resolved Hide resolved
components/workbenches/workbenches.go Outdated Show resolved Hide resolved
Copy link
Contributor

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/resources.go Show resolved Hide resolved
pkg/feature/raw_resources.go Outdated Show resolved Hide resolved
return nil
}

func convertToRFC1123Subdomain(input string) string {
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reworked in 3f5efbd

Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

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

Copy link
Contributor Author

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.

@VaishnaviHire
Copy link
Member

/test opendatahub-operator-e2e

@zdtsw
Copy link
Member

zdtsw commented Oct 31, 2023

should update https://github.com/maistra/opendatahub-operator/blob/features_dsl/Makefile#L66 to new version?

@bartoszmajsak
Copy link
Contributor Author

should update maistra/opendatahub-operator@features_dsl/Makefile#L66 to new version?

It's the same in the target branch

OPERATOR_SDK_VERSION ?= v1.24.1

It might be that my local operator-sdk from other project took precedence here, as Makefile does this:

OPERATOR_SDK = $(shell which operator-sdk)

but in my case it returns:

❯ which operator-sdk
~/.asdf/shims/operator-sdk

@zdtsw
Copy link
Member

zdtsw commented Nov 1, 2023

should update maistra/opendatahub-operator@features_dsl/Makefile#L66 to new version?

It's the same in the target branch

OPERATOR_SDK_VERSION ?= v1.24.1

It might be that my local operator-sdk from other project took precedence here, as Makefile does this:

OPERATOR_SDK = $(shell which operator-sdk)

but in my case it returns:

❯ which operator-sdk
~/.asdf/shims/operator-sdk

so, we still want to use 1.24.1, right? if so, we will not need the changes e.g bundle.Dockerfile

Copy link
Member

@zdtsw zdtsw left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm label Nov 1, 2023
@zdtsw
Copy link
Member

zdtsw commented Nov 1, 2023

tested in cluster with the build. components are working.
Screenshot from 2023-11-01 08-42-33

@bartoszmajsak
Copy link
Contributor Author

should update maistra/opendatahub-operator@features_dsl/Makefile#L66 to new version?

It's the same in the target branch

OPERATOR_SDK_VERSION ?= v1.24.1

It might be that my local operator-sdk from other project took precedence here, as Makefile does this:

OPERATOR_SDK = $(shell which operator-sdk)

but in my case it returns:

❯ which operator-sdk
~/.asdf/shims/operator-sdk

so, we still want to use 1.24.1, right? if so, we will not need the changes e.g bundle.Dockerfile

@zdtsw I will address both in the follow-up PR.

@openshift-ci openshift-ci bot removed the lgtm label Nov 1, 2023
@zdtsw
Copy link
Member

zdtsw commented Nov 1, 2023

/lgtm

add approval based on new commit is after rebase from incubation branch

@openshift-ci openshift-ci bot added the lgtm label Nov 1, 2023
@zdtsw
Copy link
Member

zdtsw commented Nov 1, 2023

/approved

@zdtsw zdtsw added the approved label Nov 1, 2023
Copy link

openshift-ci bot commented Nov 1, 2023

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@zdtsw
Copy link
Member

zdtsw commented Nov 3, 2023

ref #666

VaishnaviHire pushed a commit to VaishnaviHire/opendatahub-operator that referenced this pull request Nov 15, 2023
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants