[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret
by Ramesh Reddy (Jira)
[ 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)
4 years, 10 months
[JBoss JIRA] (TEIID-5916) Add indexes in generated protobuf
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIID-5916?page=com.atlassian.jira.plugi... ]
Ramesh Reddy updated TEIID-5916:
--------------------------------
Story Points: 1
> Add indexes in generated protobuf
> ---------------------------------
>
> Key: TEIID-5916
> URL: https://issues.redhat.com/browse/TEIID-5916
> Project: Teiid
> Issue Type: Enhancement
> Components: Infinispan
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 14.0
>
>
> The protobuf logic will mark an entire table as indexed, but that may not line up to what we need.
> The usage of the Indexed annotation on the message indicates that custom IndexedField annotations will be used to selective enable indexes.
> This is true whether the cache is marked as indexed (which would be specified in the cache template) or not.
> If we auto-create an indexed cache, then all fields are automatically indexed and there's no need for the indexed annotation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIIDSB-170) Automate materialization to JDG
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIIDSB-170:
---------------------------------
Sprint: DV Sprint 60, DV Sprint 61, DV Sprint 62, DV Sprint 63 (was: DV Sprint 60, DV Sprint 61, DV Sprint 62)
> Automate materialization to JDG
> -------------------------------
>
> Key: TEIIDSB-170
> URL: https://issues.redhat.com/browse/TEIIDSB-170
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Components: OpenShift
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 1.5.0
>
> Original Estimate: 1 week
> Time Spent: 4 days, 3 hours
> Remaining Estimate: 5 hours
>
> Create an internal materialization replacement needs that is turnkey materialization to JDG (little to no user setup required)
> - the operator may create the infinispan cluster if needed
> - the status table and internal representation of the materialization target would be setup automatically
> For the user this would be as simple marking a view as materialized and then it would be populated in jdg upon deployment. They would not have any concerns with cache naming, status tables, etc.
> For simplicity the initial version would make a similar assumption to the current internal logic - it is for only a specific vdb. If the vdb cr is modified, then it's expected that the cache would be recreated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-5916) Add indexes in generated protobuf
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIID-5916?page=com.atlassian.jira.plugi... ]
Ramesh Reddy updated TEIID-5916:
--------------------------------
Sprint: DV Sprint 60, DV Sprint 63 (was: DV Sprint 60)
> Add indexes in generated protobuf
> ---------------------------------
>
> Key: TEIID-5916
> URL: https://issues.redhat.com/browse/TEIID-5916
> Project: Teiid
> Issue Type: Enhancement
> Components: Infinispan
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 14.0
>
>
> The protobuf logic will mark an entire table as indexed, but that may not line up to what we need.
> The usage of the Indexed annotation on the message indicates that custom IndexedField annotations will be used to selective enable indexes.
> This is true whether the cache is marked as indexed (which would be specified in the cache template) or not.
> If we auto-create an indexed cache, then all fields are automatically indexed and there's no need for the indexed annotation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months