[
https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug...
]
Ramesh Reddy commented on TEIIDSB-157:
--------------------------------------
[~shawkins] Here I am taking the 4th approach. Just ignore the secret file that is created
for the Infinispan cluster, and depend upon a separate secret configuration of the
Infinisan cluster access for Teiid. IMO, the reason others will not work is, if the
Infinispan cluster is configured in a different namespace than the Teiid, then access to
secret requires different permission to access the secret from other namespaces. Which
creates unnecessary confusion.
As mentioned on TEIIDSB-170, right now the Teiid Operator either looks for
"{vdb-name}-cache-store" or "teiid-cache-store" and reads the config
from there. As per using this as a regular data source, the YAML already provides hooks to
read from any secret.
Support loading password credential from infinispan secret
----------------------------------------------------------
Key: TEIIDSB-157
URL:
https://issues.redhat.com/browse/TEIIDSB-157
Project: Teiid Spring Boot
Issue Type: Enhancement
Components: datasource
Reporter: Steven Hawkins
Priority: Major
Fix For: 1.5.0
Original Estimate: 5 hours
Time Spent: 2 hours
Remaining Estimate: 3 hours
The infinispan operator generates a secret that contains a yaml file, which is where the
developer password is stored.
There three approaches:
1. for materialization assume that we will "own" the DataGrid instance such
that we'll create and pass our own secret file for infinispan to use. In this case
we'll know the password and can provide that to the connection factory via an env
property.
2. add logic to the connection factory to specify a "credential file" such that
we'll parse the yaml from the given location (a mount of the secret) and find the
appropriate credential for the given username (typically developer).
3. ask the infinispan team to allow for easier consumption of the secret (a secret per
user?)
To get things working with the example, I can take the first approach - but it will look
a little convoluted.
In general 2 or 3 will be needed in scenarios where we expect to simply pick up existing
credentials.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)