[JBoss JIRA] (TEIIDSB-144) Calling setTransactionIsolation on pg driver causes the connection to be closed
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-144?page=com.atlassian.jira.plug... ]
Steven Hawkins updated TEIIDSB-144:
-----------------------------------
Fix Version/s: 1.4.0
> Calling setTransactionIsolation on pg driver causes the connection to be closed
> -------------------------------------------------------------------------------
>
> Key: TEIIDSB-144
> URL: https://issues.redhat.com/browse/TEIIDSB-144
> Project: Teiid Spring Boot
> Issue Type: Bug
> Components: datasource
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 1.4.0, 1.3.1
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining Estimate: 2 hours
>
> An attempt to set the isolation level on pg 42.2.8 resulted in an exception SQLSTATE 0a000 - unsupported - which causes the connection pool to mark the connection as broken:
> {code}
> 2019-11-25 23:07:50.125 WARN 43993 --- [ProcessorQueue6] com.zaxxer.hikari.pool.ProxyConnection : HikariPool-1 - Connection org.postgresql.jdbc.PgConnection@2ffebc7e marked as broken because of SQLSTATE(0A000), ErrorCode(0)
> org.postgresql.util.PSQLException:
> at org.postgresql.jdbc.PgConnection.setTransactionIsolation(PgConnection.java:851) ~[postgresql-42.2.8.jar:42.2.8]
> at com.zaxxer.hikari.pool.ProxyConnection.setTransactionIsolation(ProxyConnection.java:407) ~[HikariCP-3.2.0.jar:na]
> at com.zaxxer.hikari.pool.HikariProxyConnection.setTransactionIsolation(HikariProxyConnection.java) ~[HikariCP-3.2.0.jar:na]
> at org.teiid.translator.jdbc.JDBCBaseExecution.<init>(JDBCBaseExecution.java:72) ~[translator-jdbc-12.3.0.jar:12.3.0]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ]
Steven Hawkins commented on TEIIDSB-157:
----------------------------------------
We might have some cross talk across issues. The issue is that infinispan creates a secret with a single key that's a yaml file: https://raw.githubusercontent.com/infinispan/infinispan-operator/master/d...
There is no simple mechanism in openshift to extract a username / password pair from that structure that I can find and then set it as an env variable.
After starting down the path of providing my own secret to infinispan (the link from the last comment), I see that the generated secret is used instead. So I need their community to weigh in on that.
> Support loading password credential from infinispan secret
> ----------------------------------------------------------
>
> Key: TEIIDSB-157
> URL: https://issues.redhat.com/browse/TEIIDSB-157
> Project: Teiid Spring Boot
> Issue Type: Sub-task
> Components: datasource
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.4.0, 1.3.1
>
>
> 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, 11 months
[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:
--------------------------------------
Why not configure as ENV properties in the DV VDB, referencing back to the secret it created? Which override the properties InfinispanConfiguration?
> Support loading password credential from infinispan secret
> ----------------------------------------------------------
>
> Key: TEIIDSB-157
> URL: https://issues.redhat.com/browse/TEIIDSB-157
> Project: Teiid Spring Boot
> Issue Type: Sub-task
> Components: datasource
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.4.0, 1.3.1
>
>
> 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, 11 months
[JBoss JIRA] (TEIID-5798) Mixed PERMISSION GRANTS
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5798?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIID-5798:
---------------------------------------
The pg behavior is that policy names are scoped to the table on which they are created - similar to our handling of constraint names. I don't have a problem if we do that as well, but it will require some additional tracking to determine uniqueness. We also allow conditions on procedure result sets, so we can't just say in all cases:
create policy p on tbl ...
it will need to instead be:
create policy p on TABLE tbl ...
the drop syntax will similarly be affected. We can default to a TABLE reference if not specified - so that we can typically be aligned with pg.
> Mixed PERMISSION GRANTS
> -----------------------
>
> Key: TEIID-5798
> URL: https://issues.redhat.com/browse/TEIID-5798
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Original Estimate: 6 hours
> Time Spent: 4 hours
> Remaining Estimate: 1 day, 6 hours
>
> Hello,
> I am currently trying to set a set of permissions on a table/view. Hence a condition on INSERT,UPDATE,DELETE and an unconditioned SELECT.
> However, it seems that conditioned and unconditioned GRANT statements do not work together.
> {code}
> GRANT INSERT,UPDATE,DELETE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" CONDITION 'UserDefinedProducts_SRC.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36) )' TO odata;
> GRANT SELECT ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" TO odata;
> REVOKE ALTER,EXECUTE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" FROM odata;
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ]
Steven Hawkins commented on TEIIDSB-157:
----------------------------------------
Option 1 does not seem to work with the current infinispan operator. Following https://infinispan.org/infinispan-operator/master/documentation/asciidoc/... the cluster still generates a secret and uses that instead. I've opened another topic in the infinispan community for that. If that is blocked, we'll have to go with #2.
> Support loading password credential from infinispan secret
> ----------------------------------------------------------
>
> Key: TEIIDSB-157
> URL: https://issues.redhat.com/browse/TEIIDSB-157
> Project: Teiid Spring Boot
> Issue Type: Sub-task
> Components: datasource
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.4.0, 1.3.1
>
>
> 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, 11 months
[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ]
Steven Hawkins updated TEIIDSB-157:
-----------------------------------
Description:
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.
was:
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.
It seems like we'll in
> Support loading password credential from infinispan secret
> ----------------------------------------------------------
>
> Key: TEIIDSB-157
> URL: https://issues.redhat.com/browse/TEIIDSB-157
> Project: Teiid Spring Boot
> Issue Type: Sub-task
> Components: datasource
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.4.0, 1.3.1
>
>
> 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, 11 months
[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret
by Steven Hawkins (Jira)
Steven Hawkins created TEIIDSB-157:
--------------------------------------
Summary: Support loading password credential from infinispan secret
Key: TEIIDSB-157
URL: https://issues.redhat.com/browse/TEIIDSB-157
Project: Teiid Spring Boot
Issue Type: Sub-task
Components: datasource
Reporter: Steven Hawkins
Fix For: 1.4.0, 1.3.1
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.
It seems like we'll in
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIID-5878) Support loading the protobuf file from the classpath
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5878:
-------------------------------------
Summary: Support loading the protobuf file from the classpath
Key: TEIID-5878
URL: https://issues.redhat.com/browse/TEIID-5878
Project: Teiid
Issue Type: Feature Request
Components: Misc. Connectors
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 13.0.2
Providing a protobuf file should support loading from the classpath as well - currently it expects just a file system path.
This will allow for inclusion of protobuf files in Teiid Spring Boot fat jars.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months