Skip to content
This repository has been archived by the owner on Oct 28, 2024. It is now read-only.

Service definition example does not load #90

Open
arcenik opened this issue Apr 26, 2018 · 3 comments
Open

Service definition example does not load #90

arcenik opened this issue Apr 26, 2018 · 3 comments

Comments

@arcenik
Copy link
Contributor

arcenik commented Apr 26, 2018

Problem

The serviceDefinitions provided in the README.md file cannot be loaded and cause an internal error.

Reproduce

  • Extract the yaml from the README.md file and save on a file like test-service.yml
  • Run the curl command

Result

$ curl -u 'cc_ext:change_me' \
  -X POST \
  -H 'Content-Type: application/json' \
  --data-binary '@./test-service.yml' \
  http://localhost:8080/custom/admin/service-definition  ; echo
{"code":null,"description":"Internal Server Error","error_code":null}

And the logs from the osb:

2018-04-26 09:39:19.668  INFO 78 --- [nio-8080-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring FrameworkServlet 'dispatcherServlet'
2018-04-26 09:39:19.668  INFO 78 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization started
2018-04-26 09:39:19.682  INFO 78 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization completed in 13 ms
2018-04-26 09:39:19.865 ERROR 78 --- [nio-8080-exec-1] c.s.c.s.b.controller.BaseController      : Uncaught error

java.lang.NumberFormatException: null
  at java.math.BigDecimal.<init>(BigDecimal.java:494) ~[na:1.8.0_162]
  ...
  at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) ~[groovy-all-2.4.7.jar:2.4.7]
  at com.swisscom.cloud.sb.broker.servicedefinition.ServiceDefinitionProcessor.createOrUpdateServiceDefinition(ServiceDefinitionProcessor.groovy:64) ~[main/:na]
  at com.swisscom.cloud.sb.broker.servicedefinition.ServiceDefinitionProcessor$$FastClassBySpringCGLIB$$be964f84.invoke(<generated>) ~[main/:na]
  ...

The complete backtrace

@ampersand8
Copy link
Contributor

The example from the README refers to configuring the service-definition in the application.yml. To update/create the service-definition with the API endpoint, you'll have to provide a JSON. So you can convert parts of the example to JSON, which should then work.

So the example JSON would look like this:

{
    "guid": "udn9276f-hod4-5432-vw34-6c33d7359c12",
    "name": "mongodbent",
    "description": "MongoDB Enterprise HA v3.2.11",
    "bindable": true,
    "asyncRequired": true,
    "internalName": "mongoDbEnterprise",
    "displayIndex": 1,
    "tags": [],
    "metadata": {
      "version": "3.2.11",
      "displayName": "MongoDB Enterprise"
    },
    "plans": [
      {
        "guid": "jfkos87r-truz-4567-liop-dfrwscvbnmk6",
        "name": "replicaset",
        "description": "Replica Set with 3 data bearing nodes with 32 GB memory, 320 GB storage, unlimited concurrent connections",
        "templateId": "mongodbent-bosh-template",
        "free": false,
        "displayIndex": 0,
        "containerParams": [
          {
            "template": "",
            "name": "plan",
            "value": "mongoent.small"
          },
          {
            "template": "",
            "name": "vm_instance_type",
            "value": "mongoent.small"
          }
        ],
        "metadata": {
          "storageCapacity": "320GB",
          "memory": "32GB",
          "nodes": "3",
          "maximumConcurrentConnections": "unlimited",
          "dedicatedService": true,
          "highAvailability": true,
          "displayName": "Small"
        }
      }
    ]
}

The README is unclear where and how this service-definition should be loaded. We'll update this section to clear it up.

@arcenik
Copy link
Contributor Author

arcenik commented Apr 26, 2018

Ok, so when passing JSON instead of YML this is working 👍 .
But this is not a reason to crash and return a 500/internal error.
It should instead return a 400/bad request, JSON decode failed.

The same when you do a get on non existing resource that make the server crash instead of returning a 404.

@ampersand8
Copy link
Contributor

Yeah, good catch. 500 is defintely wrong in those cases.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants