[Plugin Dev] Domain parsing seems wrong in GetApp model

[emirozer]

Hi @krishicks & @simonleung8 ,

I am trying to access the Domain field in GetApp_RouteSummary:
https://github.com/cloudfoundry/cli/blob/master/plugin/models/get_app.go#L46

No matter for which app i try i always get this result : { false}

Example of what routes strutct has:

[{92222bca-952e-11e5-9166-507b9d5e74f4 emir {   false}}]

I than did, export CF_TRACE=true, checked the json response and voila:

"domain":{  
            "guid":"92222bca-952e-11e5-9166-507b9d5e74f4",
            "name":"cfapps.io"
         }

I believe the marshalling of that structs domain part might have a bug, couldnt pin point where exactly the response gets marshalled into that struct..

OS: Ubuntu 15.10
Go version: 1.5.1
CF version: 6.14
Running on Pivotal Web Services

Best,

Emir

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/109080260.

[emirozer]

So i can see that domain key does not have following variables:

OwningOrganizationGuid string
Shared                 bool

https://github.com/cloudfoundry/cli/blob/master/plugin/models/get_app.go#L55

maybe somewhere there is a 1-on-1 conversion try that fails

[krishicks]

Hi @emirozer,

You're right that the field is not being populated properly. This is because the API does not actually return us those fields; we're not sure why the struct member is even defined.

The API endpoint we're hitting in GetApp is https://apidocs.cloudfoundry.org/226/apps/get_app_summary.html. There is another endpoint for domains which might have given us the shared/not-shared information, https://apidocs.cloudfoundry.org/226/domains_(deprecated)/retrieve_a_particular_domain_(deprecated).html, but it is deprecated.

Could you explain what your use case here is, so we can see if there's another solution we could provide you?

[emirozer]

Hey Kris,

Thanks for the response !

We found a work around thankfully, my use case is simply to get the app's URI information and i assumed after reading this doc: https://github.com/cloudfoundry/cli/blob/master/plugin_examples/DOC.md

GetApp seems the way to reach that information...
But yeah unfortunately through any interface in that page one cannot retrieve an app's URI.

The workaround we found is:

results, err := cliConnection.CliCommandWithoutTerminalOutput("app", appName)

[krishicks]

Hi @emirozer,

I think you should be able to get the information you want from the GetAppModel. You just need to put together the host and the domain name to acquire the URI for each route.

E.g. given this response:

{
  "guid": "48f1c0cb-8620-4487-ad6d-8853656469b3",
  "name": "name-1827",
  "routes": [
    {
      "guid": "acabd696-ef02-4f54-89f8-befc4717876f",
      "host": "host-13",
      "domain": {
        "guid": "11430e5f-3de9-4f72-bf13-ba037bad9893",
        "name": "domain-28.example.com"
      }
    }
  ],
...snip...

You should be able to iterate through the GetAppModel struct's Routes, concatenating the route.Host and route.Domain.Name fields. Does that not work?

[emirozer]

I will check that and give feedback here!

[emirozer]

Wait haha, that was exactly the problem, route.Host is populated but route.Domain.Name isn't :)

[krishicks]

What version of CC are you targeting?

[emirozer]

(API version: 2.44.0)

[krishicks]

Thanks for the extra information.

It is definitely a bug in the cli. The problem is due to us making multiple API calls and constructing the app object that gets passed back to the CLI with the wrong API response object.

The first API call we do to get information about the app is /v2/spaces/:space-guid/apps?q=:app-name&inline-relations-depth=1. This corresponds to this API endpoint: https://apidocs.cloudfoundry.org/226/spaces/list_all_apps_for_the_space.html

We get an entity back that has some information about the app, but not as much information as we'd get from /v2/apps/:guid/summary (https://apidocs.cloudfoundry.org/226/apps/get_app_summary.html)

On https://github.com/cloudfoundry/cli/blob/master/cf/commands/application/app.go#L85, you'll see that we call populatePluginModel with the response from the first API call. The application we should be using is retrieved just below, in the call to ShowApp, where the second API call is made: https://github.com/cloudfoundry/cli/blob/master/cf/commands/application/app.go#L103

One reason for the two calls is possibly that we just don't have the guid of the app, in which case we should only make the first call to acquire the guid, and then not use that response object anymore. But it may be the case that the first response object has information that the latter does not.

[dkoper]

Fixed in our edge release.

[xchapter7x]

tested on HEAD master. works for me.
Thanks :)