munnerz

API structure comments:

- constants package is an implicit part of our API, whether we want it to be or not
- right now, there is an undisclosed dependency between v1alpha{2,3} + internal + constants
- therefore, each of v1alpha2 & 3 should have their own copies of each node role type for example (to allow for migrations in future)
- has a big effect on kind as a library. Should consumers depend on the internal type? Or the external types?

- we don't provide any guarantees on the stability of the *internal type*. It is used simply as a base for conversion
	- I am not sure what kubeadm's strategy for this is, however I suspect that there is not a particular good one just yet
	- external types are *designed* to be stable and consumed by users, be that via CLI or library

munnerz

  
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: nvidia-device-plugin-daemonset
spec:
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:

munnerz

func objectNTimes(t *testing.T, fuzzer *gofuzz.Fuzzer, obj runtime.Object, schema *structuralschema.Structural, iterations int) {
	t.Logf("Running CRD schema pruning fuzz test for object %v", obj.GetObjectKind())
	for i := 0; i < iterations; i++ {
		fuzzed := obj.DeepCopyObject()
		// fuzz *before* converting to unstructured, so we get typed fuzzing
		fuzzer.Fuzz(fuzzed)
		unstructuredFuzzed, err := runtime.DefaultUnstructuredConverter.ToUnstructured(fuzzed)
		if err != nil {
			t.Fatalf("Failed to convert type to `runtime.Unstructured`: %v", err)
			return