-
Notifications
You must be signed in to change notification settings - Fork 0
added s3 extended apis #6
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
Conversation
6e52335 to
3768de7
Compare
a92e028 to
fe8be88
Compare
models/extended/searchBucket.smithy
Outdated
|
|
||
| @http(method: "GET", uri: "/{Bucket}") | ||
| @readonly | ||
| operation SearchBucket { |
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.
this is called ListObjects in s3:
- should we not call this
SearchObjects? - or even just keep the name
ListObjectseven if we have extra params for searching?
(similar for ListObjectsV2 and ListObjectVersions below)
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 reused the same names we had before for the migration, but I agree we can use official ones, and the frontend will adapt, they will have to change code anyway.
I will just add an "extended" keyword at the end to differentiate, otherwise its gonna be troublesome to differentiate official api from extended one :
ListObjects -> ListObjectsExtended
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.
maybe ListObjectsEx for brevity ? or ListObjectsScal / ScalListObjects ?
package.json
Outdated
| "build:generated": "cd build/smithy/cloudserver/typescript-codegen && yarn install && yarn build", | ||
| "build:generated:bucketQuota": "cd build/smithy/cloudserverBucketQuota/typescript-codegen && yarn install && yarn build", | ||
| "build:generated:s3extended": "cd build/smithy/cloudserverS3Extended/typescript-codegen && yarn install && yarn build", |
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 we have a single step, maybe something like:
"build:generated": "echo build/smithy/*/typescript-codegen | xargs 'cd {} && yarn install && yarn build'"
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 don't know current solution is longer but quite simple compared to this
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 is more error-prone, as we risk not-generating some modules, and need to call multiple "targets"
package.json
Outdated
| "test:indexes": "jest tests/testIndexesApis.test.ts", | ||
| "test:error-handling": "jest tests/testErrorHandling.test.ts", | ||
| "test:multiple-backend": "jest tests/testMultipleBackendApis.test.ts", | ||
| "test:api": "jest tests/testApis.test.ts", | ||
| "test:lifecycle": "jest tests/testLifecycleApis.test.ts", | ||
| "test:metadata": "jest tests/testMetadataApis.test.ts", | ||
| "test:raft": "jest tests/testRaftApis.test.ts", | ||
| "test:bucketQuotas": "jest tests/testQuotaApis.test.ts", | ||
| "test:mongo-backend": "yarn test:indexes && yarn test:error-handling && yarn test:multiple-backend && yarn test:bucketQuotas", | ||
| "test:s3Extended": "jest tests/testS3ExtendedApis.test.ts", |
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.
do we really need these?
the same can be done easily from CLI: yarn test tests/testIndexesApis.test.ts for exemple...
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 understand not all tests work with every backend, but this approach:
- requires lots of "maintenance" when adding test suites
- has a high risk of breaking (forgetting to add a test suite & run it in CI)
- does not spare developer either, as they will run the same thing as CI... and we could miss issues altogether
Maybe a more scalable approach would be to "skip" some tests depending on the backend ? e.g.
yarn testruns all tests- the backend (mongo/metadata) is detected via environment variables or cloudserver api calls
- in the test code (in typescript), skip tests if they are not relevant for the backend
- also implement some extra test to verify the API fails with "not implemented" (I guess?) when used with the incorrect backend : e.g. metadata search or index with metadata backend, or metadata api with mongo...
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 added some kind of utility to override describe(), that will skip the test based on a new env variable
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.
Filtering tests a feature of jest : just need to add params ; and any params passed to yarn test is appended to the command of the script.
So we you have a script "test" : "jest",
yarn testwill run all tests with jestyarn test tests/testIndexesApis.test.tswill only run the tests in testIndexesApis.test.ts
i.e. carefully choosing the scripts and associated command gives lots of flexibility without any workaround...
d2aa0ac to
e099139
Compare
783b446 to
7271bad
Compare
Hello sylvainsenechal,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
b8fa310 to
18d257e
Compare
|
|
||
| @http(method: "GET", uri: "/{Bucket}?list-type=2") | ||
| @readonly | ||
| operation SearchBucketV2 { |
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.
As this is a listing I think we should find a better naming for this
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.
yep, I updated it
18d257e to
376adb7
Compare
0bb8e63 to
402e02c
Compare
402e02c to
3840086
Compare
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
| } from '@aws-sdk/client-s3'; | ||
|
|
||
| const extendCommandWithExtraParametersMiddleware = (query: string) => | ||
| (next: any) => async (args: any) => { |
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 this be typed (avoid any)?
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.
Technically yes but the type here is very convoluted, requires importing stuff from aws sdk types that we don't really understand, I think it's ok this way
|
|
||
| export class ListObjectsExtendedCommand extends ListObjectsCommand { | ||
| constructor(input: ListObjectsExtendedInput) { | ||
| super(input); |
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.
Shoud we pass the whole input object? Is there no risk that AWS SDK "rejects" the query field?
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 its ok and tested, and I don't see what non complicated alternatives we would have
|
|
||
| export interface ListObjectsExtendedInput extends ListObjectsCommandInput { | ||
| Query: 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.
don't we also support an extra X-Scal-Request-Uids ?
or should we have another API to set it (since we probably don't want to override every command) ?
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'll rethink about this later when i do the follow up on backbeat where I will have to think about it.
But yeah I don't think it's the right place as we would need to override all commands, we will probably just use a middleware to add the request id if we want
| { step: 'build', name: 'extendCommandWithExtraParameters' } | ||
| ); | ||
| } | ||
| } |
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.
maybe an exercise for later, but I think we could factorize this, and use advanced typescript to "generate" the new class by adding a Query string param to the input of the constructor...
so we would end up with something like:
// Write the code just once here - may be a bit more complex though
func AddParameters(...) { }
export ListObjectsExtendedCommand = AddParameters(ListObjectsCommand, 'Query')
export ListObjectVersionsExtendedCommand = AddParameters(ListObjectVersionsCommand, 'Query')
(not required/blocking, and may not even work ; but I think this is possible and could help with maintenance..... though not sure at what cost)
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 just did a quick test with ai : it is possible to do something like this. If we had a lot of s3 command to exports it would probably be worth it, but here it just adding a lot of complexity (especially if we want to later handle multiple new parameters, + body vs query parameter) and doesn't seem worth it.
| import { describeForMetadataBackend } from './testHelpers'; | ||
|
|
||
| describe('CloudServer Lifecycle API Tests', () => { | ||
| describeForMetadataBackend('CloudServer Lifecycle API Tests', () => { |
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 maybe you can call skip from within the block, which may be friendly/readable: something like
descrube('Cloudsever Lifecycle API Tests', () => {
if (process.env.BACKEND_TYPE === BackendType.METADATA) {
skip(`${name} (tests skipped: mongo backend only)`);
}
it(..., () => {})
it(..., () => {})
}
(it works with mocha, not sure about jest)
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 just tried this also, it's not super nice compared with existing solution because we have to do it in a before all, so we end up with 2 before all which i wanna avoid. Also with this, all the tests end up running, but are stopped early, so in the logs we see all tests as "run and skipped", instead of just skipping the whole test file with the describe
|
/approve |
|
I have successfully merged the changeset of this pull request
Please check the status of the associated issue CLDSRVCLT-6. Goodbye sylvainsenechal. The following options are set: approve |
Issue: CLDSRVCLT-6