Fixing schema definitions bugs

[MbolotSuse]

Overview

This is related to rancher/rancher#45158, and resolves two of the issues identified in the issue summary. Specifically:

• There are some resources (e.x. generateKubeconfigOutput) which are added as custom schemas - these don't represent real k8s resources. However, since they are still top-level schemas, they need definitions.
• Some resources (e.x. monitoring.coreos.com.alertmanagerconfig from the rancher-monitoring chart) are not in the preferred version of the group, but are in some version of the group. monitoring.coreos.com.alertmanagerconfig, for example, appears in the v1alpha1 version, but not in the v1 version which is the preferred version of the group.

This does not address the third issue - this should be addressed by the work on rancher/rancher#45157, since these resources represent CRDs that have no typing information in kubernetes.

Solution Detail

• We now add the baseSchema configured for the server to the SchemaDefinitionHandler. This contains the configured, built-in schemas (such as generateKubeconfigOutput).
• When processing a request, if the schema is a baseSchema (as determined by trying to lookup the schema from the baseSchemas), then we extract the definition from the schema's resourceFields rather than from the openapi models.
  • In these cases, we still extract the definition from the schema on the request rather than the baseSchema (which is just used to determine if this resource is a base schema). This is done in case the schema has been transformed for this user - baseSchemas are setup-wide, where the schemas on the request are specific to the user.
  • This approach requires that the schema still has the resource fields set. For this reason, these resources still have resourceFileds in /v1/schemas. Since the impact of this is relatively low, this wasn't resolved in this PR.
  • This transformation is done at the time the schema is called, rather than at refresh time, so there's some overhead in processing these requests. However, that overhead is comparable (and probably lower) to what we do in recursively gathering the schemas on a proper k8s resource.
  • This approach requires that we parse the type field on the resource fields for cases of complex types like map[string]. This is done using an import from wrangler, which is used for similar purposes in rancher
• The logic for preferred group/version was tweaked slightly.
  • In the current/master state, resources are only added when they are in the preferred version for a group.
  • In the new state, we add a resource if one of the two is true:
    • The resource is in the preferred version for a group
    • We don't have a model for that schema yet
  • This ensures that if we have a preferred version of a resource, that version is used (since it is always added, it will override any other non-preferred version). However, if none exists, we still have a version of the resource, so we can still get a legitimate definition.

Notes

Tests were added for the above cases to maintain coverage.

[tomleb]

Overall looks good to me, 1 question and 1 suggestion

[nflynt]

👍