Switch to componentconfig approach #1
Conversation
| } | ||
|
|
||
| // TODO(componentconfig-q): Should we deal with v1alpha1 or unversioned when we own the API? | ||
| // (I guess the same question with our User objects) |
There was a problem hiding this comment.
I think of conversion this way:
The apiserver needs to canonicalize the resource for storage purposes, and convert to/from that representation for the client. Today, we do that conversion by using the internal (unversioned) representation as the hub, but we've talked about eliminating the internal rep for a long time (kubernetes/kubernetes#8190 (comment)).
Originally, both defaulting and validation were originally unversioned. Now defaulting is versioned but validation is not. We need to change validation to be versioned (kubernetes/kubernetes#8550). At that point, most of the apiserver's logic would be on the versioned reps, though admission control is TBD.
All other components of the system are clients of the API. (Let's ignore static pods for now.) Ideally, they'd just use the versioned reps, like regular clients (kubernetes/kubernetes#20193). That changes how they'd transition to a new API version, but I think that's a good thing.
So what should components do with versioned configuration? IMO, they should convert it to the canonical versioned representation.
|
|
||
| // GroupName is the group name use in this package | ||
| // TODO(componentconfig-q): does the componentconfig live in the GroupName? | ||
| // Should it actually just be in the same go packages? |
There was a problem hiding this comment.
I wouldn't make it the same API group. I don't think I'd make it the same go package, either, but I haven't thought about it too much. The actual API is the user interface and is exposed as a REST API, whereas the config "API" is the management interface and is consumed via file, from a URL, from the apiserver, etc.
|
|
||
| import metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" | ||
|
|
||
| // TODO(componentconfig-q): Is the Auth in AuthConfiguration redundant? |
There was a problem hiding this comment.
If Auth is in the name of the API group, it doesn't strictly need to be in the name of the Kind, though we don't currently have good mechanisms to disambiguate non-unique kinds, and "Configuration" would be generic enough to not be very useful.
I'd like components to support consuming multiple config Kinds, perhaps from multiple files/URLs/whatever. In that case, the types could have more specific names, like ProviderList.
| configMap, err := k8sClient.CoreV1().ConfigMaps(namespace).Get(name, metav1.GetOptions{}) | ||
| if err != nil { | ||
| if apierrors.IsNotFound(err) { | ||
| // TODO(componentconfig-q): Create? Probably not as it would interfere with a manager (race condition) |
There was a problem hiding this comment.
I wouldn't create the ConfigMap here, no.
I have marked some questions I am (very) unsure about wrt componentconfig - search for
componentconfig-q