Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Merge-on-date: (TBA)] Add container log APIs to WebApps.json #1681

Merged
merged 5 commits into from
Dec 8, 2017
Merged

[Merge-on-date: (TBA)] Add container log APIs to WebApps.json #1681

merged 5 commits into from
Dec 8, 2017

Conversation

michimune
Copy link
Contributor

@michimune michimune commented Sep 13, 2017

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.

PR information

  • The title of the PR is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
  • Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
  • If applicable, the PR references the bug/issue that it fixes.
  • Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

@fearthecowboy fearthecowboy added the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Sep 13, 2017
"tags": [
"WebApps"
],
"summary": "Gets the last lines of docker logs for the given site",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did you want to add an appropriate produces element? (see IANA Media Types )

 "produces": [
     "text/plain"
  ],

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Copy link
Contributor

@jianghaolu jianghaolu Sep 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please let me know if I'm missing something here but this endpoint does seem to work for me:

POST https://management.azure.com/subscriptions/ffa52f27-be12-4cad-b1ea-c2c241b6cceb/resourceGroups/linux-test-appgroup/providers/Microsoft.Web/sites/linux-test-app/containerlogs?api-version=2016-08-01
405 Method Not Allowed 749.00 ms
{
  "error": {
    "Message": "The requested resource does not support http method 'POST'."
  }
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The deployment to production happened two weeks ago. I have confirmed it working with my testa pp. Can you please try again?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the endpoint is returning a base 64 encoded content - in this case, the return type shouldn't be file but byte. The file response type should be unencoded (gzipped okay).

Also, the server is actually returning me application/json for content type.

],
"summary": "Gets the last lines of docker logs for the given site",
"description": "Gets the last lines of docker logs for the given site",
"operationId": "WebApps_GetWebSiteContainerLogs",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And maybe here too?

 "produces": [
     "application/zip"
  ],

(and for the other APIs too...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for this one - get application/json for content type, which probably requires a server-side fix and the response should be byte.

Copy link
Member

@fearthecowboy fearthecowboy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good to me; you might want to add produces on the APIs

Also, new APIs require signoff from ARM.

Adding @ravbhatnagar for his blessing.

}
}
},
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/containerlogs/zip": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing segments. containerLogs is the resource type as per the signature. So you need a resourceTypename segment on which you will call zip action. A better way to model this API would be return a pointer to storage blob where the zip can be downloaded from. We generally avoid content other than application/json flowing through ARM.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I see. Just to share the history. We initially used GET for this API but changed to POST based on suggestions from the CSM team (In order to return a byte stream). So zip was originally meant to be a resource type name.
Unfortunately returning a pointer to storage blob isn't our option because the zip is pointed to by a SCM URL where basic auth is used. We need to avoid returning a URL containing a clear password. Another possibility is that we store zip contents into storage blob which is specified by a command line parameter. However this could introduce more complexity to how the API is used.

We will revisit later for better modeling. For now, we would slightly change the signature by appending /download (i.e. ".../containerlogs/zip/download"). Does this make more sense?

@@ -1913,6 +1913,84 @@
}
}
},
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/containerlogs": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be rename the action to getContainerLogs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to add a new getContainerLogs later, but as of now we would like to keep the name.

@ravbhatnagar ravbhatnagar added ReadyForSDKReview and removed WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required labels Sep 14, 2017
@fearthecowboy fearthecowboy added the Reviewed-ChangesRequested <valid label in PR review process>add this label when assignee request changes after review label Sep 14, 2017
@azuresdkciprbot
Copy link

Hi There,

I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:

File: specification/web/resource-manager/readme.md
Before the PR: Warning(s): 1860 Error(s): 105
After the PR: Warning(s): 1870 Error(s): 105

AutoRest Linter Guidelines | AutoRest Linter Issues

Send feedback and make AutoRest Linter Azure Bot smarter day by day!

Thanks for your co-operation.

@fearthecowboy
Copy link
Member

When @ravbhatnagar gives his ascent to your feedback, I can merge this.

}
},
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/containerlogs/zip/download": {
"post": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this one

POST https://management.azure.com/subscriptions/ffa52f27-be12-4cad-b1ea-c2c241b6cceb/resourceGroups/linux-test-appgroup/providers/Microsoft.Web/sites/linux-test-app/containerlogs/zip/download?api-version=2016-08-01
404 Not Found
The response was empty

@salameer
Copy link
Member

@michimune and @ravbhatnagar

What are the update on this PR?

@Azure Azure deleted a comment from msftclas Sep 27, 2017
"tags": [
"WebApps"
],
"summary": "Gets the last lines of docker logs for the given site",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the endpoint is returning a base 64 encoded content - in this case, the return type shouldn't be file but byte. The file response type should be unencoded (gzipped okay).

Also, the server is actually returning me application/json for content type.

],
"summary": "Gets the last lines of docker logs for the given site",
"description": "Gets the last lines of docker logs for the given site",
"operationId": "WebApps_GetWebSiteContainerLogs",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for this one - get application/json for content type, which probably requires a server-side fix and the response should be byte.

@michimune
Copy link
Contributor Author

I can change the response schema type, but I have no idea how to specify the content type. I will need some investigation. Any advice would be helpful.

@jianghaolu
Copy link
Contributor

@michimune It's a service issue - can you report to the service owner? The issue is these 2 APIs are sending non-JSON content with application/json content type header.

@azuresdkciprbot
Copy link

Hi There,

I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:

File: specification/web/resource-manager/readme.md
Before the PR: Warning(s): 0 Error(s): 88
After the PR: Warning(s): 0 Error(s): 0

AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback

Thanks for your co-operation.

Copy link
Contributor

@jianghaolu jianghaolu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The specs are approved. Waiting for the changes to be deployed to production.

@ravbhatnagar
Copy link
Contributor

Looks good for ARM. Lets merge once the changes are deployed to prod.

@ravbhatnagar ravbhatnagar added ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review and removed ReadyForSDKReview labels Oct 31, 2017
@fearthecowboy
Copy link
Member

@michimune -- When is the expected date this will deployed to production?

@fearthecowboy fearthecowboy removed the Reviewed-ChangesRequested <valid label in PR review process>add this label when assignee request changes after review label Dec 8, 2017
@fearthecowboy fearthecowboy changed the title Add container log APIs to WebApps.json [Merge-on-date: (TBA)] Add container log APIs to WebApps.json Dec 8, 2017
@jianghaolu
Copy link
Contributor

@fearthecowboy I just verified this is live now.

@fearthecowboy fearthecowboy merged commit 58b5052 into Azure:current Dec 8, 2017
@fearthecowboy
Copy link
Member

Thanks @jianghaolu ... merged!

@AutorestCI
Copy link

@AutorestCI
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARMSignedOff <valid label in PR review process>add this label when ARM approve updates after review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants