Bug 1263081 - Failed event exists in deploymentconfig when creates initial deployment by imagechange trigger
Failed event exists in deploymentconfig when creates initial deployment by im...
Status: CLOSED CURRENTRELEASE
Product: OpenShift Origin
Classification: Red Hat
Component: Deployments (Show other bugs)
3.x
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: Dan Mace
zhou ying
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-15 02:11 EDT by XiuJuan Wang
Modified: 2015-11-23 16:17 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-23 16:17:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description XiuJuan Wang 2015-09-15 02:11:39 EDT
Description of problem:
Failed event exists in deploymentconfig when creates the initial deployment.
The message is "Couldn't create initial deployment: DeploymentConfig "frontend" is invalid: triggers[0].imageChange.tag: invalid value 'latest', Details: no image recorded for <namespace>/origin-ruby-sample:latest"

Actually, the initial deployment succeed.

Version-Release number of selected component (if applicable):
devenv-fedora-2240

How reproducible:
always

Steps to Reproduce:
1.Create an application
$ oc new-app application-template-stibuild.json
2.After build complate, check deploy pod logs
3.Describe deploymentconfig

Actual results:
step 2:
No error in deploy pod log

step3:
$ oc  describe  dc frontend 
Name:		frontend
Created:	2 minutes ago
Labels:		template=application-template-stibuild
Latest Version:	1
Triggers:	Image(origin-ruby-sample@latest, auto=true), Config
Strategy:	Rolling
Template:
  Selector:	name=frontend
  Replicas:	2
  Containers:
  NAME			IMAGE														ENV
  ruby-helloworld	172.30.246.16:5000/xiuwang/origin-ruby-sample@sha256:c725e18cd8ce0415f3dc798d5290a3aa63f81f242f92e2b637752ab1abb37ad3	ADMIN_PASSWORD=bRWojFYG,ADMIN_USERNAME=admin5LV,MYSQL_DATABASE=root,MYSQL_PASSWORD=qehX3Xc6,MYSQL_USER=userP5Q
Deployment #1 (latest):
	Name:		frontend-1
	Created:	31 seconds ago
	Status:		Complete
	Replicas:	2 current / 2 desired
	Selector:	deployment=frontend-1,deploymentconfig=frontend,name=frontend
	Labels:		openshift.io/deployment-config.name=frontend,template=application-template-stibuild
	Pods Status:	2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Events:
  FirstSeen	LastSeen	Count	From		SubobjectPath	Reason		Message
  2m		1m		2	{deployer }			failedCreate	Couldn't create initial deployment: DeploymentConfig "frontend" is invalid: triggers[0].imageChange.tag: invalid value 'latest', Details: no image recorded for xiuwang/origin-ruby-sample:latest


Expected results:
Should have no failed event

Additional info:

No error in deploy pod log
$ oc  logs frontend-1-deploy 
I0915 03:41:15.895509       1 deployer.go:195] Deploying xiuwang/frontend-1 for the first time (replicas: 2)
I0915 03:41:15.896705       1 recreate.go:113] Scaling xiuwang/frontend-1 to 1 before performing acceptance check
I0915 03:41:17.923603       1 recreate.go:118] Performing acceptance check of xiuwang/frontend-1
I0915 03:41:17.923826       1 lifecycle.go:279] Waiting 120 seconds for pods owned by deployment "xiuwang/frontend-1" to become ready (checking every 1 seconds; 0 pods previously accepted)
I0915 03:41:27.924448       1 lifecycle.go:300] All pods ready for xiuwang/frontend-1
I0915 03:41:27.924473       1 recreate.go:126] Scaling xiuwang/frontend-1 to 2
I0915 03:41:29.967235       1 recreate.go:144] Deployment frontend-1 successfully made active
Comment 1 Dan Mace 2015-09-15 08:57:18 EDT
This is as designed. When you created the deploymentConfig, the image tag referenced in the triggered didn't exist, and events were produced. Eventually, the build completed and produced the image/tag, satisfying the reference, and triggering the deployment. If the events continued to be produced after the successful deployment, there'd be a problem, but looking at the event count pasted here that doesn't seem to be the case.
Comment 2 XiuJuan Wang 2015-09-15 22:36:04 EDT
Dan,
Thanks for the detailed explanation.

Note You need to log in before you can comment on or make changes to this bug.