spinnaker: Deployments fail with parsing error when triggered by Docker Registry

Steps to reproduce: While setting up a new Kubernetes deployment step, when checking the “Deployment” checkbox, leave all default values, save, then trigger the step via a Docker Registry update.

Result:

Exception ( Monitor Deploy )
Failure executing: PATCH at: https://10.51.169.25:6443/apis/extensions/v1beta1/namespaces/default/deployments/wrnchforwarder-dev. Message: Deployment.apps "wrnchforwarder-dev" is invalid: [spec.strategy.rollingUpdate.maxUnavailable: Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: a valid percent string must be a numeric string followed by an ending '%' (e.g. '1%', or '93%', regex used for validation is '[0-9]+%'), spec.strategy.rollingUpdate.maxSurge: Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: a valid percent string must be a numeric string followed by an ending '%' (e.g. '1%', or '93%', regex used for validation is '[0-9]+%'), spec.strategy.rollingUpdate.maxUnavailable: Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: may not be 0 when `maxSurge` is 0]. Received status: Status(apiVersion=v1, code=422, details=StatusDetails(causes=[StatusCause(field=spec.strategy.rollingUpdate.maxUnavailable, message=Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: a valid percent string must be a numeric string followed by an ending '%' (e.g. '1%', or '93%', regex used for validation is '[0-9]+%'), reason=FieldValueInvalid, additionalProperties={}), StatusCause(field=spec.strategy.rollingUpdate.maxSurge, message=Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: a valid percent string must be a numeric string followed by an ending '%' (e.g. '1%', or '93%', regex used for validation is '[0-9]+%'), reason=FieldValueInvalid, additionalProperties={}), StatusCause(field=spec.strategy.rollingUpdate.maxUnavailable, message=Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: may not be 0 when `maxSurge` is 0, reason=FieldValueInvalid, additionalProperties={})], group=apps, kind=Deployment, name=wrnchforwarder-dev, retryAfterSeconds=null, additionalProperties={}), kind=Status, message=Deployment.apps "wrnchforwarder-dev" is invalid: [spec.strategy.rollingUpdate.maxUnavailable: Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: a valid percent string must be a numeric string followed by an ending '%' (e.g. '1%', or '93%', regex used for validation is '[0-9]+%'), spec.strategy.rollingUpdate.maxSurge: Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: a valid percent string must be a numeric string followed by an ending '%' (e.g. '1%', or '93%', regex used for validation is '[0-9]+%'), spec.strategy.rollingUpdate.maxUnavailable: Invalid value: intstr.IntOrString{Type:1, IntVal:0, StrVal:"1.0"}: may not be 0 when `maxSurge` is 0], metadata=ListMeta(resourceVersion=null, selfLink=null, additionalProperties={}), reason=Invalid, status=Failure, additionalProperties={}).```

Workaround: Manually change Max Unavailable and Max Surge to any number/percentage, save, then change back to 1/1 (the default values).

Expected result: Deploy occurs properly.

In addition, the bug is complicated by the fact that manual triggered deploys do not encounter this issue.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 3
  • Comments: 101

Most upvoted comments

I face the same problem with yours. This is because that the yaml configuration that generated by Spinnaker UI is wrong. To solve this problem:

  1. Click your application
  2. Click Piples
  3. Click Configure
  4. Click Pipeline Actions, then click Edit as JSON
  5. Find the keyword, maxSurge. This value should be string, like “100%”
  6. Find the keyword, maxUnavailable. This value should be string like “0%” Here is an example. { "rollingUpdate": { "maxSurge": "100%", "maxUnavailable": "0%" } }
  7. Update Pipeline

I can also confirm this issue with Spinnaker 1.5.1 as well as with 1.5.4. The behavior is exactly like @mike10010100 described, it happens when an automatic trigger starts the deployment, and does not happen when manually triggered.

I am having the same issue. Manual deployment works but the automated trigger doesn’t. I’m triggering from our private artifactory repo if that makes a difference.