Rename PetSet to StatefulSet

[janetkuo]

@bryk In k8s 1.5 we're renaming PetSet to StatefulSet. We should do the rename in dashboard too (both frontend and backend).

@kow3ns @foxish @erictune

[bryk]

Yes, we were aware of this.

[kow3ns]

@bryk would you guys like some help on the refactor?

[floreks]

Of course, any help is appreciated. We want to be in sync with k8s releases so it would be great to release dashboard 1.5 at the same time with StatefulSets already.

Thanks for your help!

[rf232]

I don't know too well exactly how go dependencies work, but I tried to do the refactor and I found out that our vendored libraries don't have the StatefulSet changes in kubernetes/kubernetes yet.

Also govendor doesn't tell me I can update those libs (we reference the kubernetes core source by looking at k8s.io/kubernetes)

Does that mean that we need to wait till this refactor is moved to k8s.io repo somehow. And is that linked to actual releases?

[maciaszczykm]

@rf232 Basically our version of core code is inside our repository, so we have to update it to get newest changes. Kubernetes v1.5.0-alpha.2 release has them, so we can make our alpha by updating dependencies and performing changes in code (switching from PetSets to StatefulSets) in one pull request. If we would make it, then our next release should be tagged with 1.5 alpha too, because it will be incompatible with <1.5 versions of Kubernetes.

[rf232]

hmm, updating dependencies to the versions from github master is /far/ from trivial, so if someone can help me/do that I would be very grateful :)

[erictune]

@caesarxuchao or @mbohlool could one of you take a look at how Dashboard is vendoring its libraries and suggest any best practices?

It looks like the only client they import directly from their source is k8s.io/kubernetes/pkg/client/unversioned

[floreks]

Maybe we should switch to client-go and clean up our kubernetes deps? We're mostly using old client Interface that is no longer available in newer version of k8s and a bit of kubectl code I think.

I can take care of that. It will take some time to refactor everything though.

[caesarxuchao]

client/unversioned is already removed from the main repo. I'll also recommend using client-go. However, there will be some frictions migrating to client-go. If dashboard is looking for a quick solution, the easiest thing to do is vendor the internalclient.

One potential blocker for adopting client-go is that client-go defines its own API types, (e.g., client-go/api.Pod), though their definitions are exactly the same as the types defined in kubernetes main repo. It means dashboard needs to convert the types before using utility functions defined in the kubernetes main repo, e.g., deploymentutil. We plan to let client-go share the same types with the main repo, but that's going to take O(weeks) to happen.

[floreks]

@caesarxuchao It helps a lot, thanks! I'll try client-go first and if it's too much work then use internalclient for now and keep working on adapting our code to use client-go.

[floreks]

I do have one concern though. If we want to rename PetSet -> StatefulSet then we have to use client-go@v2.0.0-alpha.0. It is stable enough to use? How compatibility matrix looks like for this version?

@caesarxuchao @rf232

[caesarxuchao]

Don't use v2.0.0-alpha.0. It still has apps/v1alpha1, which had graduated to v1beta1 in master.

Client code for apps/v1beta1 will be published to client-go today, I can cut v2.0.0-alpha.1 after that. This version will be quite stable.

[floreks]

I've used internalclient for now because we are also using some utility functions from cmdutil and deploymentutil. Fetching these dependencies downloads most of k8s core repo anyway so we can stick with that for now and wait for better compatibility with client-go.

[caesarxuchao]

Sounds good. FYI, the signature of those utility functions will be changed soon (kubernetes/kubernetes#35159 (comment)), so you might have to go through the refactor once more.