Bug 1773682

Please take a note, that next also are impacted:

com.github.openshift.api.build.v1.BuildConfigSpec
nodeSelector, status -- listed as required

com.github.openshift.api.build.v1.BuildConfigStatus
lastVersion -- listed as required

I cannot deploy buildconfig with helm.

Also affecting ImageStream

Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(ImageStream): missing required field "spec" in com.github.openshift.api.image.v1.ImageStream

*** Bug 1773877 has been marked as a duplicate of this bug. ***

Setting found version as 3.11 to match the dupe and target as 4.3.0 for analysis/span of which versions are impacted.

https://github.com/openshift/openshift-apiserver/pull/55 is the bump, for reference

Refer to the duplicate bug 1773877, verified the bug with following env:

$ oc version
Client Version: v4.4.0
Server Version: 4.4.0-0.nightly-2019-12-20-210709
Kubernetes Version: v1.17.0

Executing the following Shell scripts in console,

OPENSHIFT_API_URL=`oc config view --minify -o jsonpath='{.clusters[*].cluster.server}'`
OPENSHIFT_API_TOKEN=`oc whoami -t`
curl -k \
    -H "Authorization: Bearer $OPENSHIFT_API_TOKEN" \
    -H 'Accept: application/json' \
    $OPENSHIFT_API_URL/openapi/v2 | \
    jq > openapi.v2

Searching the keyword in openapi.v2, checked the required fields: BuildConfig, Route, ImageStream,RouteTargetReference and RouteStatus, they are as expected.

$ grep -n -A 6 '   "com.github.openshift.api.route.v1.Route' openapi.v2
170538:    "com.github.openshift.api.route.v1.Route": {
170539-      "description": "A route allows developers to expose services through an HTTP(S) aware load balancing and proxy layer via a public DNS entry. The route may further specify TLS options and a certificate, or specify a public CNAME that the router should also accept for HTTP and HTTPS traffic. An administrator typically configures their router to be visible outside the cluster firewall, and may also add additional security, caching, or traffic controls on the service content. Routers usually talk directly to the service endpoints.\n\nOnce a route is created, the `host` field may not be changed. Generally, routers use the oldest route with a given host when resolving conflicts.\n\nRouters are subject to additional customization and may support additional controls via the annotations field.\n\nBecause administrators may configure multiple routers, the route status field is used to return information to clients about the names and states of the route under each router. If a client chooses a duplicate name, for instance, the route status conditions are used to indicate the route cannot be chosen.",
170540-      "type": "object",
170541-      "required": [
170542-        "spec"
170543-      ],
170544-      "properties": {
...
170607:    "com.github.openshift.api.route.v1.RouteIngressCondition": {
170608-      "description": "RouteIngressCondition contains details for the current condition of this route on a particular router.",
170609-      "type": "object",
170610-      "required": [
170611-        "type",
170612-        "status"
170613-      ],
--
170637:    "com.github.openshift.api.route.v1.RouteList": {
170638-      "description": "RouteList is a collection of Routes.",
170639-      "type": "object",
170640-      "required": [
170641-        "items"
170642-      ],
170643-      "properties": {
--
170676:    "com.github.openshift.api.route.v1.RoutePort": {
170677-      "description": "RoutePort defines a port mapping from a router to an endpoint in the service endpoints.",
170678-      "type": "object",
170679-      "required": [
170680-        "targetPort"
170681-      ],
170682-      "properties": {
--
170689:    "com.github.openshift.api.route.v1.RouteSpec": {
170690-      "description": "RouteSpec describes the hostname or path the route exposes, any security information, and one to four backends (services) the route points to. Requests are distributed among the backends depending on the weights assigned to each backend. When using roundrobin scheduling the portion of requests that go to each backend is the backend weight divided by the sum of all of the backend weights. When the backend has more than one endpoint the requests that end up on the backend are roundrobin distributed among the endpoints. Weights are between 0 and 256 with default 100. Weight 0 causes no requests to the backend. If all weights are zero the route will be considered to have no backends and return a standard 503 response.\n\nThe `tls` field is optional and allows specific certificates or behavior for the route. Routers typically configure a default certificate on a wildcard domain to terminate routes without explicit certificates, but custom hostnames usually must choose passthrough (send traffic directly to the backend via the TLS Server-Name- Indication field) or provide a certificate.",
170691-      "type": "object",
170692-      "required": [
170693-        "to"
170694-      ],
170695-      "properties": {
--
170733:    "com.github.openshift.api.route.v1.RouteStatus": {
170734-      "description": "RouteStatus provides relevant info about the status of a route, including which routers acknowledge it.",
170735-      "type": "object",
170736-      "required": [
170737-        "ingress"
170738-      ],
170739-      "properties": {
--
170749:    "com.github.openshift.api.route.v1.RouteTargetReference": {
170750-      "description": "RouteTargetReference specifies the target that resolve into endpoints. Only the 'Service' kind is allowed. Use 'weight' field to emphasize one over others.",
170751-      "type": "object",
170752-      "required": [
170753-        "kind",
170754-        "name"
170755-      ],

*** Bug 1805884 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0581