[rrajendran17]

Problem:

New CRD required for introducing host network configs on harvester hosts

Solution:

new crd for creating host network configs on harvester host and its related permissions

Related Issue(s):

harvester/harvester#8101

Test plan:

https://github.com/rrajendran17/harvester-harvester/blob/HEP-ipconfig/enhancements/20251015-support-ipconfig-on-clusternetworks.md

Additional documentation or context

[Copilot]

Pull request overview

This PR adds a new HostNetworkConfig Custom Resource Definition (CRD) to manage node-level network configurations on Harvester hosts, along with the necessary RBAC permissions to access this resource.

Key Changes:

• Introduces the HostNetworkConfig CRD supporting both static and DHCP IP assignment modes with VLAN configuration capabilities
• Updates RBAC permissions for harvester-network-controller and harvester-network-webhook to include access to the new hostnetworkconfigs resource

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.

File	Description
charts/harvester-network-controller/templates/crds/network.harvesterhci.io_hostnetworkconfigs.yaml	New CRD defining the HostNetworkConfig resource with spec for network configuration and status for tracking per-node application state
charts/harvester-network-controller/templates/rbac.yaml	Adds "hostnetworkconfigs" to the resources list in both the main controller ClusterRole and webhook ClusterRole for appropriate access permissions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The apiVersion and kind fields lack the detailed descriptions that are present in other CRDs in this repository. For consistency with vlanconfigs, vlanstatuses, and linkmonitors, these fields should include standard Kubernetes descriptions explaining their purpose.

Suggested change

	type: string
	kind:
	type: string
	type: string
	description: |
	APIVersion defines the versioned schema of this representation of an object.
	Servers should convert recognized schemas to the latest internal value, and
	may reject unrecognized values. More info:
	https://kubernetes.io/docs/reference/using-api/api-overview/
	kind:
	type: string
	description: |
	Kind is a string value representing the REST resource this object represents.
	Servers may infer this from the endpoint the client submits requests to.
	Cannot be updated. In CamelCase. More info:
	https://kubernetes.io/docs/reference/using-api/api-overview/

[Copilot]

The CRD is missing additionalPrinterColumns which are present in similar CRDs like vlanconfigs and vlanstatuses. Adding printer columns for key fields such as clusterNetwork, mode, and AGE would improve the user experience when listing resources with kubectl.

Suggested change

	storage: true
	storage: true
	additionalPrinterColumns:
	- name: ClusterNetwork
	type: string
	jsonPath: .spec.clusterNetwork
	- name: Mode
	type: string
	jsonPath: .spec.mode
	- name: Age
	type: date
	jsonPath: .metadata.creationTimestamp

[Copilot]

The schema is missing a top-level 'required' field for the spec property. Other CRDs in this repository (vlanconfigs, linkmonitors, vlanstatuses) include a 'required' array at the root level of the schema to enforce that spec is present. This should be added for consistency and to ensure proper validation.

[Copilot]

The validation for the 'ips' field may need additional constraints. When mode is 'static', the ips field should likely be required, but when mode is 'dhcp', it should not be used. Consider adding validation rules or documenting this relationship more clearly to prevent invalid configurations.

[Copilot]

The vlanID field has validation constraints (minimum: 2, maximum: 4094) but is not marked as required. The documentation should clarify whether vlanID is optional and, if so, what the behavior is when it's not specified. Alternatively, if vlanID is always required for host network configurations, it should be added to the required array.

Suggested change

	description: VLAN ID associated with the host network
	description: |
	Optional VLAN ID associated with the host network. If omitted, the
	host network configuration uses the controller's default VLAN behavior
	(for example, it may be treated as an untagged network).

[innobead]

Did you add this new CRD first to https://github.com/harvester/network-controller-harvester/tree/master/pkg/apis/network.harvesterhci.io/v1beta1 and https://github.com/harvester/network-controller-harvester/tree/master/manifests/crds? I assume this PR should come after updating the component repo first.

[rrajendran17]

Did you add this new CRD first to https://github.com/harvester/network-controller-harvester/tree/master/pkg/apis/network.harvesterhci.io/v1beta1 and https://github.com/harvester/network-controller-harvester/tree/master/manifests/crds? I assume this PR should come after updating the component repo first.

@innobead yes the corresponding network controller changes are here rrajendran17/network-controller-harvester@7824dcd (work in progress), I will post it for review once complete, Thanks

[ihcsim]

One thing you can consider doing is to use the built-in CEL validation to validate the CIDR format. It makes the API more expressive and ensures K8s rejects any invalid format immediately, without the request ever reaching our webhook.

For example,

ips:
    additionalProperties:
        description: |-
               CIDR is an IP address range in CIDR notation (for example, "10.0.0.0/8" or "fd00::/8").
        maxLength: 18 # required
        type: string
        x-kubernetes-validations:
            - message: Invalid CIDR format provided
              rule: isCIDR(self)

[w13915984028]

@rrajendran17 As the CIDR related parts are modified manually to yaml, it will be a bit diffcult to maintain

please

(1) Add comment to the source code api definition on harvester/network-controller-harvester#229

(2) Please check below script, if we could use a diff file or some other ways to patch the crd after make generate, and on make generate-manifest

https://github.com/harvester/network-controller-harvester/blob/67b26a944114641d2b43ef4c37524dc0a38f0b5e/scripts/generate-manifest#L23

thanks.

[rrajendran17]

@rrajendran17 As the CIDR related parts are modified manually to yaml, it will be a bit diffcult to maintain

please

(1) Add comment to the source code api definition on harvester/network-controller-harvester#229

(2) Please check below script, if we could use a diff file or some other ways to patch the crd after make generate, and on make generate-manifest

https://github.com/harvester/network-controller-harvester/blob/67b26a944114641d2b43ef4c37524dc0a38f0b5e/scripts/generate-manifest#L23

thanks.

Thanks @w13915984028 I have updated the original PR with the crd generated from api, but did not update this PR with the same crd. I have pushed the changes now.
One problem I see is maxLength field is not recognized by the controller-gen but it was required for CEL CIDR validation, I had to add it manually to the CRD.

[starbops]

One problem I see is maxLength field is not recognized by the controller-gen but it was required for CEL CIDR validation, I had to add it manually to the CRD.

Maybe updating the controller-gen to a newer version might help?

[rrajendran17]

One problem I see is maxLength field is not recognized by the controller-gen but it was required for CEL CIDR validation, I had to add it manually to the CRD.

Maybe updating the controller-gen to a newer version might help?

I thought its an issue with controller-gen, looks like the kubebuillder does not provide an explicit maxLength for map values as string.It supports validations for slice formats and strings. If value in map has to be validated for maxLength, then it can be made as a string inside a struct but it complicates the api.
For the cidr validation it expects maxLength to be present, otherwise the crd installation fails with the following error.I think the only option was to add maxLength manually. (or we could move the CIDR CEL validation out of crd and do it in webhook)

Let me know in case there are other options, Thanks

* spec.validation.openAPIV3Schema.properties[spec].properties[ips].x-kubernetes-validations[0].rule: Forbidden: estimated rule cost exceeds budget by factor of 15.7x (try simplifying the rule, or adding maxItems, maxProperties, and maxLength where arrays, maps, and strings are declared)

[rrajendran17]

One problem I see is maxLength field is not recognized by the controller-gen but it was required for CEL CIDR validation, I had to add it manually to the CRD.

Maybe updating the controller-gen to a newer version might help?

I thought its an issue with controller-gen, looks like the kubebuillder does not provide an explicit maxLength for map values as string.It supports validations for slice formats and strings. If value in map has to be validated for maxLength, then it can be made as a string inside a struct but it complicates the api. For the cidr validation it expects maxLength to be present, otherwise the crd installation fails with the following error.I think the only option was to add maxLength manually. (or we could move the CIDR CEL validation out of crd and do it in webhook)

Let me know in case there are other options, Thanks

* spec.validation.openAPIV3Schema.properties[spec].properties[ips].x-kubernetes-validations[0].rule: Forbidden: estimated rule cost exceeds budget by factor of 15.7x (try simplifying the rule, or adding maxItems, maxProperties, and maxLength where arrays, maps, and strings are declared)

@ihcsim helped me fix this.Its all good now,I could include maxLength from api into the CRD.Thanks

[w13915984028]

LGTM, thanks.

[w13915984028]

question: could here and below be "*", as all the resources are by nature operated by network-controller

[w13915984028]

LGTM, thanks.