Refactor to simplify the hard-traveled path of the KubeletConfiguration object

[mtaufen]

There are two main goals of this PR:

• Make NewMainKubelet take KubeletConfiguration and KubeletDeps as its only arguments.
• Finally eliminate the legacy KubeletConfig type.

Why am I doing this?

Long story short, I started adding an endpoint to the Kubelet to display the current config that the Kubelet was running with, and I realized a few things:

• There were so many transformations to the configuration, in so many different places, before it was used that I wasn't confident the values initially passed in on the KubeletConfiguration would be the correct values to report by the time someone used the endpoint to check on them.
• Trying to reconstruct a KubeletConfiguration object from a mix of the Kubelet object and the legacy KubeletConfig object would just add to the mess (not to mention maintenance burden), and it would be much easier if we passed the KubeletConfiguration all the way down to where we construct the Kubelet object, and then just store a reference to the KubeletConfiguration object on the Kubelet for later retrieval.
• My hope is that by eliminating unnecessary internal transformations to the config information, and by consolidating the remaining ones in a single place (NewMainKubelet), we can have a much clearer understanding of what happens to the config before it makes it to the Kubelet object, and also a better ability to report up-to-date information on the status of the Kubelet.

So I started cleaning things up :-).

Discussion points

It was relatively simple to get NewMainKubelet to just take the legacy KubeletConfig as its only argument, because most of its arguments were just passing through KubeletConfig fields or passing information that was generated solely from KubeletConfig fields.

Completely eliminating the legacy KubeletConfig type has been more difficult, because the fields of the KubeletConfiguration do not have a one-to-one relationship with the fields of the KubeletConfig. While I was able to eliminate many of the KubeletConfig fields, I'm starting to get into the nontrivial stuff and I'd like to get a discussion started on what should happen with the remaining fields (pending cherry-picking notwithstanding).

On my kconf-refactor branch, the legacy KubeletConfig object is down to the following 27 fields (from the initial 93). I'd really appreciate any guidance people have on what should happen with these fields.

type KubeletConfig struct {
    Auth                    server.AuthInterface
    AutoDetectCloudProvider bool
    Builder                 KubeletBuilder
    CAdvisorInterface       cadvisor.Interface
    Cloud                   cloudprovider.Interface
    ContainerManager        cm.ContainerManager
    DockerClient            dockertools.DockerInterface
    EventClient             *clientset.Clientset
    Hostname                string
    HostNetworkSources      []string
    HostPIDSources          []string
    HostIPCSources          []string
    KubeClient              *clientset.Clientset
    Mounter                 mount.Interface
    NetworkPlugins          []network.NetworkPlugin
    NodeName                string
    OOMAdjuster             *oom.OOMAdjuster
    OSInterface             kubecontainer.OSInterface
    PodConfig               *config.PodConfig
    Recorder                record.EventRecorder
    Reservation             kubetypes.Reservation
    TLSOptions              *server.TLSOptions
    Writer                  kubeio.Writer
    VolumePlugins           []volume.VolumePlugin
    EvictionConfig          eviction.Config
    ContainerRuntimeOptions []kubecontainer.Option
    Options                 []Option
}

The patterns I've seen so far with respect to eliminating KubeletConfig fields may be of some help:

• Some fields could just be eliminated, because they were either the same on KubeletConfiguration or just a typecast away from being the same.
• Some fields from KubeletConfiguration just ended up in substructures of KubeletConfig; it was easy to just remove those substructure fields from KubeletConfig and construct them using local vars in NewMainKubelet instead.
• Some fields, e.g. Runonce, were able to move into the KubeletConfiguration.

P.S. Part of the way I'm making the transition is by adding an extra KubeletConfiguration argument to functions that originally took a KubeletConfig, and field-by-field, switching those functions over to using information from the KubeletConfiguration. Once the KubeletConfig is gone, I'll remove the KubeletConfig argument, and the transition will be complete.

Final note:
Please try to keep in mind that this is not a general Kubelet cleanup effort, it is just me cleaning things up that are directly in the path of what I'm trying to do. Let's keep this focused on cleanup related to the path that config takes on it's way to the Kubelet.

Release note:

Removed Flags
- Removes the --auth-path flag. This has been deprecated in favor of --kubeconfig for two releases.

---

This change is

[mtaufen]

cc @vishh @mikedanese @timstclair

[philips]

cc @aaronlevy @derekparker @pbx0

[philips]

This is part of #27980.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

[k8s-bot]

GCE e2e build/test passed for commit 652024f1912559b207abcb6997edbc2e25162ae4.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[mtaufen]

@k8s-bot unit test this please

[k8s-github-robot]

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

[k8s-bot]

GCE e2e build/test passed for commit 652024f1912559b207abcb6997edbc2e25162ae4.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

[k8s-bot]

GCE e2e build/test passed for commit 652024f1912559b207abcb6997edbc2e25162ae4.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

@mtaufen PR needs rebase

[mtaufen]

@vishh Bumping priority due to frequent rebases.

[k8s-github-robot]

/lgtm cancel //PR changed after LGTM, removing LGTM. @mtaufen @vishh

[vishh]

Ack. There are PRs that are waiting to be rebased on top of this. So bumping priority makes sense.

[k8s-bot]

GCE e2e build/test passed for commit 7ae1458.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

[k8s-bot]

GCE e2e build/test passed for commit 7ae1458.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

Automatic merge from submit-queue

[vishh]

Finally!!!

On Thu, Aug 25, 2016 at 1:18 PM, Kubernetes Bot [email protected]
wrote:

GCE e2e build/test passed for commit 7ae1458
7ae1458
.

• Test Results
  https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/pr-logs/pull/29216/kubernetes-pull-build-test-e2e-gce/56033
• Build Log
  http://pr-test.k8s.io/29216/kubernetes-pull-build-test-e2e-gce/56033/build-log.txt
• Test Artifacts
  https://console.developers.google.com/storage/browser/kubernetes-jenkins/pr-logs/pull/29216/kubernetes-pull-build-test-e2e-gce/56033/artifacts/
• Internal Jenkins Results
  http://goto.google.com/prkubekins/job/kubernetes-pull-build-test-e2e-gce//56033

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#29216 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGvIKIE665GoMYcBPx0N7b5YW2Wn8gCZks5qjfiDgaJpZM4JP-G6
.