Rename the project to kubernetes-framework

[iocanel]

The name kubernetes-client does no justice to the project, which is much more than that. kubernetes-framework is much more descriptive.

[rohanKanojia]

@oscerd @gastaldi @rhuss @jstrachan @jimmidyson @traviswinter @jstrachan @carlossg @lordofthejars @jglick @piyush-garg @hrishin @ljnelson @davsclaus

Thoughts??

[oscerd]

I think it makes sense

[gastaldi]

LGTM. Will the groupId change too?

[gastaldi]

Since the name will change, It would be cool if the major and minor versions matched the Kubernetes API versions too.

[davsclaus]

Yeah sure, however a little blurb why its more than a client would be nice to know, what makes it stand out as a framework now? And are we also taking about moving it to another organization than fabric8 ?

[iocanel]

The things that make it something more than a client is that it provides:

1. A model that allows advanced handling and manipulations.
2. A rich DSL.
3. Extension Hooks (it acts as a base on which you can easily built your own extension).
4. A kubernetes/openshift mock server for testing.
5. Tons of utilities embeded in the client side.

My main incentives for changing the name are:

1. I often try to push for more resources, on the project and I get the feel that the scope of the project isn't well understood.
2. There is a naming clash with the official kubernetes-client. (https://github.com/kubernetes-client/java)

Now, I haven't considered groupId change, org change, or anything. My proposal had more to do with renaming the repository and changing the way we commicate the project. But I am open to discussion.

@davsclaus @gastaldi, makes sense?

[davsclaus]

Thanks for the explanation. Yes it makes sense

[gastaldi]

@iocanel yes, that makes sense to me too

[traviswinter]

@iocanel - Agreed, its much larger then just the client. But as someone already mentioned, this would separate this project from the official Kubernetes client naming strategy which could make things a little simpler :)

[rhuss]

@iocanel When renaming, can we move the orga/groupId, too ?

For fmp and dmp we are considering to move away from fabric8, so this would be a good occassion for the kubernetes-client, too.

[rhuss]

LGTM. Will the groupId change too?

Yes, I would recommend this as fabric8 turns out to be kind of a burned name (as least according to my latest survey). For fmp we are just validating the name, and try to get approval by internal authorities for the name change. The renaming/rebranding is quite close. // @lordofthejars @rohanKanojia @dev-gaur

[rhuss]

Now, I haven't considered groupId change, org change, or anything. My proposal had more to do with renaming the repository and changing the way we commicate the project. But I am open to discussion.

would be really awesome if we could make the name and orga change in one go

[iocanel]

@rhuss: I think that everyone agrees that fabric8 has been overused.

Still, this needs some discussion, as it can easily back-fire.

[jglick]

No opinion. I have been moving to kubernetes-client/java.

[rohanKanojia]

@jglick : Why are you moving to kubernetes-client/java? Just because it's official? Or do you think it's superior in terms of features/extensibility?

[gastaldi]

@jglick I've seen the examples in https://github.com/kubernetes-client/java#example and the syntax is kinda confusing compared to the DSL/fluent approach that fabric8/kubernetes-client offers. I mean, there are so many nulls in that method that I have no idea what they mean :smile:

[jglick]

@rohanKanojia @gastaldi yes kubernetes-client/java is not pretty from a Java API perspective, and it has its own flaws such as https://github.com/kubernetes-client/java/issues/86, but so far it has suited my purposes better because:

• kubernetes-client/java feels much closer to the underlying REST API, and better aligned with the dominant Golang client.
• When working with CRs, I prefer direct access to the JSON structure (as List / Map / String / primitive wrapper). If and when I want generated structs I can do that myself.
• I was unable to get watches working on my CRs using fabric8io/kubernetes-client; it worked on the first try using kubernetes-client/java. Something to do with the HTTP library.
• https://github.com/fabric8io/kubernetes-client/issues/931#issuecomment-462968162 was irritating, especially as it seems like something introduced for OpenShift, which I do not care about.
• https://github.com/fabric8io/kubernetes-client/issues/1153#issuecomment-462933085 felt like a fatal design flaw. Again this is coming from layers of behavior added on top of the REST API which I did not want or need.

[rohanKanojia]

Hmm, we're going to provide better custom resource support soon in coming 1-2 sprints. Regarding your other issues, I would check if we can get them fixed. Sad to see you moving away, though.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[manusa]

This issue is quite old and we've got the required feedback (also from other means of communication), I'm closing it to avoid more noise.

In summary, I think that everyone agrees that a rename makes sense but it brings a set of challenges (Maven GAV coordinates migration, community awareness, and so on). We'll probably need a more complex branding (or rebranding) strategy and a cost-effort-benefit analysis.