-
Notifications
You must be signed in to change notification settings - Fork 916
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
add version number to newly created datasource object #6178
Conversation
Signed-off-by: Zilong Xia <[email protected]>
Will make a video record tomorrow morning ~ |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6178 +/- ##
==========================================
- Coverage 67.26% 67.24% -0.02%
==========================================
Files 3344 3345 +1
Lines 64796 64826 +30
Branches 10427 10432 +5
==========================================
+ Hits 43584 43595 +11
- Misses 18671 18689 +18
- Partials 2541 2542 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
||
return response.ok({ | ||
body: { | ||
dataSourceVersion, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we use dataSourceversion
in the attr? Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, let me update the entry key in the attributes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated entry key from version
to dataSourceVersion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: Zilong Xia <[email protected]>
import { CryptographyServiceSetup } from '../cryptography_service'; | ||
import { registerFetchDataSourceVersionRoute } from './fetch_data_source_version'; | ||
import { AuthType } from '../../common/data_sources'; | ||
// eslint-disable-next-line @osd/eslint/no-restricted-paths |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove this line 17 if we not comment out here. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need this line to pass the lint check for line 18, similar to https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data_source/server/routes/test_connection.test.ts#L17, we may need to find a better way for organizing the imports through
const authRegistry = await authRegistryPromise; | ||
router.post( | ||
{ | ||
path: '/internal/data-source-management/fetchDataSourceVersion', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the user has enabled "compatibility mode" in their cluster, it will always be set to version 7.10.2. While this isn't a blocking issue, it's something we should probably take into consideration. Thank you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice call out ! We've already included this concern in #6177 specifically as
Describe alternatives you've considered
We may need to switch to different api for example leveraging the nodes ones since the compatibility mode might be turned on on the data source domain, yet even that the version number would be locked to 7.10.2 which is supposed to be supported by plugins. We still need to further check with each plugin owners to finalized the use cases and this feature for now is more focusing on getting the version in place first.
While it would need more work including coordination with plugin owners we'll for sure keep it in mind and make the api switch if needed
try { | ||
// OpenSearch Serverless does not have version concept | ||
if ( | ||
this.dataSourceAttr.auth?.credentials?.service === SigV4ServiceName.OpenSearchServerless |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we will support other authentication types, I wonder how determine if the data source is serverless or on premise, or open search cluster, can we use the attributes.auth.credentials.service to determine the service type. Any suggestions @bandinib-amzn @xinruiba ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah would like to learn more on the serverless/premise side, actually we may need to add another attri entry say dataSource type maybe (OS | OS Serverless | On Premise)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use attributes.auth.credentials.service
to determine the service type for sigV4 dataSources.
This attribute, as far as I know, only has effect on how to deal with credentials in server side. But I don't think we add this server type as an attribute of our datasource object.
And for NoAuth and UserName&&PassWord auth, we don't set attributes.auth.credentials.service
attribute, which means those dataSources will by default treated as server domain here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking if the server type is a must have, are we able to decide the service type based on the open-search endpoint format?
Like server endpoint (have es):
https://someurl.region.es.amazonaws.com/
Serverless endpoint (have aoss):
https://someurl.region.aoss.amazonaws.com/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call out ! Let me check further on above when adding the dataSourceType to data-source (in case it's needed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now service is at authentication
level. It is only being used when auth method is SigV4. We can move service parameter to data source level. As it sounds simple, it will need refactoring and testing of existing functionality. @ZilongX Can you create an issue to track?
await this.callDataCluster | ||
.info() | ||
.then((response) => response.body) | ||
.then((body) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we use await already, do we still need to use then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes here just leverage the thenable to further trim the body keeping only required entries
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's redundant to use both await and then in the same function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
nit:
clusterInfo = await this.callDataCluster.info();
if (clusterInfo?.statusCode === 200 && clusterInfo?.body) {
dataSourceVersion = clusterInfo.version.number;
}
return dataSourceVersion;
@@ -35,4 +35,27 @@ export class DataSourceConnectionValidator { | |||
throw createDataSourceError(e); | |||
} | |||
} | |||
|
|||
async fetchDataSourceVersion() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be called fetchDataSourceMetadata or do we want to create another API to fetch enabled plugins?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, this is just the first step to fetch the version number, next one is to fetch the installed plugins which would be consolidated into one method say fetchDataSourceMetadata with multiple api calls behind the scene
@@ -140,6 +140,7 @@ export interface DataSourceAttributes extends SavedObjectAttributes { | |||
title: string; | |||
description?: string; | |||
endpoint?: string; | |||
dataSourceVersion?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is another DataSourceAttributes interface in data source plugin, should we update there as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes but maybe later, that one seems to be leveraged for data source display page, this one is focusing on the saving part, we may need to display the version number on the datasource list page, with some UI updates as well, will need to check further.
export async function fetchDataSourceVersion( | ||
http: HttpStart, | ||
{ endpoint, auth: { type, credentials } }: DataSourceAttributes, | ||
dataSourceID?: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should data source id be required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is optional because of test connection. Because if we do test connection before saving data source, we won't have data source id. But what will happen if it empty or undefined? Does it throw error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just tested and it won't cause any exception :) further digging indicates a maybe checkid: schema.maybe(schema.string()),
so an empty one won't cause trouble for now
id: schema.maybe(schema.string()), | ||
dataSourceAttr: schema.object({ | ||
endpoint: schema.string(), | ||
auth: schema.maybe( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for auth, I think we are introducing custom auth types, thus need to be similar to https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data_source/server/routes/test_connection.ts#L56, @xinruiba might have more context
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. @ZilongX can you add schema validation for custom auth type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice call out, let me add the validation for custom auth type
}, | ||
}, | ||
async (context, request, response) => { | ||
const { dataSourceAttr, id: dataSourceId } = request.body; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since data source id is optional, how do we handle undefined data source id here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as the test connection call , dataSourceId is actually needed for the OS API call but more on the MD internal side for validation to make sure the call is actually triggered by data source creation.
export async function fetchDataSourceVersion( | ||
http: HttpStart, | ||
{ endpoint, auth: { type, credentials } }: DataSourceAttributes, | ||
dataSourceID?: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is optional because of test connection. Because if we do test connection before saving data source, we won't have data source id. But what will happen if it empty or undefined? Does it throw error?
id: schema.maybe(schema.string()), | ||
dataSourceAttr: schema.object({ | ||
endpoint: schema.string(), | ||
auth: schema.maybe( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. @ZilongX can you add schema validation for custom auth type?
.expect(200); | ||
expect(result.body).toEqual({ dataSourceVersion: '2.11.0' }); | ||
}); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please add test case for cutsom auth as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let me add the validation and test for custom auth
Signed-off-by: Zilong Xia <[email protected]>
@ZilongX Thanks for the change. It will be good if we can also add a video to test registered Auth Type. |
Signed-off-by: ZilongX <[email protected]>
try { | ||
// OpenSearch Serverless does not have version concept | ||
if ( | ||
this.dataSourceAttr.auth?.credentials?.service === SigV4ServiceName.OpenSearchServerless |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now service is at authentication
level. It is only being used when auth method is SigV4. We can move service parameter to data source level. As it sounds simple, it will need refactoring and testing of existing functionality. @ZilongX Can you create an issue to track?
await this.callDataCluster | ||
.info() | ||
.then((response) => response.body) | ||
.then((body) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
nit:
clusterInfo = await this.callDataCluster.info();
if (clusterInfo?.statusCode === 200 && clusterInfo?.body) {
dataSourceVersion = clusterInfo.version.number;
}
return dataSourceVersion;
{ | ||
path: '/internal/data-source-management/fetchDataSourceVersion', | ||
validate: { | ||
body: schema.object({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Now the code for request payload validation duplicate. We should be reusing the same code to remove duplicate code. I think we can define schema to separate parameter and use here and in test data connection.
All checks are passing. |
* add version number to newly created datasource object Signed-off-by: Zilong Xia <[email protected]> * update attribute key from version to dataSourceVersion Signed-off-by: Zilong Xia <[email protected]> * add support and test coverage for custom auth type Signed-off-by: Zilong Xia <[email protected]> * fix ciGroup3 test case suite Create Datasource Wizard Signed-off-by: Zilong Xia <[email protected]> --------- Signed-off-by: Zilong Xia <[email protected]> Signed-off-by: ZilongX <[email protected]> (cherry picked from commit daccae7) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> # Conflicts: # CHANGELOG.md
* add version number to newly created datasource object Signed-off-by: Zilong Xia <[email protected]> * update attribute key from version to dataSourceVersion Signed-off-by: Zilong Xia <[email protected]> * add support and test coverage for custom auth type Signed-off-by: Zilong Xia <[email protected]> * fix ciGroup3 test case suite Create Datasource Wizard Signed-off-by: Zilong Xia <[email protected]> --------- Signed-off-by: Zilong Xia <[email protected]> Signed-off-by: ZilongX <[email protected]> (cherry picked from commit daccae7) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> # Conflicts: # CHANGELOG.md Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Description
This change is the first step per RFC [RFC] Plugins Version Decoupling #5877 aiming at decouple the strict version constrains between OSD Core and Plugins
To make it happen this first step change is to include the data source version number in the newly created
data-source
object which would be consumed by plugins as part of the proof for determining version supportIssues Resolved
#6177
Screenshot
Screen.Recording.2024-03-18.at.9.21.47.AM.mov
In the recording we demoed two scenarios:
Testing the changes
R1 - 028ae3c -
update attribute key from version to dataSourceVersion
R2 - 9beabfb -
add support and test coverage for custom auth type
Check List
yarn test:jest
yarn test:jest_integration