Bug 1379563

Summary: Manual Deployment of pre-built application
Product: OpenShift Container Platform Reporter: Jaspreet Kaur <jkaur>
Component: openshift-controller-managerAssignee: Michail Kargakis <mkargaki>
Status: CLOSED DUPLICATE QA Contact: zhou ying <yinzhou>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.2.0CC: aos-bugs
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-27 09:19:35 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:

Description Jaspreet Kaur 2016-09-27 07:14:48 UTC
Description of the issue :

Application Replication Controllers are created from an outdated Deployment Config which saves the hash value of an old build of the application.

Deployment Config doesn't get updated with the latest build after a successful one.


When creating an application (using a standard Image Steam, i.e PHP),
the user is presented with advanced creation options, including setting the triggers for new Builds \ Deployments.
the user expects that when removing the 'ticks' in the Deployment Config triggers, the application would be built,
but NOT Deployed.

Common Timeline:
Dev puses code to his remote git >
3rd party CI completes successfully, and pushes code to openshift exposed git and uses openshift's webhook* >
Openshift Completes the build successfully and pushes to the Internal Registry

*This step could also be just a manual build

EXPECTED BEHAVIOR AT THIS POINT:
** Deployment  Config recognizes the ImageChange, updates itself in preparation to next deployment **
** User manually deploys the application a few hours after the successful build, and latest build is deployed ** 

ACTUAL BEHAVIOR AT THIS POINT:
Deployment Config still only remembers the first ever successful build of the application,
any subsequent manual deployments, would still deploy the first built image, which is outdated.

TEMPORARY Solution:
Either
1. Set Deployment Config to always pull from latest with complete disregard to image hash and triggers
2. Each Deployment reset the Config to the latest built image Hash (by peeking at the application Image Stream)


This problem completely breaks the deployment and rollback functionality, and gives a very hard time for developers.
and the solution we have implemented in the mean time, is unacceptable for long term as this is a production case.

Where are you experiencing the behavior?  What environment?

Reproduced in:
Openshift Enterprise 3.2.1.9-1-g2265530
Openshift Enterprise 3.1.1.6

When does the behavior occur? Frequently?  Repeatedly?   At certain times?

Always occurring, can be easily reproduced.

Steps to do so:
1. Prepare a git code (any platform) which serves a simple 'Version X' page, start with Version 1
2. Create an Openshift Project

2 ways to proceed from here (A and B):

A3. Using the mentioned code create an app, but deselect all triggers in the DC part
A4. After a successful build attempt a deployment
A5: Watch the deployment fail completely because No Image Stream was configured in the DC (no docker pull spec)

B3: Using the mentioned code create an app, but KEEP all triggers in the DC part
B4: After a successful build a deployment should be created automatically
   B4.1: Note that Now application returns Version 1
B5: Update the git to Version 2
B6: Remove all the Triggers from the DC (OR Remove the automatic setting on ImageChangeParams)
B7: Rebuild the app (Build would have Version 2)
B8: Deploy latest, Expect Version 2, but Version 1 still returns

Suggestion :

We would suggest 'refactor' the 'automatic' boolean field behaviour in ImageChangeParams,

So instead the current behavior:
automatic: true = Trigger Enabled
automatic: false OR absent = Trigger Disabled

This would be the new behavior:
automatic: true = Deployment Config gets updated with latest image hash AND Replication Controller is created automatically from the latest image
automatic: false = Deployment Config gets updated with latest image hash but no Replication Controller is deployed.

Comment 1 Michail Kargakis 2016-09-27 09:19:35 UTC

*** This bug has been marked as a duplicate of bug 1303938 ***