Bug 805989

Summary: [REST API] Provide an mean to check the state of an application
Product: OKD Reporter: Xavier Coulon <xcoulon>
Component: PodAssignee: Abhishek Gupta <abhgupta>
Status: CLOSED CURRENTRELEASE QA Contact: libra bugs <libra-bugs>
Severity: low Docs Contact:
Priority: medium    
Version: 2.xCC: adietish, jialiu, mpatel, rmillner
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ruby-stickshift-controller-0.10.4-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-14 17:22:07 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:

Description Xavier Coulon 2012-03-22 15:57:02 UTC
Could be just an extra attribute in the response, giving the running state (STARTED/STARTING/STOPPED/STOPPING).

Comment 1 Andre Dietisheim 2012-03-22 18:03:57 UTC
A reason for this requirement is reported in https://bugzilla.redhat.com/show_bug.cgi?id=806008. A typical client would 

1) request the app creation
2) wait for it to become reachable (git, http, etc.)

Comment 2 Andre Dietisheim 2012-03-23 09:35:35 UTC
*** Bug 806008 has been marked as a duplicate of this bug. ***

Comment 3 Xavier Coulon 2012-03-23 09:38:25 UTC
To summarize our need (on the JBoss Tools side): when querying for an application (using the GET /domain/<domain>/applications/<appName>), the response could contain a 'state' element with one on the following values:
- CREATING : the application is being created on OpenShift (git, http, etc.). It is not available yet for cloning, the client should wait
- STARTING: the application is being started
- STARTED: the application is running
- STOPPING: the application is being stopped
- STOPPED: the application is stopped

If the state is not 'CREATING', then the client can clone the git repo and push content.

Comment 4 Andre Dietisheim 2012-03-23 10:49:00 UTC
I guess that we'd need a DESTROYING state in case one would GET the application state while the PaaS is destroying the application.

Comment 5 Xavier Coulon 2012-03-23 10:53:53 UTC
*** Bug 805986 has been marked as a duplicate of this bug. ***

Comment 6 Xavier Coulon 2012-03-26 14:02:23 UTC
Marking as URGENT since we'll need to know (at least) if the application is CREATED to be able to clone it

Comment 7 Abhishek Gupta 2012-03-28 18:49:16 UTC
The fix for this is more of a feature than a bug fix. Will be taking this up in the next sprint and try to deliver it early in the week.

Comment 8 Rob Millner 2012-03-29 03:04:07 UTC
Dropping the priority, this request shouldn't block the release even if its important to do for progress for another feature.

Comment 9 Xavier Coulon 2012-03-29 07:21:42 UTC
Yet, on the client side, we need this feature to know when the application's git repo is ready to be cloned. Unless there's a workaround... 
In the previous API, the creation request would return a temporary URL that we could query to know when the application is "ready" (or available). 

How do we do that now ?

Comment 10 Xavier Coulon 2012-03-29 10:01:37 UTC
As a complement to my previous comment:
In the previous API, the application creation response is in the following form:

data:{
	health_check_path: health,
	uuid: APPLICATION_UUID
} 

and we query (GET) this health_check_patch until response is 200 and body is '1'. Then, we know that the git repository is ready to be cloned.

So, as you understand, having this utility URL is a requirement for our tooling.

Granted, other states mentionned in the initial request (STARTED/STARTING/STOPPED/STOPPING) can be considered as a new feature, but at least, we'd need two states: CREATING/CREATED or something similar to be able to clone the application's git repo.

Comment 11 Abhishek Gupta 2012-05-07 23:07:25 UTC
The state of the application on each gear can be checked using the gear_groups rest api.

/broker/rest/domains/<domain-name>/applications/<app-name>/gear_groups

This rest call reflects the state of the application on each gear based on the contents of the file $OPENSHIFT_GEAR_DIR/runtime/.state

The following states should be tracked in ~/runtime/.state
    stopped
    building
    deploying
    started
    idle
    unknown

Comment 12 Johnny Liu 2012-05-09 13:51:34 UTC
Verified this bug with devenv_1762, and PASS.

Comment 13 Andre Dietisheim 2012-08-31 22:33:00 UTC
How is this related to https://bugzilla.redhat.com/show_bug.cgi?id=846166?