-
Notifications
You must be signed in to change notification settings - Fork 36
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
[research] Consider moving CRDs to beta, and making beta "hub" versions #352
Comments
FYI @odubajDT, this sounds like something you might be interested in. |
I would love to do this, but I guess the team needs to decide on the specs of the resources for beta |
Yes, it's not a "right now" issue. I just wanted to you to aware of it. I think once we complete (or get closer to completing) the flagd-kube-proxy, we will have a better candidate for the beta CRD. |
Great, @toddbaert would it be possible to organize a team meeting to align on the specification of the CRDs ? Therefore I can start with this ticket and create a PoC |
My take on this is to wait till we finalize kube-proxy related implementations. We will see more changes with proxy deployment and in my view, it's best to push those changes to alpha version. Once we have the proxy changes and stability on the solution, we can draft the beta version of the API. Timeline wise, this is 1 ~ 2 sprints of waiting |
Consider addressing #433 along with this change |
From the last conversation with @toddbaert here some items that need to be fullfilled about this issue and also results of the research:
To cover the defined items I would propose the following scenario for implementation:
Each of these steps should be a separate ticket if it is not yet. Should we proceed, create a tracking issue with all the tickets linked with exact descriptions what should be done? I would consider it as transparent for the open-source community, but I will leave the decision on the team. If we decide not to create separate tickets, I would highly suggest at least have each of the steps implemented in separate PR. After this is implemented and merged, firstly then we should consider releasing a stable version. I would appreciate feedback on this @Kavindu-Dodan @toddbaert @thisthat @mowies @RealAnna @bacherfl . Any suggestions, objections or opinions are very welcome also from the community! |
Thanks all for the effort 🙌 I have some questions about the points listed by @odubajDT
why a stable release with a beta API version? I would vote for having stable APIs for OFO 1.x
what type of clean up do you envision? 🤔 I would expect to drop any code line that deals with these CRDs |
True, but we actually cannot skip
With this I meant removing the struct functions, for example here https://github.com/open-feature/open-feature-operator/blob/main/apis/core/v1alpha1/featureflagconfiguration_types.go#L111. There is no reason to keep these functions, as they won't be used anywhere. Also we can remove the conversion webhooks between |
Yes. 1.0 is a more distant goal. We should have our eyes on it, but it's not an immediate concern. Completing all this work is necessary but not sufficient for a 1.0.
I think we should do whatever the convention is, as you say. Maybe we can very explicitly mark them as only maintained for historical purposes. |
@odubajDT thank you for the summary I also like to discuss our CRD naming. Right now, our naming of two CRDs is a little confusing
|
Fine by me 👍 But we should keep the names singular, as according to k8s standards, CRD should be named as singular and k8s explicitly adds a plural value [1]. So I would suggest |
a PoC of a working solution is available here: Please note that some of the E2E tests are failing due to the usage of |
I still find SourceConfiguration name a bit redundant 🤔 in the end the CR itself is a configuration, what I want to define as a user is a |
|
I agree more with Anna on the naming. Maybe something like |
The main issue is sharing the same prefix @odubajDT I like the So the current candidates,
|
Let's create a pool, the name for the
Please vote by marking this comment with the emoji, which represents your favorite name |
I'd like to bring a bit more context on how it would feel to use each version to support the voting: SourceConfiguration
SidecarConfiguration
FeatureFlagSource
Source
|
I guess we have a winner, it will be |
I agree with this after learning the background. |
The research as well as the implementation is done, closing this issue |
In an effort move to 1.0, we should consider moving our CRDs to beta to imply stability. Things we should consider:
The text was updated successfully, but these errors were encountered: