Fix ConvertToVersion to prefer object's GVK field over first registered kind - #135537

…st GVK

This commit refactors the apiserver REST handlers to use typed objects
(appsv1alpha1.Application) instead of unstructured.Unstructured, eliminating
the need for runtime conversions and simplifying the codebase.

Additionally, it fixes an issue where UnstructuredList objects were using
the first registered kind from typeToGVK instead of the kind from the
object's field when multiple kinds are registered with the same Go type.

This is a more comprehensive fix for the problem addressed in
#1630, which was reverted in
#1677.

The fix includes the upstream fix from kubernetes/kubernetes#135537,
which enables short-circuit path for UnstructuredList similar to regular
Unstructured objects, using GVK from the object field instead of
typeToGVK.

Changes:
- Refactored rest.go handlers to use typed Application objects
- Removed unstructured.Unstructured conversions
- Fixed UnstructuredList GVK handling
- Updated dependencies in go.mod/go.sum
- Added e2e test for OpenAPI validation
- Updated Dockerfile

Signed-off-by: Andrei Kvapil <[email protected]>

…st GVK

This commit refactors the apiserver REST handlers to use typed objects
(appsv1alpha1.Application) instead of unstructured.Unstructured, eliminating
the need for runtime conversions and simplifying the codebase.

Additionally, it fixes an issue where UnstructuredList objects were using
the first registered kind from typeToGVK instead of the kind from the
object's field when multiple kinds are registered with the same Go type.

This is a more comprehensive fix for the problem addressed in
#1630, which was reverted in
#1677.

The fix includes the upstream fix from kubernetes/kubernetes#135537,
which enables short-circuit path for UnstructuredList similar to regular
Unstructured objects, using GVK from the object field instead of
typeToGVK.

Changes:
- Refactored rest.go handlers to use typed Application objects
- Removed unstructured.Unstructured conversions
- Fixed UnstructuredList GVK handling
- Updated dependencies in go.mod/go.sum
- Added e2e test for OpenAPI validation
- Updated Dockerfile

Signed-off-by: Andrei Kvapil <[email protected]>

…st GVK

This commit refactors the apiserver REST handlers to use typed objects
(appsv1alpha1.Application) instead of unstructured.Unstructured, eliminating
the need for runtime conversions and simplifying the codebase.

Additionally, it fixes an issue where UnstructuredList objects were using
the first registered kind from typeToGVK instead of the kind from the
object's field when multiple kinds are registered with the same Go type.

This is a more comprehensive fix for the problem addressed in
#1630, which was reverted in
#1677.

The fix includes the upstream fix from kubernetes/kubernetes#135537,
which enables short-circuit path for UnstructuredList similar to regular
Unstructured objects, using GVK from the object field instead of
typeToGVK.

Changes:
- Refactored rest.go handlers to use typed Application objects
- Removed unstructured.Unstructured conversions
- Fixed UnstructuredList GVK handling
- Updated dependencies in go.mod/go.sum
- Added e2e test for OpenAPI validation
- Updated Dockerfile

Signed-off-by: Andrei Kvapil <[email protected]>

…st GVK

This commit refactors the apiserver REST handlers to use typed objects
(appsv1alpha1.Application) instead of unstructured.Unstructured, eliminating
the need for runtime conversions and simplifying the codebase.

Additionally, it fixes an issue where UnstructuredList objects were using
the first registered kind from typeToGVK instead of the kind from the
object's field when multiple kinds are registered with the same Go type.

This is a more comprehensive fix for the problem addressed in
#1630, which was reverted in
#1677.

The fix includes the upstream fix from kubernetes/kubernetes#135537,
which enables short-circuit path for UnstructuredList similar to regular
Unstructured objects, using GVK from the object field instead of
typeToGVK.

Changes:
- Refactored rest.go handlers to use typed Application objects
- Removed unstructured.Unstructured conversions
- Fixed UnstructuredList GVK handling
- Updated dependencies in go.mod/go.sum
- Added e2e test for OpenAPI validation
- Updated Dockerfile

Signed-off-by: Andrei Kvapil <[email protected]>

…3784)

## What this PR does

Brings `GOVERNANCE.md` in line with the organisation it describes: what
the project governs, and what it ships but does not.

### Sub-projects

The `Code Repositories` list named seven repositories and was wrong in
both directions. Five of the six sub-projects whose code ships in the
distribution were missing from it — `etcd-operator`,
`keycloak-kms-proxy`, `local-ccm`, `cozystack-scheduler` and
`ingress-nginx-with-protobuf-exporter` — while `talos-bootstrap` and
`talos-meta-tool` were listed although an adopter installs neither.
Nothing stated what being on the list meant, which is why it drifted.

It is replaced by a section organised around the distinction that
decides scope: whether a repository's output reaches the artifact an
adopter installs. Packaged sub-projects get a table naming what each one
contributes, its stability, and its owners — the same handles each
repository's `CODEOWNERS` already carries. Independent tooling, project
infrastructure and upstream forks are described in a line each, as
explicitly outside that scope.

Three things an evaluator finds anyway are stated rather than left to be
discovered: that one fork (`apimachinery`) is compiled into the product,
why, and that the fix is proposed upstream as
kubernetes/kubernetes#135537; that four repositories are private, with
the reason for each, and that none of them contributes to the
distribution; and that telemetry is received by a component adopters do
not install, with a link to the opt-out.

### Third-party Dependencies

Writes down which shipped components the project does not govern.
Cozystack vendors software it does not own, which is ordinary and needs
no defence — but the boundary was nowhere stated. This is a Required
item on the Incubation checklist ("All project metadata and resources
are vendor-neutral"), and an evaluator currently has nothing in the
governance document to read it off.

The section says two things: what the arrangement is, and where the
components are listed. It names nothing itself. The
[Licenses](https://cozystack.io/docs/v1.6/operations/configuration/licenses/)
page carries the list, and by its own framing carries upstreams only —
Cozystack-maintained components are Apache-2.0 and are not listed there
individually. Appearing on that page is therefore already the
classification, so a second list here would only drift from it.

Two components that belong on that page were missing from it despite
shipping since v1.3.4 and v1.4.3; cozystack/website#649 adds them.

Nothing moves, nothing is relicensed, no mirroring changes. This
documents the existing arrangement, which each package's `values.yaml`
already describes at its own level.

### Downstream repositories

Walked the trigger map in `docs/agents/contributing.md` against the
diff. It touches `GOVERNANCE.md` only, and no trigger concerns
governance documents — the website triggers are package additions,
platform values, variants, components, release assets,
`ApplicationDefinition` semantics, the Talos pin and developer tooling.
The website PR linked above is a companion, not a consequence of this
diff: it fixes a pre-existing gap on the Licenses page that stands on
its own.

- [x] No downstream repository is affected by this change

### Release note

```release-note
NONE
```


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Added governance guidance for project sub-components, including
ownership, licensing, maintenance, and repository classifications.
* Documented project infrastructure, upstream forks, private
repositories, and telemetry services.
* Clarified how third-party software is sourced, governed, mirrored, and
versioned.
* Linked to a license inventory listing third-party components and their
applicable licenses.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

…3784)

## What this PR does

Brings `GOVERNANCE.md` in line with the organisation it describes: what
the project governs, and what it ships but does not.

### Sub-projects

The `Code Repositories` list named seven repositories and was wrong in
both directions. Five of the six sub-projects whose code ships in the
distribution were missing from it — `etcd-operator`,
`keycloak-kms-proxy`, `local-ccm`, `cozystack-scheduler` and
`ingress-nginx-with-protobuf-exporter` — while `talos-bootstrap` and
`talos-meta-tool` were listed although an adopter installs neither.
Nothing stated what being on the list meant, which is why it drifted.

It is replaced by a section organised around the distinction that
decides scope: whether a repository's output reaches the artifact an
adopter installs. Packaged sub-projects get a table naming what each one
contributes, its stability, and its owners — the same handles each
repository's `CODEOWNERS` already carries. Independent tooling, project
infrastructure and upstream forks are described in a line each, as
explicitly outside that scope.

Three things an evaluator finds anyway are stated rather than left to be
discovered: that one fork (`apimachinery`) is compiled into the product,
why, and that the fix is proposed upstream as
kubernetes/kubernetes#135537; that four repositories are private, with
the reason for each, and that none of them contributes to the
distribution; and that telemetry is received by a component adopters do
not install, with a link to the opt-out.

### Third-party Dependencies

Writes down which shipped components the project does not govern.
Cozystack vendors software it does not own, which is ordinary and needs
no defence — but the boundary was nowhere stated. This is a Required
item on the Incubation checklist ("All project metadata and resources
are vendor-neutral"), and an evaluator currently has nothing in the
governance document to read it off.

The section says two things: what the arrangement is, and where the
components are listed. It names nothing itself. The
[Licenses](https://cozystack.io/docs/v1.6/operations/configuration/licenses/)
page carries the list, and by its own framing carries upstreams only —
Cozystack-maintained components are Apache-2.0 and are not listed there
individually. Appearing on that page is therefore already the
classification, so a second list here would only drift from it.

Two components that belong on that page were missing from it despite
shipping since v1.3.4 and v1.4.3; cozystack/website#649 adds them.

Nothing moves, nothing is relicensed, no mirroring changes. This
documents the existing arrangement, which each package's `values.yaml`
already describes at its own level.

### Downstream repositories

Walked the trigger map in `docs/agents/contributing.md` against the
diff. It touches `GOVERNANCE.md` only, and no trigger concerns
governance documents — the website triggers are package additions,
platform values, variants, components, release assets,
`ApplicationDefinition` semantics, the Talos pin and developer tooling.
The website PR linked above is a companion, not a consequence of this
diff: it fixes a pre-existing gap on the Licenses page that stands on
its own.

- [x] No downstream repository is affected by this change

### Release note

```release-note
NONE
```


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Added governance guidance for project sub-components, including
ownership, licensing, maintenance, and repository classifications.
* Documented project infrastructure, upstream forks, private
repositories, and telemetry services.
* Clarified how third-party software is sourced, governed, mirrored, and
versioned.
* Linked to a license inventory listing third-party components and their
applicable licenses.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->