Bug 2043804
| Summary: | No way to verify if IPs with leading zeros are still valid in the apiserver | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | OpenShift BugZilla Robot <openshift-bugzilla-robot> |
| Component: | kube-apiserver | Assignee: | Antonio Ojea <aojeagar> |
| Status: | CLOSED ERRATA | QA Contact: | Rahul Gangwar <rgangwar> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.10 | CC: | mfojtik, rgangwar, xxia, zxiao |
| Target Milestone: | --- | ||
| Target Release: | 4.7.z | ||
| 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: | 2022-05-12 18:12:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2043808 | ||
| Bug Blocks: | 2043805 | ||
oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.11.0-0.nightly-2022-04-27-234931 True False 6h37m Cluster version is 4.11.0-0.nightly-2022-04-27-234931
rahulgangwar@rgangwar-mac openshift-tests-private % vi service.json
{"kind": "Service", "apiVersion": "v1", "metadata": {"name": "test-service", "namespace": "openshift-apiserver"}, "spec": {"clusterIP": "172.30.1.02", "externalIP": "192.168.0.012", "externalName": "test-service-one", "ports": [{"port": 10000, "targetPort": 11000}], "selector": {"test": "data"}}}
rahulgangwar@rgangwar-mac openshift-tests-private % oc create -f ./service.json
service/test-service created
rahulgangwar@rgangwar-mac openshift-tests-private % oc get svc test-service -n openshift-apiserver -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2022-04-29T11:37:44Z"
name: test-service
namespace: openshift-apiserver
resourceVersion: "165282"
uid: a5aad80e-f931-48f0-9627-187b69e5156a
spec:
clusterIP: 172.30.1.02
clusterIPs:
- 172.30.1.02
externalName: test-service-one
internalTrafficPolicy: Cluster
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- port: 10000
protocol: TCP
targetPort: 11000
selector:
test: data
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
cat pod.json
{"kind": "Pod", "apiVersion": "v1", "metadata": {"name": "pod1", "namespace": "openshift-apiserver"}, "spec": {"containers": [{"image": "python", "name": "test-pod", "resources": {"limits": {"cpu": "1M"}, "requests": {"cpu": "1M"}}}]}, "status": {"podIP":"10.244.0.05","podIPs":oc create -f pod.json
pod/pod1 created
rahulgangwar@rgangwar-mac openshift-tests-private % oc get po pod1 -n openshift-apiserver -o yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
openshift.io/scc: anyuid
creationTimestamp: "2022-04-29T11:39:14Z"
name: pod1
namespace: openshift-apiserver
resourceVersion: "165838"
uid: 29eb49ab-4509-43aa-8f62-7a81b778ea75
spec:
containers:
- image: python
imagePullPolicy: Always
name: test-pod
resources:
limits:
cpu: 1M
requests:
cpu: 1M
securityContext:
capabilities:
drop:
- MKNOD
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-rxmxz
readOnly: true
[{"ip":"10.244.0.05"}]}}
As you can see, IPs with leading zeros are correctly parsed without disrupting user actions.
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 (OpenShift Container Platform 4.7.50 bug fix update), 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-2022:1698 |
This bug’s PR is dev-approved and not yet merged, so I’m following issue DPTP-660 to do the pre-merge verifying by using the bot to launch a cluster with the open PR. Here is the verification steps: 1. Launch cluster using cluster bot with still open but yet to approved PRs $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.7.0-0.ci.test-2022-04-11-012443-ci-ln-xtqrcb2-latest True False 6m34s Cluster version is 4.7.0-0.ci.test-2022-04-11-012443-ci-ln-xtqrcb2-latest 2. Create service with leading zero IPs $ cat ./service.json {"kind": "Service", "apiVersion": "v1", "metadata": {"name": "test-service", "namespace": "openshift-apiserver"}, "spec": {"clusterIP": "172.30.1.02", "externalIP": "192.168.0.012", "externalName": "test-service-one", "ports": [{"port": 10000, "targetPort": 11000}], "selector": {"test": "data"}}} $ oc create -f ./service.json service/test-service created Check if service is created with success $ oc get svc test-service2 -n openshift-apiserver -o yaml apiVersion: v1 kind: Service … name: test-service namespace: openshift-apiserver resourceVersion: "36420" selfLink: /api/v1/namespaces/openshift-apiserver/services/test-service uid: c91237a8-b54e-4f2f-816f-ddf44e9bd58f spec: clusterIP: 172.30.1.02 clusterIPs: - 172.30.1.02 3. Create pod with leading zero IPs $ cat ./file/pod.json {"kind": "Pod", "apiVersion": "v1", "metadata": {"name": "pod1", "namespace": "openshift-apiserver"}, "spec": {"containers": [{"image": "python", "name": "test-pod", "resources": {"limits": {"cpu": "1M"}, "requests": {"cpu": "1M"}}}]}, "status": {"podIP":"10.244.0.05","podIPs":[{"ip":"10.244.0.05"}]}} $ oc create -f ./file/pod.json pod/pod1 created Check if testing pod is created correctly $ oc get po pod1 -n openshift-apiserver -o yaml apiVersion: v1 kind: Pod metadata: annotations: openshift.io/scc: anyuid creationTimestamp: "2022-04-11T02:20:23Z" ….. - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: …. f:status: f:podIP: {} f:podIPs: .: {} k:{"ip":"10.244.0.05"}: .: {} f:ip: {} manager: kubectl-create operation: Update time: "2022-04-11T02:20:23Z" As you can see, IPs with leading zeros are correctly parsed without disrupting user actions. So the bug is pre-merge verified. After the PR gets merged, the bug will be moved to VERIFIED by the bot automatically or, if not working, by me manually.