OPNET-592: Install-config interface for NMState configuration

[cybertron]

No description provided.

[openshift-ci-robot]

@cybertron: This pull request references OPNET-592 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.20.0" version, but no target version was set.

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign abhat for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• enhancements/network/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@cybertron: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/markdownlint	c5b5fdb	link	true	/test markdownlint

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[mkowalski]

What is the role of the name in this interface? Is it used to make a decision which configuration is applied to which node, or is it purely about labelling?

There are 2 cases where it may or may not matter

1. Bare metal clusters where you may not be sure if your network infra dispatches hostnames correctly (see wrong DHCP, missing PTRs and so on). If we match config for the NIC by its MAC address then it's cool because we don't really need a name for the host. At the same time, if you manage a cluster of metal nodes, you should have an inventory of MAC addresses, otherwise you have other, bigger, problems.

2. Non-metal platforms with machines dynamically created. Given the interface is now platform-agnostic, it is possible for someone to use it on e.g. AWS-deployed cluster. That means, at the moment of generating install-config you do not know names of the hosts; you also do not know MAC addresses of the NICs you are going to get on those nodes. Maybe this is a non-goal at this moment, but imagine a following scenario

As an operator deploying on AWS/Azure nodes with 2 NICs, I want the 2nd NIC of every node to be configured with a static IPv4 address in the form of 172.16.0.x/24 for x in 1-10.

We may or may not allow this, but interface in its current form looks like a perfect candidate to fulfil such a story.