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-apiserverAssignee: Antonio Ojea <aojeagar>
Status: CLOSED ERRATA QA Contact: Rahul Gangwar <rgangwar>
Severity: high Docs Contact:
Priority: high    
Version: 4.10CC: 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    

Comment 1 Zimo Xiao 2022-04-11 06:29:00 UTC
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.

Comment 9 Rahul Gangwar 2022-04-29 11:53:38 UTC
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.

Comment 13 errata-xmlrpc 2022-05-12 18:12:28 UTC
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