Add logger to actuators

[amy]

This PR partially addresses: #22
Specifically this adds loggers to the actuators.

The pattern used here was inspired by the aws provider. Ex: https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/master/pkg/cloud/aws/actuators/cluster/actuator.go#L41

[amy]

/assign @chuckha

This is a beginning sketch of how we can handle logging for the actuators. Please review and share your thoughts about the general direction.

[chuckha]

few comments

[chuckha]

will need a few updates, but nice job removing the fmt import. that's dope.

[chuckha]

All of the error logs need to include the stack trace.

I think there's probably a better way to do this, maybe a function like:

func (c *Cluster) handleError(err error) error {
// log stacktrace
// return err
}

[neolit123]

/test pull-cluster-api-provider-docker-verify

[amy]

/retest

[k8s-ci-robot]

@amy: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[chuckha]

/ok-to-test

[chuckha]

/retest

[chuckha]

It looks like we're losing the stack traces, is that right? I don't want to give those up, they have been very useful during development

[amy]

Re: stacktrace comments. I think that was a misunderstanding we cleared up?

#27 (comment)

[calebamiles]

@chuckha, @amy what's the status of https://github.com/kubernetes/klog? should we be using that here like k/k?

[ncdc]

I'm in favor of a simplified logging interface, be it go-logr or something similar. But I would probably prefer something other than klog. Maybe zapr, since that's what kubebuilder seems to integrate by default now?

[chuckha]

this pr is focused on plugging logr.Logger through and using a minor shim to keep stack traces around. we can swap out the klogr implementation for zapr or whatever we want later, no matter which one we pick we will be pulling in a dependency so i am not fussed either way.

From what i understand kubebuilder has done a lot of work to make the log implementation pluggable so we don't need to pick zapr because they do.

[chuckha]

lgtm, just missing the license on one file

[chuckha]

/approve

thank you!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amy, chuckha

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [chuckha]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[neolit123]

/lgtm
not a big fan of logr, but +1 on having a logger shim as early as possible!