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

[TimeSeriesInsights] Query categorical variable and warm store query parameter changes #7609

Conversation

yeskarthik
Copy link
Contributor

@yeskarthik yeskarthik commented Oct 23, 2019

Latest improvements:

MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.

Contribution checklist:

  • I have reviewed the documentation for the workflow.
  • Validation tools were run on swagger spec(s) and have all been fixed in this PR.
  • The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

  • Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
  • adding/removing APIs.
  • adding/removing properties.
  • adding/removing API-version.
  • adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

  • If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
    Please follow the link to find more details on API review process.

sandshadow and others added 30 commits January 9, 2018 17:03
Fix R2016 by making PATCH body properties optional. Suppress the remaining 4 violations that are confirmed as false positives.
…Prop

Added dataStringComparisonBehavior parameter to reference data put/update spec
…onKeyProperty

Adding partitionKeyProperty to EnvironmentCreate and EnvironmentGet request.
…lingAsString

changing modelAsString for partitionKeyPRoperties
Introduce longterm environment to TSI resource hierarchy
@azuresdkci azuresdkci requested a review from lirenhe October 23, 2019 22:40
@azuresdkci
Copy link
Contributor

Can one of the admins verify this patch?

@lirenhe lirenhe added the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Oct 24, 2019
@lirenhe
Copy link
Member

lirenhe commented Oct 24, 2019

@yeskarthik, please take a look at and fix the Avocado and spell check error.

@lirenhe lirenhe added Changes Required WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required and removed WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required labels Oct 24, 2019
@yeskarthik
Copy link
Contributor Author

@lirenhe I fixed the comments, can you please complete the PR? Thanks.

@yeskarthik
Copy link
Contributor Author

#sign-off

@yeskarthik
Copy link
Contributor Author

@lirenhe can you please complete the PR?

@lirenhe
Copy link
Member

lirenhe commented Oct 28, 2019

@lirenhe can you please complete the PR?

Please wait for ARM to signoff this PR

@yeskarthik
Copy link
Contributor Author

@lirenhe this is not an ARM API, this is data access API, they usually don't sign off these changes. @deepakpalled

@yeskarthik
Copy link
Contributor Author

yeskarthik commented Oct 28, 2019

I'm going to be adding one more minor change.

@lirenhe lirenhe removed the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Oct 29, 2019
@yeskarthik yeskarthik requested a review from lirenhe October 29, 2019 02:28
@lirenhe lirenhe added the APIStewardshipBoard-ReviewRequested This should be reviewed by the Azure API Stewardship team in partnership with the service team. label Oct 29, 2019
@yeskarthik
Copy link
Contributor Author

yeskarthik commented Oct 29, 2019

@Azure/azure-api-review-board can you please verify and merge these changes? These changes are already deployed and live. These are updates the existing APIs and only swagger changes. This does not contain any SDK changes.

@lirenhe lirenhe removed the APIStewardshipBoard-ReviewRequested This should be reviewed by the Azure API Stewardship team in partnership with the service team. label Oct 30, 2019
@lirenhe lirenhe merged commit 5a6b507 into Azure:master Oct 30, 2019
@AutorestCI
Copy link

AutorestCI commented Oct 30, 2019

Automation for azure-sdk-for-python

Encountered a Subprocess error: (azure-sdk-for-python)

Command: ['/usr/local/bin/autorest', '/tmp/tmpxfttb9e4/rest/specification/timeseriesinsights/data-plane/readme.md', '--perform-load=false', '--swagger-to-sdk', '--output-artifact=configuration.json', '--input-file=foo', '--output-folder=/tmp/tmpo0frri75']
Finished with return code 7
and output:

AutoRest code generation utility [version: 2.0.4283; node: v8.12.0]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
Failure:
Error: Unable to start AutoRest Core from /root/.autorest/@microsoft.azure_autorest-core@2.0.4405/node_modules/@microsoft.azure/autorest-core
Error: Unable to start AutoRest Core from /root/.autorest/@microsoft.azure_autorest-core@2.0.4405/node_modules/@microsoft.azure/autorest-core
    at main (/opt/node_modules/autorest/dist/app.js:232:19)
    at <anonymous>

/root/.autorest/@microsoft.azure_autorest-core@2.0.4405/node_modules/@microsoft.azure/autorest-core/dist/app.js:33
    autorest_core_1.Shutdown();
    ^
ReferenceError: autorest_core_1 is not defined
    at process.on (/root/.autorest/@microsoft.azure_autorest-core@2.0.4405/node_modules/@microsoft.azure/autorest-core/dist/app.js:33:5)
    at emitOne (events.js:121:20)
    at process.emit (events.js:211:7)
    at process.emit (/node_modules/source-map-support/source-map-support.js:439:21)
fs.js:612
  return binding.close(fd);
                 ^

Error: EBADF: bad file descriptor, close
    at Object.fs.closeSync (fs.js:612:18)
    at StaticVolumeFile.shutdown (/opt/node_modules/autorest/dist/static-loader.js:352:10)
    at StaticFilesystem.shutdown (/opt/node_modules/autorest/dist/static-loader.js:406:17)
    at process.exit.n [as exit] (/opt/node_modules/autorest/dist/static-loader.js:169:11)
    at printErrorAndExit (/node_modules/source-map-support/source-map-support.js:423:11)
    at process.emit (/node_modules/source-map-support/source-map-support.js:435:16)
    at process._fatalException (bootstrap_node.js:391:26)

"description": "The list of values that a category maps to. Can be either a unique list of string or list of long.",
"type": "array",
"items": {
"type": "object"
Copy link
Member

Choose a reason for hiding this comment

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

The description and swagger are in disagreement as to what the types can be here. A string or integer in swagger/openapi are not objects.

"$ref": "#/definitions/TimeSeriesAggregateCategory"
}
},
"defaultCategory": {
Copy link
Member

Choose a reason for hiding this comment

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

Is there a specific reason as to why the type of defaultCatgory is a complex object with a single attribute?

"required": false,
"type": "string",
"x-ms-parameter-location": "method",
"description":"For the environments with warm store enabled, the query can be executed either on the 'WarmStore' or 'ColdStore'. This parameter in the query defines which store the query should be executed on. If not defined, the query will be executed on the cold store."
Copy link
Member

Choose a reason for hiding this comment

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

Specify default?

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.

9 participants