[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   

Summary

Secure 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.

Details

The 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:

  • The supertenant needs to be secured.
  • A user named testing_admin needs to be added with okapi.all permissions.

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 SkoczenHanna 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:

  • mod-audit
  • mod-courses
  • mod-data-export
  • mod-codex-inventory
  • mod-feesfines
  • mod-oaipmh
  • mod-orders
  • mod-patron
  • mod-remote-storage
  • mod-rtac
  • mod-search
  • mod-inventory-update
  • mod-circulation 
  • mod-circulation-storage
  • mod-inventory
  • mod-inventory-storage

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 LadischHanna Hulevich, Jakub Skoczen, Adam Dickmeiss, Mikhail Fokanov, Ian Hardy

Some notes on our progress on this:

  1. The scratch env has been rebuilt using the Jenkins pipeline for that: https://jenkins-aws.indexdata.com/job/scratch_environment/job/manage-scratch-environment/
  2. We believe this rebuild has given us the current state of master on every module as well as the UI modules.
  3. This build was not completely clean however. Ian was able to work through those issues and get all of the modules going on diku however. (We should probably do a postmortem to try to document what was was needed beyond what Jenkins does to try to make this easier in the future.)
  4. We were able to deploy the OL branches for mod-inventory and mod-inventory-storage.
  5. Securing the supertenant and adding the testing user worked as expected after the rebuild, resolving yesterday's issue.
  6. However we were not able to complete a successful functional test of OL and don't currently see the 409 response. We think this is because okapi has not been made aware of the new module descriptors that are present in the OL branches for mod-inventory and mod-inventory-storage. Attempting to register these modules currently fails.

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.:
To enable optimistic locking it is not sufficient to drop in the new module. We also need to POST /_/tenant to run the upgrade process that installs the new database triggers that do the actual optimistic locking check.

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.

Generated at Thu Feb 08 23:26:58 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.