Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1809389

Summary: Missing properties in MachineConfig OpenSpec API
Product: OpenShift Container Platform Reporter: Jason Boxman <jboxman>
Component: Machine Config OperatorAssignee: Yu Qi Zhang <jerzhang>
Status: CLOSED DUPLICATE QA Contact: Michael Nguyen <mnguyen>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.4   
Target Milestone: ---   
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-04 14:07:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jason Boxman 2020-03-03 02:18:34 UTC
Hi,

For some reason, the OpenAPI spec for several of the CRDs in the machineconfiguration.openshift.io group do not have a `properties` key:

```
machine.openshift.io/v1beta1 Machine
machine.openshift.io/v1beta1 MachineHealthCheck
machine.openshift.io/v1beta1 MachineSet
machineconfiguration.openshift.io/v1 ContainerRuntimeConfig
machineconfiguration.openshift.io/v1 ControllerConfig
machineconfiguration.openshift.io/v1 KubeletConfig
machineconfiguration.openshift.io/v1 MachineConfig
machineconfiguration.openshift.io/v1 MachineConfigPool
```

For example:

```
    "io.openshift.machineconfiguration.v1.MachineConfigPool": {
      "type": "object",
      "x-kubernetes-group-version-kind": [
        {
          "group": "machineconfiguration.openshift.io",
          "kind": "MachineConfigPool",
          "version": "v1"
        }
      ]
    },

```

This spec is part of the output from `oc get —raw /apis`. I’ve been using the OpenAPI spec file as the basis for the OpenShift API documentation on docs.openshift.com.

The fix might be to include `preserveUnknownFields: false` CRD[0].


Steps to Reproduce:
1. Run `oc get —raw /apis`

Typically, they look like this:

```
    "io.openshift.network.v1.EgressNetworkPolicy": {
      "description": "EgressNetworkPolicy describes the current egress network policy for a Namespace. When using the 'redhat/openshift-ovs-multitenant' network plugin, traffic from a pod to an IP address outside the cluster will be checked against each EgressNetworkPolicyRule in the pod's namespace's EgressNetworkPolicy, in order. If no rule matches (or no EgressNetworkPolicy is present) then the traffic will be allowed by default.",
      "type": "object",
      "required": [
        "spec"
      ],
      "properties": {
        "apiVersion": {
          "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://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
          "type": "string"
        },
        "kind": {
          "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://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
          "type": "string"
        },
        "metadata": {
          "description": "Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata",
          "$ref": "#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta"
        },
        "spec": {
          "description": "spec is the specification of the current egress network policy",
          "type": "object",
          "required": [
            "egress"
          ],
          "properties": {
            "egress": {
              "description": "egress contains the list of egress policy rules",
              "type": "array",
              "maxItems": 50,
              "items": {
                "description": "EgressNetworkPolicyRule contains a single egress network policy rule",
                "type": "object",
                "required": [
                  "to",
                  "type"
                ],
                "properties": {
                  "to": {
                    "description": "to is the target that traffic is allowed/denied to",
                    "type": "object",
                    "maxProperties": 1,
                    "minProperties": 1,
                    "properties": {
                      "cidrSelector": {
                        "description": "cidrSelector is the CIDR range to allow/deny traffic to. If this is set, dnsName must be unset",
                        "type": "string",
                        "pattern": "^(([0-9]|[0-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\\.){3}([0-9]|[0-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])/([0-9]|[12][0-9]|3[0-2])$"
                      },
                      "dnsName": {
                        "description": "dnsName is the domain name to allow/deny traffic to. If this is set, cidrSelector must be unset",
                        "type": "string",
                        "pattern": "^([A-Za-z0-9-]+\\.)*[A-Za-z0-9-]+\\.?$"
                      }
                    }
                  },
                  "type": {
                    "description": "type marks this as an \"Allow\" or \"Deny\" rule",
                    "type": "string",
                    "pattern": "^Allow|Deny$"
                  }
                }
              }
            }
          }
        }
      },
      "x-kubernetes-group-version-kind": [
        {
          "group": "network.openshift.io",
          "kind": "EgressNetworkPolicy",
          "version": "v1"
        }
      ]
    },
```

[0] https://github.com/openshift/cluster-network-operator/pull/458

Comment 1 Yu Qi Zhang 2020-03-03 14:38:24 UTC
Hi Jason,

I believe this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1705750, or at least the problem you described you should resolved by that. See: https://github.com/openshift/machine-config-operator/blob/release-4.4/manifests/machineconfig.crd.yaml#L33

This should be in latest nightly builds, so your cluster may be older. Could you try with the latest nightlies?

Also, could you tell me the exact command you ran? `oc get -raw /apis` doesn't seem to work, and I tried variations of `oc get --raw /apis/network.openshift.io/v1/egressnetworkpolicies` but it doesn't give me that detailed of an output

Comment 2 Jason Boxman 2020-03-04 03:58:18 UTC
Sorry, the correct command is:

`oc get --raw /openapi/v2 | jq .`

I can look at a recent nightly.

Thanks!

Comment 3 Yu Qi Zhang 2020-03-04 14:07:36 UTC
This is what I see for e.g. machineconfigpool from a nightly build yesterday:

"io.openshift.machineconfiguration.v1.MachineConfigPool": {
      "description": "MachineConfigPool describes a pool of MachineConfigs.",
      "type": "object",
      "properties": {
        "apiVersion": {
          "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://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
          "type": "string"
        },
        "kind": {
          "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://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
          "type": "string"
        },
        "metadata": {
          "description": "Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata",
          "$ref": "#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta"
        },
        "spec": {
          "description": "MachineConfigPoolSpec is the spec for MachineConfigPool resource.",
          "type": "object",
          "properties": {
...

And a bunch more fields. I think this is working as intended now. Will close, please let me know if you are still having issues.

*** This bug has been marked as a duplicate of bug 1705750 ***