Red Hat Bugzilla – Bug 805989
[REST API] Provide an mean to check the state of an application
Last modified: 2015-05-14 21:48:48 EDT
Could be just an extra attribute in the response, giving the running state (STARTED/STARTING/STOPPED/STOPPING).
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.)
*** Bug 806008 has been marked as a duplicate of this bug. ***
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.
I guess that we'd need a DESTROYING state in case one would GET the application state while the PaaS is destroying the application.
*** Bug 805986 has been marked as a duplicate of this bug. ***
Marking as URGENT since we'll need to know (at least) if the application is CREATED to be able to clone it
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.
Dropping the priority, this request shouldn't block the release even if its important to do for progress for another feature.
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 ?
As a complement to my previous comment:
In the previous API, the application creation response is in the following form:
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.
The state of the application on each gear can be checked using the gear_groups rest api.
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
Verified this bug with devenv_1762, and PASS.
How is this related to https://bugzilla.redhat.com/show_bug.cgi?id=846166?