Bug 1370058
| Summary: | client 3.3 can not scale dc on OSE 3.1 [compatibility] | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | XiaochuanWang <xiaocwan> |
| Component: | oc | Assignee: | Solly Ross <sross> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Xingxing Xia <xxia> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.3.0 | CC: | aos-bugs, ffranz, jokerman, mfojtik, mkargaki, mmccomas, sross, tdawson |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| 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: | 2016-09-19 15:18:21 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
XiaochuanWang
2016-08-25 08:11:55 UTC
agoldste@ (and I) did some digging, and the problem stems from three "issues": 1. OSE 3.1 has a ValidateScaleUpdate method, which calls ValidateObjectMetaUpdate. This is called on Scale updates in OSE 3.1, against a "fake" Scale object with only Name, Namespace, and CreationTimestamp filled out in ObjectMeta. 2. OpenShift's scaler code used in `oc scale` for DeploymentConfigs fetches the entire DC to scale, and then generates a scale object from that to submit 2. OSE 3.3's helper method for generating scale objects sets the UID, whereas OSE 3.1's does not (see https://github.com/openshift/origin/pull/6233). Thus, OSE 3.3's oc submits a scale update with a UID, and OSE 3.1 attempts to validate the ObjectMeta update against the fake "old" Scale, sees the UID being filled out as an attempt to set the UID, and bails. I think the right solution here is to not fetch the entire DeploymentConfig when attempting to submit a scale update, but instead just fetching the scale object itself. it looks like we only fetch the DC to check if dc.Spec.Test is set, an print an error (but not actually fail to do the update) when it is. IMO, it seems worth it to drop the warning message there in order to do the right thing with the Scale update. Adding Mikail, PTAL at the solution proposed by Solly. SGTM Fix has not yet been merged in OSE on oc v3.3.0.26. Verified it on origin client: oc v1.3.0-alpha.3+4250e53 against server (openshift v3.1.1.6-64-g80b61da) Better to verify it again on OSE 3.3 when code is merged. In order to keep tracking this bug, mark it on_qa. Verified on oc v3.3.0.27 against openshift v3.1.1.6-64-g80b61da Steps: # oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/sample-app/application-template-stibuild.json # oc get pod NAME READY STATUS RESTARTS AGE database-1-yv25d 1/1 Running 0 56s ruby-sample-build-1-build 1/1 Running 0 1m # oc scale dc/database --replicas=5 deploymentconfig "database" scaled # oc get pod NAME READY STATUS RESTARTS AGE database-1-biklu 1/1 Running 0 3m database-1-due7c 1/1 Running 0 3m database-1-ktq9u 1/1 Running 0 3m database-1-xj4hv 1/1 Running 0 3m database-1-yv25d 1/1 Running 0 4m frontend-1-yfeq9 1/1 Running 0 2m frontend-1-yfgh1 1/1 Running 0 2m ruby-sample-build-1-build 0/1 Completed 0 4m |