Adding api endpoints for resources to heat api

[drmaas]

No description provided.

[drmaas]

@vinodborole PTAL when you get a chance.

[vinodborole]

Thanks @drmaas for this, the code looks good. Is it possible for you add few test cases for the resource health use case?

[auhlig]

In addition to Vinods comment: Could you resolve the conflicts and stick to the import style in core/src/main/java/org/openstack4j/api/Builders.java? @drmaas

[drmaas]

Will address comments.

[drmaas]

@vinodborole @auhlig added tests - PTAL

[vinodborole]

LGTM, @auhlig can you have a look once; especially the json files used for test cases

[auhlig]

Yeah. I get what you mean Vinod: d69e213#diff-8159b497a2f70e96643a4d320903a5bbR2 makes no sense.

[auhlig]

But the rest of the code looks good.

[drmaas]

@auhlig what makes no sense?

If you are referring to patchWithResponse and postWithResponse, I return an ActionResponse so that the response code can be obtained to check the status, because the responses return no data.

If you are referring to the json files themselves, what would be a better set of test data to use? The resource response is an example of actual metadata returned from a stack resource. The signal json is made up, since I have no context for what a real payload would look like.

Or are you saying that the signal api does not accept a request body?

[auhlig]

Hi @drmaas ,
Right. I meant { foo: bar } in the request body I quoted above. Maybe some of the attributes described here http://developer.openstack.org/api-ref/orchestration/v1/index.html#send-a-signal-to-a-resource (see Request Parameters) would make more sense.

While reading the the API documentation I was wondering, where the tenant_id in the path /v1/{tenant_id}/stacks/{stack_name}/{stack_id}/resources/{resource_name}/signal is coming from as the path you're using starts with stacks/...?
I can see that the path lacking the tenant_id is used in the whole ResourcesServiceImpl, so could we check which path is correct?

[drmaas]

@auhlig I tested out all of the endpoints in ResourcesServiceImpl against our Mitaka install. They all do use the tenant (project id) in the URI path that is baked into the client when the client (v2 or v3) is built. This seems to be the pattern for all Openstack4j api calls - automatically use the project id that was specified at client build time. I've seen instances where the docs are wrong.

You're right about no payload needing to be sent - I will update the PR.

[auhlig]

Interesting. Thanks for sharing the info. Could you also submit a PR to update the docs? That would be much appreciated!

Besides this PR looks good. What do you think @vinodborole?

[drmaas]

@auhlig http://developer.openstack.org/api-ref/orchestration/v1/index.html#stack-resources looks correct to me (tenant id is in the path for all endpoints) - are you referring to something else?

[auhlig]

I'm referring to our docs :)

[drmaas]

@auhlig @vinodborole issue submitted

[auhlig]

Thanks. I guess it's ready to merge, right @vinodborole? If so please merge

[vinodborole]

Yes @auhlig it is good to merge now, thanks a lot @drmaas for this contribution 👍