CLDSRV-1015: Drop runtime dependency on @scality/cloudserverclient - #6314
Conversation
The backbeat routes only needed the exception names of cloudserverclient to report CRR conflicts, yet the package was a runtime dependency and got shipped in the production image. It is huge and vendors its own node_modules (including a vulnerable fast-xml-parser), which lockfile scanners and yarn resolutions cannot see or fix. The error names are now defined in constants, and the client is back to being a devDependency for functional tests. A unit test checks the names still match the client's exceptions. Issue: CLDSRV-1015
Hello francoisferrand,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
|
note: the size of the CloudserverClient package comes because it bundles its own node_modules inside the published package; which is being addressed in CLDSRVCLT-19 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
@@ Coverage Diff @@
## development/9.4 #6314 +/- ##
================================================
Coverage 86.49% 86.49%
================================================
Files 212 212
Lines 14567 14567
================================================
Hits 12599 12599
Misses 1968 1968
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command: Alternatively, the |
|
Should we not fix the CVE (upgrade the package or change the dependency in cloudserverclient) ? This PR seems like a hack to hide something... |
I think he will make a pr in cloudserverclient to fix the node module bug thing |
SylvainSenechal
left a comment
There was a problem hiding this comment.
A bit unfortunate we can't use the cloudserverclient errors without important 200mb of node modules
not only that, depending on cloudserverclient also creates a kind of a dependency loop cloudserverc depends on cloudserverclient, which kind of depends on cloudserver (for testing, etc...). it is not a real dependency loop (in package.json), but still weird - and means it is not possible to one PR (server) before updating the client. --> decoupling works better in such case, and the risk of copying is managed by a test |
|
/approve |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option The following options are set: approve |
Build failedThe build for commit did not succeed in branch w/9.5/bugfix/CLDSRV-1015 The following options are set: approve |
In the queueThe changeset has received all authorizations and has been added to the The changeset will be merged in:
The following branches will NOT be impacted:
This pull request does not target the following hotfix branch(es) so they
There is no action required on your side. You will be notified here once IMPORTANT Please do not attempt to modify this pull request.
If you need this pull request to be removed from the queue, please contact a The following options are set: approve |
|
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue CLDSRV-1015. Goodbye francoisferrand. |
The backbeat routes only used cloudserverclient to get the names of three exceptions for CRR conflict responses, but that made the whole package a runtime dependency shipped in the production image. It's ~235 MB and vendors its own
node_modules(including an old fast-xml-parser with a critical CVE), which lockfile scanners don't see and yarn resolutions can't fix.The error names now live in
constants.js, and the client goes back todevDependenciessince functional tests still use it. A unit test checks the local names match the client's exception names, so a rename on the client side gets caught.Checked that a
yarn install --production --frozen-lockfileno longer pulls the package and that the server still starts withS3BACKEND=mem. The Dockerfile already installs with--production.yarn.lockis unchanged, since yarn classic doesn't track dev vs prod.Issue: CLDSRV-1015