| Summary: | no output when running oc explain ClusterDNS --api-version=dns.openshift.io/v1alpha1 | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Hongan Li <hongli> |
| Component: | Networking | Assignee: | Daneyon Hansen <dhansen> |
| Networking sub component: | router | QA Contact: | Hongan Li <hongli> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | medium | ||
| Priority: | medium | CC: | aos-bugs, dmace |
| Version: | 4.1.0 | ||
| Target Milestone: | --- | ||
| Target Release: | 4.1.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: | 2019-06-04 10:46:29 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: | |
|
Description
Hongan Li
2019-03-27 08:32:39 UTC
OpenAPI specs should fixed as of https://github.com/openshift/cluster-dns-operator/pull/87. Note the API group/version/kind to use is now `dns --api-version=dns.operator.openshift.io/v1`. maybe hit other regression issue but now `oc explain` cannot work for many CR with `--api-version=operator.openshift.io/v1`. $ oc explain dns --api-version=operator.openshift.io/v1 error: Couldn't find resource for "operator.openshift.io/v1, Kind=DNS" $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-04-10-182914 True False 29h Cluster version is 4.0.0-0.nightly-2019-04-10-182914 similar bug of master: https://bugzilla.redhat.com/show_bug.cgi?id=1688638#c5 move to assigned just for investigation
I am not experiencing this bug:
$ oc explain dns --api-version=operator.openshift.io/v1
KIND: DNS
VERSION: operator.openshift.io/v1
DESCRIPTION:
FIELDS:
apiVersion <string>
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/api-conventions.md#resources
kind <string>
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/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
spec <map[string]>
spec is the specification of the desired behavior of the DNS.
status <Object>
status is the most recently observed status of the DNS.
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.1.0-0.okd-2019-04-16-184709 True False 3h59m Cluster version is 4.1.0-0.okd-2019-04-16-184709
$
Yes, it also works with CI build
$ oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.0.0-0.ci-2019-04-16-221411 True False 59m Cluster version is 4.0.0-0.ci-2019-04-16-221411
$ oc explain dns.status --api-version=operator.openshift.io/v1
KIND: DNS
VERSION: operator.openshift.io/v1
RESOURCE: status <Object>
DESCRIPTION:
status is the most recently observed status of the DNS.
FIELDS:
clusterDomain <string>
clusterDomain is the local cluster DNS domain suffix for DNS services. This
will be a subdomain as defined in RFC 1034, section 3.5:
https://tools.ietf.org/html/rfc1034#section-3.5 Example: "cluster.local"
More info:
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service
clusterIP <string>
<---snip--->
seems not only DNS but other resources also have problem with nightly build (see #Comment 3), so I'm going to move it to verified.
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-2019:0758 |