[FOLIO-3282] secure supertenant for core-platform scratch env Created: 07/Sep/21 Updated: 10/Sep/21 Resolved: 10/Sep/21 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Story | Priority: | P2 |
| Reporter: | Jakub Skoczen | Assignee: | Ian Hardy |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Sprint: | DevOps Sprint 122 |
| Development Team: | FOLIO DevOps |
| Description |
SummarySecure supertenant and add testing_admin user with password of "admin" to CP team scratch env. This has a high priority for the CP team since it is needed for optimistic locking testing. DetailsThe Core Platform team's scratch environment is where it can test new features prior to release. Currently we have a need to run the karate tests in the context of this scratch environment. This scratch environment has been deployed, and modules have been installed, however it is known to be missing two important configurations which will enable karate testing. These configurations are as follows:
There may be other configurations required, but as of now these are the known configurations we need. Environments where the karate tests are known to work are the testing and snapshot reference environments. Background
|
| Comments |
| Comment by Ian Hardy [ 07/Sep/21 ] |
|
Took a look at this today. A few notes.
Okapi returns: 2021-09-07T19:23:32,530 WARN ProxyContext Unexpected Location header in response for POST /_/tenant io.vertx.core.impl.NoStackTraceThrowable: Unexpected Location header in response for POST /_/tenant |9/7/2021 3:23:32 PM 2021-09-07T19:23:32,532 INFO ProxyContext 456596/proxy RES 500 262962us okapi Unexpected Location header in response for POST /_/tenant when trying to enable modules. Appears to be related to https://folio-org.atlassian.net/browse/OKAPI-875, but I'm not 100% what's going on here.
Also noticed that the core platform scratch environment is running some older modules Steve Ellis Jakub Skoczen do you want to try to refresh it first, or are these the modules you want to run for the testing? If you want to refresh, I'd suggest we do that before we have another crack at securing it. |
| Comment by Steve Ellis [ 07/Sep/21 ] |
|
Thanks Ian Hardy for your work on this. Apologies for the scope drifting a bit. Let me try to summarize our discussion on slack for other interested parties like Jakub Skoczen, Hanna Hulevich and Adam Dickmeiss. Our best guess right now is that the error could be due to core modules like mod-users, mod-login, mod-permissions, and mod-authtoken in the cluster being out of date, compared to the newer modules we are deploying as part of the optimistic locking testing. For example the okapi on the cluster is 4.7.0, which is about 6 or 7 months old. The theory is that if we deploy more up-to-date modules things will start working. Care should be taken to not change the builds for the optimistic locking-affected modules. The modules that should be left alone are as follows:
These modules have been deployed with great care that Hanna has facilitated through her EPAM collaborator. Any other module can be updated to try to get things working. |
| Comment by Julian Ladisch [ 08/Sep/21 ] |
|
On today's core platform meeting we decided that https://core-platform.ci.folio.org should get a fresh installation as suggested by Ian. It should be similar to https://folio-testing.dev.folio.org/ that has the latest master branches we need for testing OL. |
| Comment by Steve Ellis [ 08/Sep/21 ] |
|
Julian Ladisch, Hanna Hulevich, Jakub Skoczen, Adam Dickmeiss, Mikhail Fokanov, Ian Hardy Some notes on our progress on this:
This means that the current scratch env is not viable for OL functional testing by the POs, which is not great, but at least we are closer to having a more complete and up-to-date testing environment.
|
| Comment by Jakub Skoczen [ 09/Sep/21 ] |
|
Ian Hardy Steve Ellis Guys, what are the next steps here? |
| Comment by Julian Ladisch [ 09/Sep/21 ] |
|
Regarding step 6.: I've run curl -w"\n" -s -S -D - -H "Content-type: application/json" -H "x-okapi-url-to: https://core-platform-okapi.ci.folio.org/" -H "x-okapi-tenant: diku" -XPOST -d "{\"module_from\": \"21.0.0\", \"module_to\": \"22.0.0\" }" http://localhost:8081/_/tenant on the docker.dev.folio.org/mod-inventory-storage:MODINVSTOR-713-optimistic-locking-failOnConflict container, now https://core-platform.ci.folio.org/ has optimistic locking with 409 error messages enabled. |
| Comment by Steve Ellis [ 10/Sep/21 ] |
|
Jakub Skoczen and Hanna Hulevich this ticket can be closed. Installing the latest of all the modules resolved the issue with securing the supertenant. An additional benefit is that all the modules are now up-to-date, which I think gives us a better testing env. I'm now seeing the karate tests run successfully against the scratch endpoint. Thank you Julian Ladisch for the curl that made okapi aware of the special builds for mod-inventory and mod-inventory-storage. And thank you Ian Hardy for all your great work on this. |
| Comment by Ian Hardy [ 10/Sep/21 ] |
|
Steve can deploy new modules and secure/unsecure the supertenant as needed going forward. Closing this one now. |