January 2020 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5877) OverlappingFileLockException with excel translator

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5877?page=com.atlassian.jira.plugi... ] Work on TEIID-5877 started by Steven Hawkins. --------------------------------------------- > OverlappingFileLockException with excel translator > -------------------------------------------------- > > Key: TEIID-5877 > URL: https://issues.redhat.com/browse/TEIID-5877 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 13.1, 13.0.2 > > > Concurrent access with file locking produces an exception rather than exclusion. This needs to be more gracefully handled. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5883) Move older infinispan dependency to wildfly

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5883?page=com.atlassian.jira.plugi... ] Steven Hawkins updated TEIID-5883: ---------------------------------- Component/s: Build/Kits > Move older infinispan dependency to wildfly > ------------------------------------------- > > Key: TEIID-5883 > URL: https://issues.redhat.com/browse/TEIID-5883 > Project: Teiid > Issue Type: Bug > Components: Build/Kits > Affects Versions: 13.x > Reporter: Van Halbert > Assignee: Steven Hawkins > Priority: Blocker > > The wildfly version of ispn is marked as having a cve. That dependency version should be isolated to wildfly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[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: -------------------------------------- sorry, I did not see the link contents and assumed that there was a different way to get to the credentials. > 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 > > 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, 11 months

1
0
0 / 0

[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: ---------------------------------------- I'm confused. What are you thinking is the new way? > 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 > > 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, 11 months

1
0
0 / 0

[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: -------------------------------------- Looks like Infinispan folks suggested a new way https://infinispan.org/infinispan-operator/master/operator.html#managing_... is the section you're looking for, I believe should we close this as "out of date"? > 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 > > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-162) Operator does not account for the transaction manager

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-162?page=com.atlassian.jira.plug... ] Ramesh Reddy edited comment on TEIIDSB-162 at 1/22/20 7:57 PM: --------------------------------------------------------------- Added the code in the master and as well in 7.6.0.1.x branches. Please note the image in quay.io with 0.1.0 tag does not have this update, 0.2.0 does, and master is moved 0.2.0 to start new community iteration. Wanted to move this JIRA to TEIIDTOOLS but this is sub-task the JIRA system did not allow me to do that was (Author: rareddy): Added the code in the master and as well in 7.6.0.1.x branches. Please note the image in quay.io with 0.1.0 tag does not have this update, 0.2.0 does, and master is moved 0.2.0 to start new community iteration. > Operator does not account for the transaction manager > ----------------------------------------------------- > > Key: TEIIDSB-162 > URL: https://issues.redhat.com/browse/TEIIDSB-162 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: OpenShift > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.4.0, 1.3.1 > > > If you define a vdb in a cr, the generated vdb will just use the platformtransactionmanager. > Since the materialization procedures use transaction blocks, we need a full transaction manager. By default with the platformtransactionmanager it will throw an exception - only spring managed transactions ... > The workaround would be to add snowdrop to the cr dependencies, but it would be nice to either always use that in the generated, or detect materialization is being used, or address TEIIDSB-109 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-162) Operator does not account for the transaction manager

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-162?page=com.atlassian.jira.plug... ] Ramesh Reddy resolved TEIIDSB-162. ---------------------------------- Fix Version/s: 1.3.1 Resolution: Done > Operator does not account for the transaction manager > ----------------------------------------------------- > > Key: TEIIDSB-162 > URL: https://issues.redhat.com/browse/TEIIDSB-162 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: OpenShift > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.4.0, 1.3.1 > > > If you define a vdb in a cr, the generated vdb will just use the platformtransactionmanager. > Since the materialization procedures use transaction blocks, we need a full transaction manager. By default with the platformtransactionmanager it will throw an exception - only spring managed transactions ... > The workaround would be to add snowdrop to the cr dependencies, but it would be nice to either always use that in the generated, or detect materialization is being used, or address TEIIDSB-109 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-162) Operator does not account for the transaction manager

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-162?focusedWorklogId=12449938&pa... ] Ramesh Reddy logged work on TEIIDSB-162: ---------------------------------------- Author: Ramesh Reddy Created on: 22/Jan/20 7:58 PM Start Date: 22/Jan/20 7:58 PM Worklog Time Spent: 3 hours Issue Time Tracking ------------------- Remaining Estimate: 0 minutes Time Spent: 3 hours Worklog Id: (was: 12449938) > Operator does not account for the transaction manager > ----------------------------------------------------- > > Key: TEIIDSB-162 > URL: https://issues.redhat.com/browse/TEIIDSB-162 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: OpenShift > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.4.0, 1.3.1 > > Time Spent: 3 hours > Remaining Estimate: 0 minutes > > If you define a vdb in a cr, the generated vdb will just use the platformtransactionmanager. > Since the materialization procedures use transaction blocks, we need a full transaction manager. By default with the platformtransactionmanager it will throw an exception - only spring managed transactions ... > The workaround would be to add snowdrop to the cr dependencies, but it would be nice to either always use that in the generated, or detect materialization is being used, or address TEIIDSB-109 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-162) Operator does not account for the transaction manager

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-162?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIIDSB-162: -------------------------------------- Added the code in the master and as well in 7.6.0.1.x branches. Please note the image in quay.io with 0.1.0 tag does not have this update, 0.2.0 does, and master is moved 0.2.0 to start new community iteration. > Operator does not account for the transaction manager > ----------------------------------------------------- > > Key: TEIIDSB-162 > URL: https://issues.redhat.com/browse/TEIIDSB-162 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: OpenShift > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.4.0 > > > If you define a vdb in a cr, the generated vdb will just use the platformtransactionmanager. > Since the materialization procedures use transaction blocks, we need a full transaction manager. By default with the platformtransactionmanager it will throw an exception - only spring managed transactions ... > The workaround would be to add snowdrop to the cr dependencies, but it would be nice to either always use that in the generated, or detect materialization is being used, or address TEIIDSB-109 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-162) Operator does not account for the transaction manager

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-162?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIIDSB-162: --------------------------------- Summary: Operator does not account for the transaction manager (was: vdb codegen does not account for the transaction manager) > Operator does not account for the transaction manager > ----------------------------------------------------- > > Key: TEIIDSB-162 > URL: https://issues.redhat.com/browse/TEIIDSB-162 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: OpenShift > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.4.0 > > > If you define a vdb in a cr, the generated vdb will just use the platformtransactionmanager. > Since the materialization procedures use transaction blocks, we need a full transaction manager. By default with the platformtransactionmanager it will throw an exception - only spring managed transactions ... > The workaround would be to add snowdrop to the cr dependencies, but it would be nice to either always use that in the generated, or detect materialization is being used, or address TEIIDSB-109 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2020