-
Notifications
You must be signed in to change notification settings - Fork 859
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
Is clusterresourcebinding.name suitable by kind and name #3627
Comments
Yes, This is a known issue. refer to #2969 |
Hi @weilaaa glad to see you are back. |
I read the pr #2969 and all guys comments , IMHO, I don't like RB name with two format exist, the one is |
I ask is there a way to migrate the existing RB data to the new RB named by For example, we clone the corresponding new RB based on the existing RB, and mark the existing RB as deprecated. At this time, the newly added RB will use the new |
Yes, this is also the thing that concerns me the most. I expect a solution that could transform the legacy RB without perception.
Sounds good to me. Speaking of the naming rule of RB, the naming of "Work" also has similar issues. I analyzed the issue and draft some ideas at this document, you can take a look. This is a very challenging task, and now is also a very good time to solve this problem(Now is the beginning of the v1.7 version cycle.) I'll appreciate it if you want to lead the effort. |
Thanks for the chance. I'll do some investigation first to check out the impact and possible solutions. |
I'm trying to figure out which PR/Issue should be included in the coming v1.7 release which is planned at the end of this month. FYI, We are working on this, the relevant topic was talked at the community meeting, and see #4000 for the progress. |
I have two different resources, the Kind is the same, but Group and Version are not. Those as bellow:
Now, I noticed clusterresourcebinding.name is generated by kind and name which means for
clusters.cluster.example1.com/v1
andclusters.cluster.example2.com/v1beta1
, the name of their clusterresourcebinding is the same, both are cluster.a-cluster. This seems to be problematic.The text was updated successfully, but these errors were encountered: