Skip to content

Conversation

Cryptophobia
Copy link
Member

We noticed that the api was giving great exceptions when you make a request that fails, but we would like to store those detailed exceptions up to the release api object for version of the release on which they occurred. Similar to how failed=True is available on the release api object, there should be a field called exception containing the exception msg from the deis-controller when a release or build fails.

Let's say we make a /scale post request to POST http://deis.192.168.99.100.nip.io/v2/apps/testing-application/scale with the following payload:

{"cmd": 10}

With this PR, when a release fails this is the example of how the release api response will look:

GET http://deis.192.168.99.100.nip.io/v2/apps/testing-application/releases

{
    "count": 37,
    "next": null,
    "previous": null,
    "results": [
        {
            "uuid": "2f104d63-a023-466d-9023-fb77aad75556",
            "app": "testing-application",
            "owner": "admin",
            "created": "2017-08-28T15:28:01Z",
            "updated": "2017-08-28T15:32:07Z",
            "version": 37,
            "summary": "admin deployed a config that failed",
            "failed": true,
            "exception": "error: (app::deploy): (app::deploy): There was a problem while deploying v36 of testing-application-cmd. Additional information:\nNo nodes are available that match all of the following predicates:: Insufficient cpu (1).",
            "config": "c0d45750-1c5d-4c39-a72e-ae3cf9990d6c",
            "build": "3dca0365-e51b-4d8c-988e-2487cc9a179a"
        },
        {
            "uuid": "a265ac6d-980b-457f-af66-e4d081cd9637",
            "app": "testing-application",
            "owner": "admin",
            "created": "2017-08-28T15:23:57Z",
            "updated": "2017-08-28T15:23:57Z",
            "version": 36,
            "summary": "admin changed lifecycle_post_start cmd",
            "failed": false,
            "exception": null,
            "config": "47561aca-8017-4952-aa6b-5fa0a415a398",
            "build": "3dca0365-e51b-4d8c-988e-2487cc9a179a"
        }
...

With this small change we get a detailed message in the api telling us why a certain release failed that is more detailed than the summary message. As a benefit it is stored on the release API object rather than just given as a response to our API calls:

"exception": "error: (app::deploy): (app::deploy): There was a problem while deploying v36 of testing-application-cmd. Additional information:\nNo nodes are available that match all of the following predicates:: Insufficient cpu (1)."

@Cryptophobia
Copy link
Member Author

Cryptophobia commented Sep 21, 2017

This PR is related to this upstream PR:

deis/controller#1325

@Cryptophobia Cryptophobia requested a review from tmedford October 11, 2017 23:06
Cryptophobia added a commit that referenced this pull request Nov 13, 2017
@Cryptophobia Cryptophobia merged commit aef1f6b into master Nov 13, 2017
kingdonb pushed a commit to kingdonb/controller that referenced this pull request Aug 6, 2019
Refactoring for new KubeHTTPClient.version() behavior
kingdonb pushed a commit to kingdonb/controller that referenced this pull request Aug 6, 2019
Refactoring for new KubeHTTPClient.version() behavior
duanhongyi added a commit to duanhongyi/controller that referenced this pull request Jan 3, 2021
…o-1.11.21

chore(deps): bump django from 1.11.20 to 1.11.21 in /rootfs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants