I'm concerned about the maintainability of this function because if later a new field is added to metadata or to to namespace.spec, it will be very hard for a PR author to know to also modify this function to add the field. We useSchemaDeclType() conversion for object even though it has managedFields and ownerReferences. Is it really essential that we omit those fields? Could we just call SchemaDeclType() here? If we REALLY don't want those fields, are we going to remove them from object and oldObject and self and oldSelf when they refer to a root object as well? (the latter is a breaking change)

If we decide to omit the fields (after addressing my above concerns), should we instead offer a SchemaDeclType() style function that always omits the fields from root objects (note that the function does take a "isRoot" param).

If use the schemaResolver that the type checker uses, these SSA fields are already omitted.

In this way, the type is built from namespace openAPI definition. The building process does not require networking either but there is a JSON marshall/unmarshall of a small schema object.

Anything we can do here to avoid redefining the schema for namespace (and incurring the maintenance cost of having the schema defined in yet another place) would be really really nice.

I've reconsidered this matter. I think it is not worthwhile to wire in the whole OpenAPI definitions only for one type. I am planning to compromise with a test to ensure this hand-crafted namespace schema matches that of OpenAPI. What do you think?

Let's postponed the check a bit later. The handcrafted type looks consistent with v1.Namespace. We can find a way to sync this later in next release since there is no change of behavior on the user's side.

I've reconsidered this matter. I think it is not worthwhile to wire in the whole OpenAPI definitions only for one type. I am planning to compromise with a test to ensure this hand-crafted namespace schema matches that of OpenAPI. What do you think?

SGTM!