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

add version number to newly created datasource object #6178

Merged
merged 8 commits into from
Mar 19, 2024

Conversation

ZilongX
Copy link
Collaborator

@ZilongX ZilongX commented Mar 18, 2024

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 support

Issues Resolved

#6177

Screenshot

  • Unit Test passed

image

  • Demonstration Recording
Screen.Recording.2024-03-18.at.9.21.47.AM.mov

In the recording we demoed two scenarios:

  1. When data source connection checks out, the data source version number is added to the data-source saved object
  2. When data source connection doesn't work, the data source version number will be empty but will not block the creation of data-source saved object

Testing the changes

R1 - 028ae3c - update attribute key from version to dataSourceVersion

image

R2 - 9beabfb - add support and test coverage for custom auth type

image

Check List

  • All tests pass
    • yarn test:jest
    • yarn test:jest_integration
  • New functionality includes testing.
  • New functionality has been documented.
  • Update CHANGELOG.md
  • Commits are signed per the DCO using --signoff

@ZilongX
Copy link
Collaborator Author

ZilongX commented Mar 18, 2024

Will make a video record tomorrow morning ~

Copy link

codecov bot commented Mar 18, 2024

Codecov Report

Attention: Patch coverage is 76.66667% with 7 lines in your changes are missing coverage. Please review.

Project coverage is 67.24%. Comparing base (db9806d) to head (79f59c4).

Files Patch % Lines
..._source/server/routes/fetch_data_source_version.ts 81.25% 3 Missing ⚠️
.../server/routes/data_source_connection_validator.ts 77.77% 1 Missing and 1 partial ⚠️
.../data_source_management/public/components/utils.ts 0.00% 2 Missing ⚠️
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     
Flag Coverage Δ
Linux_1 31.64% <ø> (ø)
Linux_2 55.45% <ø> (ø)
Linux_3 44.72% <76.66%> (+0.01%) ⬆️
Linux_4 35.05% <0.00%> (-0.01%) ⬇️
Windows_1 31.67% <ø> (-0.03%) ⬇️
Windows_2 55.41% <ø> (ø)
Windows_3 44.73% <76.66%> (+0.02%) ⬆️
Windows_4 35.05% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.


return response.ok({
body: {
dataSourceVersion,
Copy link
Member

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

Copy link
Collaborator Author

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

Copy link
Collaborator Author

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

Copy link
Contributor

@yujin-emma yujin-emma left a comment

Choose a reason for hiding this comment

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

LGTM

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
Copy link
Member

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

Copy link
Collaborator Author

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',
Copy link
Member

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.

Copy link
Collaborator Author

@ZilongX ZilongX Mar 18, 2024

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

Flyingliuhub
Flyingliuhub previously approved these changes Mar 18, 2024
try {
// OpenSearch Serverless does not have version concept
if (
this.dataSourceAttr.auth?.credentials?.service === SigV4ServiceName.OpenSearchServerless
Copy link
Collaborator

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 ?

Copy link
Collaborator Author

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)

Copy link
Member

@xinruiba xinruiba Mar 18, 2024

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.

Copy link
Member

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/

Copy link
Collaborator Author

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)

Copy link
Member

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) => {
Copy link
Collaborator

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?

Copy link
Collaborator Author

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

Copy link
Collaborator

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.

Copy link
Member

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() {
Copy link
Collaborator

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?

Copy link
Collaborator Author

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;
Copy link
Collaborator

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?

Copy link
Collaborator Author

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
Copy link
Collaborator

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?

Copy link
Member

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?

Copy link
Collaborator Author

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(
Copy link
Collaborator

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

Copy link
Member

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?

Copy link
Member

Choose a reason for hiding this comment

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

That is a good call out, thanks~
@ZilongX, you may also need to add the same schema validation to the "test_connect.ts" (@BionIT attached) to support registered Auth Type.

Copy link
Collaborator Author

@ZilongX ZilongX Mar 18, 2024

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;
Copy link
Collaborator

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?

Copy link
Collaborator Author

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
Copy link
Member

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(
Copy link
Member

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' });
});
});
Copy link
Member

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?

Copy link
Collaborator Author

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

@xinruiba
Copy link
Member

@ZilongX Thanks for the change.

It will be good if we can also add a video to test registered Auth Type.
Feel free to sync up offline~

Flyingliuhub
Flyingliuhub previously approved these changes Mar 18, 2024
@xinruiba xinruiba self-requested a review March 18, 2024 21:15
@xinruiba
Copy link
Member

xinruiba commented Mar 18, 2024

@ZilongX Thanks for the change.

It will be good if we can also add a video to test registered Auth Type. Feel free to sync up offline~

Synced up with @ZilongX offline and test registered Auth Type together, it works fine.

try {
// OpenSearch Serverless does not have version concept
if (
this.dataSourceAttr.auth?.credentials?.service === SigV4ServiceName.OpenSearchServerless
Copy link
Member

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) => {
Copy link
Member

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({
Copy link
Member

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.

@bandinib-amzn
Copy link
Member

All checks are passing.

@ZilongX ZilongX merged commit daccae7 into opensearch-project:main Mar 19, 2024
68 checks passed
opensearch-trigger-bot bot pushed a commit that referenced this pull request Mar 19, 2024
* 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
ZilongX pushed a commit that referenced this pull request Mar 19, 2024
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

6 participants