Skip to content
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

Defaulting functions do not get called #1038

Closed
baichinger opened this issue Jan 31, 2019 · 8 comments · Fixed by #1050
Closed

Defaulting functions do not get called #1038

baichinger opened this issue Jan 31, 2019 · 8 comments · Fixed by #1050
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@baichinger
Copy link

Bug Report

What did you do?
The generated defaulting functions for the CRD do not get called. Code generation was done via

./vendor/k8s.io/code-generator/generate-internal-groups.sh defaulter github.com/Dynatrace/dynatrace-oneagent-operator/pkg/generated github.com/Dynatrace/dynatrace-oneagent-operator/pkg/apis
 github.com/Dynatrace/dynatrace-oneagent-operator/pkg/apis dynatrace:v1alpha1

RegisterDefaults gets invoked during startup. The registered function SetObjectDefaults_OneAgent does not.

What did you expect to see?
Defaulting function SetObjectDefaults_OneAgent gets called.

What did you see instead? Under which circumstances?
Functions do not get called. This causes a panic later on during reconciliation as fields are not setup as expected.

Environment

  • operator-sdk version:
    v0.4.0

  • Kubernetes version information:
    v1.9.11, v1.13.1

  • Kubernetes cluster kind:
    kubeadm

  • Are you writing your operator in ansible, helm, or go?
    Golang

Additional context
Defaulters did work in previous version of operator-sdk (v0.0.5).

@AlexNPavel AlexNPavel added the kind/bug Categorizes issue or PR as related to a bug. label Feb 1, 2019
@theishshah theishshah self-assigned this Feb 1, 2019
@theishshah
Copy link
Member

This should fix the issue, please re-open if not.

@baichinger
Copy link
Author

The actual problem is not the missing defaulter functions generated. Already did this manually. The problem is that those functions don't get called by the client. The current workaround is to call them explicitly: r.schema.Default(instance)

https://github.com/Dynatrace/dynatrace-oneagent-operator/blob/defaulters/pkg/controller/oneagent/oneagent_controller.go#L108

Is this the way it is supposed to be used?

@AlexNPavel
Copy link
Contributor

@baichinger Hello. I've looked into this and I think I found what might be causing the issues. I found some examples of defaulters here: https://github.com/kubernetes/gengo/tree/master/examples/defaulter-gen/_output_tests

All of the projects that have defaulters include this function in their defaults.go file:

func addDefaultingFuncs(scheme *runtime.Scheme) error {
	return RegisterDefaults(scheme)
}

I imported your project, added that function to your v1alpha1 package's default.go file, and then ran operator-sdk generate k8s. That generated a new zz_generated.defaults.go file. I don't know how to test this, but try this out and see if that fixes the problem.

@baichinger
Copy link
Author

It does not make any difference if the functions gets registered either by RegisterDefaults or by addDefaultingFuncs. In either way the functions get registered. The problem is that those functions don't get called. IMO the client github.com/kubernetes-sigs/controller-runtime/pkg/client is in charge of calling https://github.com/kubernetes/apimachinery/blob/master/pkg/runtime/scheme.go#L389

@AlexNPavel AlexNPavel reopened this Feb 5, 2019
@hasbro17
Copy link
Contributor

hasbro17 commented Feb 6, 2019

@baichinger Just weighing in on this, I think the correct behavior for the controller-runtime client is to return exactly what is there on the server, without adding defaults to the CR.
I don't know if that will be changing anytime soon so you might have to explicitly call the Defaulting function on the object yourself for now.

The recommended way to default CRDs is via mutating admission webhooks.

The controller-runtime has APIs to help setup admission webhooks so I would defer to that for now.
https://github.com/kubernetes-sigs/controller-runtime/blob/master/example/mutatingwebhook.go
https://godoc.org/github.com/kubernetes-sigs/controller-runtime/pkg#hdr-Webhook
https://godoc.org/github.com/kubernetes-sigs/controller-runtime/pkg/webhook

We don't have a workflow for webhooks in the SDK right now but we'll most likely utilize the same APIs to help users setup webhooks for defaulting.

@theishshah @AlexNPavel With that being said I don't see a use case for running the defaulter-gen in the SDK so I think we might need to revert #1050

Related: #269

@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 10, 2019
@baichinger
Copy link
Author

/close

@openshift-ci-robot
Copy link

@baichinger: Closing this issue.

In response to this:

/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants