-
Notifications
You must be signed in to change notification settings - Fork 111
fix: Adapt the Secrets plugin API to use kubernetes secrets #1166
Conversation
Signed-off-by: Igor Vinokur <ivinokur@redhat.com>
Depends on eclipse-che/che-server#44 |
Codecov Report
@@ Coverage Diff @@
## main #1166 +/- ##
==========================================
- Coverage 32.78% 32.52% -0.26%
==========================================
Files 290 295 +5
Lines 9885 9994 +109
Branches 1457 1474 +17
==========================================
+ Hits 3241 3251 +10
- Misses 6641 6740 +99
Partials 3 3
Continue to review full report at Codecov.
|
[crw-ci-test --rebuild] |
✅ E2E Happy path tests succeed 🎉 See Details
Test product:
Eclipse Che QE channel: https://mattermost.eclipse.org/eclipse/channels/eclipse-che-qe |
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 👍
import { CheServerWorkspaceServiceImpl } from '@eclipse-che/theia-remote-impl-che-server/lib/node/che-server-workspace-service-impl'; | ||
|
||
@injectable() | ||
export class CheCredentialsServer implements CredentialsServer { |
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 this classe, we should rely on the mounted files for reading secrets.
About delete and create it should be possible to do it using K8S API
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.
About delete and create it should be possible to do it using K8S API
Could you please elaborate more on 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.
If I understand correctly, with this PR, we don't need keytar
-based code anymore, e,g, KeytarServiceImpl or KeytarCredentialsProvider.
Can we unbind the unused keytar-related components in Che-Theia to avoid including libsecret
into the image?
As recently, we've fixed starting Che-Theia backend by including libsecret
in 07aeab7
extensions/eclipse-che-theia-credentials/src/browser/che-credentials-service.ts
Outdated
Show resolved
Hide resolved
extensions/eclipse-che-theia-credentials/src/browser/credentials-frontend-module.ts
Outdated
Show resolved
Hide resolved
extensions/eclipse-che-theia-credentials/src/node/che-theia-credentials-backend-module.ts
Outdated
Show resolved
Hide resolved
Signed-off-by: Igor Vinokur <ivinokur@redhat.com>
When I unbind the KeytarServiceImpl and KeytarCredentialsProvider classes the che-theia build fails with an error:
Probably we can fix it as a next iteration. |
✅ E2E Happy path tests succeed 🎉 See Details
Test product:
Eclipse Che QE channel: https://mattermost.eclipse.org/eclipse/channels/eclipse-che-qe |
@azatsarynnyy @benoitf Since the server-side part is merged I am going to merge this tomorrow if no more objections. |
Thanks @vinokurig ! The PR looks good to me 👍 But I'm worried about removing the
It's a good idea. It would be great to create an issue for that and at least investigate it during one of the next sprints. |
Signed-off-by: Igor Vinokur ivinokur@redhat.com
What does this PR do?
Rework the Secrets API from upstream theia to use kubernetes secrets
Screenshot/screencast of this PR
What issues does this PR fix or reference?
fixes eclipse-che/che#19837
How to test this PR?
P.S. This will work only for newly created namespace, see eclipse-che/che-server#44 (review)
PR Checklist
As the author of this Pull Request I made sure that:
What issues does this PR fix or reference
andHow to test this PR
completedReviewers
Reviewers, please comment how you tested the PR when approving it.
Happy Path Channel
HAPPY_PATH_CHANNEL=stable