RHPAM-2762 & RHPAM-2777 add tests to verify issues fixes#629
RHPAM-2762 & RHPAM-2777 add tests to verify issues fixes#629jakubschwan wants to merge 3 commits intokiegroup:7.33.xfrom
Conversation
| } | ||
|
|
||
| // Verifies https://issues.redhat.com/browse/RHPAM-2762 | ||
| public void testAdminUserPasswordChange(WorkbenchDeployment workbenchDeployment) { |
There was a problem hiding this comment.
I think we should also check that the Kie Server can connect after the username or password have changed.
For templates, the Kie Server uses the secrets to get the credentials to connect with Workbench. If we change the username or password, the Kie Server might still have the old credentials and something very wrong could be happening.
I guess this is not an issue in Operator as it's using the common config, but checking the Kie Server was restarted with the correct data seems still to be needed.
What do you think?
There was a problem hiding this comment.
I don't think that this is needed. If credential secret is changed, then all deployments using this secret needs to be redeploy manually to have up to date credentials. This redeploy is not triggered automatically as change of env variables for deployment config. If the deployments are not redeploy they are still using previous credentials.
On the other hand this adjustments and extension of tests shouldn't effect running time (if we do redeploy at the same time) and can bring extra checks.
There was a problem hiding this comment.
Do you mean that if we allow users to change the credentials, it might cause a misconfiguration of other components? I don't think we should allow that, right?
From my point of view, the restart must occur if we change the credentials either in env vars (operator) or config map (templates).
There was a problem hiding this comment.
There two types of change for templates - change of data in credential secret (no redeployments) and change of the credential secret (replace) in deployment config (this will trigger redeploy).
Templates will deploy application and we cannot manage all components at once, so if user change the credential, they needs to do it for all components of the application.
In Operator we are using kieApp that is update on change, this is additional value of Operator.
There was a problem hiding this comment.
I'm only thinking in what would happen if users change the credentials using the supported approaches (not directly Openshift or CLI as we do in tests).
So, in templates, what would happen if real users change the credentials via Business Central? If no redeployments occur, it will deal in a misconfiguration and I guess we can watch this kind of changes to make redeployments happen automatically.
What about SSO or LDAP? Here we can't watch the changes, so maybe it should document what to do next?
| } | ||
|
|
||
| // Verifies https://issues.redhat.com/browse/RHPAM-2777 | ||
| public void testAdminUserNameAndPasswordChange(WorkbenchDeployment workbenchDeployment) { |
jakubschwan
force-pushed
the
7.33.x-bc-admin-persistence
branch
2 times, most recently
from
f07ea85 to
1ab252d
Compare
| SoftAssertions.assertSoftly(softly -> { | ||
| softly.assertAlso(isUserAuthorizedInWorkbench(workbenchUrl, oldUsername, oldPassword)); | ||
| softly.assertAlso(isUserAuthorizedInKieServer(kieServerUrl, oldUsername, oldPassword)); | ||
| }); |
There was a problem hiding this comment.
I don't think we need to assert old users can connect as if not, it would have failed before (to kie server when connecting to business central or when deploying the container).
| SoftAssertions.assertSoftly(softly -> { | ||
| softly.assertAlso(isUserAuthorizedInWorkbench(workbenchUrl, username, oldPassword)); | ||
| softly.assertAlso(isUserAuthorizedInKieServer(kieServerUrl, username, oldPassword)); | ||
| }); |
There was a problem hiding this comment.
I don't think we need to assert old users can connect as if not, it would have failed before (to kie server when connecting to business central or when deploying the container).
jakubschwan
force-pushed
the
7.33.x-bc-admin-persistence
branch
7 times, most recently
from
73305b5 to
79b2deb
Compare
…der and change user impl will be removed in following commit
jakubschwan
force-pushed
the
7.33.x-bc-admin-persistence
branch
2 times, most recently
from
b5e4ade to
f1725ea
Compare
jakubschwan
force-pushed
the
7.33.x-bc-admin-persistence
branch
from
f1725ea to
1d0f3db
Compare
3 participants
No description provided.