Bug 805989 - [REST API] Provide an mean to check the state of an application
[REST API] Provide an mean to check the state of an application
Status: CLOSED CURRENTRELEASE
Product: OpenShift Origin
Classification: Red Hat
Component: Kubernetes (Show other bugs)
2.x
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: Abhishek Gupta
libra bugs
: Triaged
: 805986 806008 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-22 11:57 EDT by Xavier Coulon
Modified: 2015-05-14 21:48 EDT (History)
4 users (show)

See Also:
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 13:22:07 EDT
Type: ---
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 Xavier Coulon 2012-03-22 11:57:02 EDT
Could be just an extra attribute in the response, giving the running state (STARTED/STARTING/STOPPED/STOPPING).
Comment 1 Andre Dietisheim 2012-03-22 14:03:57 EDT
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 05:35:35 EDT
*** Bug 806008 has been marked as a duplicate of this bug. ***
Comment 3 Xavier Coulon 2012-03-23 05:38:25 EDT
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 06:49:00 EDT
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 06:53:53 EDT
*** Bug 805986 has been marked as a duplicate of this bug. ***
Comment 6 Xavier Coulon 2012-03-26 10:02:23 EDT
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 14:49:16 EDT
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-28 23:04:07 EDT
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 03:21:42 EDT
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 06:01:37 EDT
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 19:07:25 EDT
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 09:51:34 EDT
Verified this bug with devenv_1762, and PASS.
Comment 13 Andre Dietisheim 2012-08-31 18:33:00 EDT
How is this related to https://bugzilla.redhat.com/show_bug.cgi?id=846166?

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