[JBoss JIRA] (TEIID-5951) Required Cloud Database list supported by Teiid Wildfly 11.1.2
by Geetika Kolli (Jira)
[ https://issues.redhat.com/browse/TEIID-5951?page=com.atlassian.jira.plugi... ]
Geetika Kolli updated TEIID-5951:
---------------------------------
Description:
Hi Team,
Could you please provide the list of Cloud Database supported by Teiid Wildfly 11.1.2 version.
Also, can you please share the documents/reference link to integrate those database.
Thanks,
Geetika
was:
Hi Team,
Could you please provide the list of Cloud Database supported by Teiid Wildfly 11.1.2 version.
Also, can you please share the documents/reference link to integrate those database.
Thanks,
Geetiika
> Required Cloud Database list supported by Teiid Wildfly 11.1.2
> --------------------------------------------------------------
>
> Key: TEIID-5951
> URL: https://issues.redhat.com/browse/TEIID-5951
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Geetika Kolli
> Assignee: Steven Hawkins
> Priority: Major
>
> Hi Team,
> Could you please provide the list of Cloud Database supported by Teiid Wildfly 11.1.2 version.
> Also, can you please share the documents/reference link to integrate those database.
> Thanks,
> Geetika
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (TEIID-5951) Required Cloud Database list supported by Teiid Wildfly
by Geetika Kolli (Jira)
Geetika Kolli created TEIID-5951:
------------------------------------
Summary: Required Cloud Database list supported by Teiid Wildfly
Key: TEIID-5951
URL: https://issues.redhat.com/browse/TEIID-5951
Project: Teiid
Issue Type: Feature Request
Reporter: Geetika Kolli
Assignee: Steven Hawkins
Hi Team,
Could you please provide the list of Cloud Database supported by Teiid Wildfly 11.1.2 version.
Also, can you please share the documents/reference link to integrate those database.
Thanks,
Geetiika
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (TEIIDSB-197) Add a module for each external source
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-197?page=com.atlassian.jira.plug... ]
Ramesh Reddy commented on TEIIDSB-197:
--------------------------------------
> I'm not sure why I'm having such a hard time getting through to you on some of this
I believe you are too focused on the process improvement over the functionality, I am weighted more on functionality right now. I saw deficiencies last time around and we fixed I think we are 90% there IMO except direct driver dependency. Right now I am viewing this as crud work that is not bringing much functionality thus reluctance to go jump all over it :)
I realized, there is no point in arguing this over and over and I could have finished the work half of the work during the time spent on this.
> Add a module for each external source
> -------------------------------------
>
> Key: TEIIDSB-197
> URL: https://issues.redhat.com/browse/TEIIDSB-197
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
>
> To simplify the logic in the operator each external source should be represented by a maven artifact - org.teiid:spring-data-x. Any dependency management would be handled in that module and not in the operator - to remove the need for a config file containing driver versions. Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (TEIIDSB-198) Align with 2.2.6 spring boot
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-198?page=com.atlassian.jira.plug... ]
Work on TEIIDSB-198 started by Steven Hawkins.
----------------------------------------------
> Align with 2.2.6 spring boot
> -----------------------------
>
> Key: TEIIDSB-198
> URL: https://issues.redhat.com/browse/TEIIDSB-198
> Project: Teiid Spring Boot
> Issue Type: Task
> Components: core
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 1.5.0
>
> Original Estimate: 4 hours
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> Due to the wildfly updates of TEIID-5859 that pull in a newer cxf and related dependencies, we end up with version conflicts. The best fix seems to be bumping Teiid Spring Boot to a later version. The only downside is that later version of spring boot have switched to jakarta javax dependencies, so we get a lot of duplicate / different class warnings. We can ignore the errors/warning, try to exclude incoming dependencies from Teiid, or switch Teiid to use jakarta instead...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (TEIIDSB-198) Align with 2.2.6 spring boot
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-198?focusedWorklogId=12450984&pa... ]
Steven Hawkins logged work on TEIIDSB-198:
------------------------------------------
Author: Steven Hawkins
Created on: 08/May/20 9:41 AM
Start Date: 08/May/20 9:41 AM
Worklog Time Spent: 6 hours
Work Description: Covering the work of updating teiid spring boot and realigning to jakarta
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 4 hours)
Time Spent: 6 hours
Worklog Id: (was: 12450984)
> Align with 2.2.6 spring boot
> -----------------------------
>
> Key: TEIIDSB-198
> URL: https://issues.redhat.com/browse/TEIIDSB-198
> Project: Teiid Spring Boot
> Issue Type: Task
> Components: core
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 1.5.0
>
> Original Estimate: 4 hours
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> Due to the wildfly updates of TEIID-5859 that pull in a newer cxf and related dependencies, we end up with version conflicts. The best fix seems to be bumping Teiid Spring Boot to a later version. The only downside is that later version of spring boot have switched to jakarta javax dependencies, so we get a lot of duplicate / different class warnings. We can ignore the errors/warning, try to exclude incoming dependencies from Teiid, or switch Teiid to use jakarta instead...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (TEIID-5859) Upgrade to wildfly 19
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5859?focusedWorklogId=12450983&pag... ]
Steven Hawkins logged work on TEIID-5859:
-----------------------------------------
Author: Steven Hawkins
Created on: 08/May/20 9:41 AM
Start Date: 08/May/20 9:40 AM
Worklog Time Spent: 4 hours
Work Description: Covering the initial to align with newer wildfly.
Issue Time Tracking
-------------------
Remaining Estimate: 4 hours (was: 1 day)
Time Spent: 4 hours
Worklog Id: (was: 12450983)
> Upgrade to wildfly 19
> ---------------------
>
> Key: TEIID-5859
> URL: https://issues.redhat.com/browse/TEIID-5859
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 14.0
>
> Original Estimate: 1 day
> Time Spent: 4 hours
> Remaining Estimate: 4 hours
>
> We should pick up the latest wildfly 18+
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (TEIIDSB-197) Add a module for each external source
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-197?page=com.atlassian.jira.plug... ]
Steven Hawkins commented on TEIIDSB-197:
----------------------------------------
> which I agree to needs improvement here, to remove driver versions from Operator
And that is exactly what I'm proposing to address here... I'm not sure why I'm having such a hard time getting through to you on some of this :(
> Another reason the driver versions designed this way was to override them if user wanted to use a different version.
That should be completely discounted as a possibility. You can override dependencies in the crd's themselves to do it on an ad hoc basis in your own custom operator would make it extremely difficult to know what versions of things were actual in use.
> I am reluctant to create 30 more projects with a single file to remove one config file
Let me rephase that - you currently believe you can do as good of a job of dependency management as maven in a single file. However I would counter that once you encounter sources that need more than a single dependency and/or you need better traceability - then it would be best to just rely on a standard system.
> I completely miss the point you are making with enviroment-post-processor, are saying no prefix needed at all? How am I passing the properties I configured for a data source to a SB process? even if it is, why add more complexity?
As far as the operator is concerned, yes there is no Teiid Spring Boot specific prefix needed, just a general convention - then let Teiid Spring Boot convert the properties to the actual property. So for example default everything to spring.teiid.data.alias.property and let Teiid Spring Boot determine if it needs to actually be spring.datasource, spring.datasource.xa, etc.
> Pretty soon, I also would like to add property names and then validate them when the CR is provided
I get that as a goal. But keep in mind it's not as straight forward as it seems. There's a lot of pooling related properties that could be included, all of the XADataSource properties (which aren't explicitly named by spring), or other similar more free form / source driven properties. The more you commit to assumptions, the more rigid and brittle things will become (for example are we prepared to fully commit to a particular pooling implementation, or do we need to come up with abstractions).
> Add a module for each external source
> -------------------------------------
>
> Key: TEIIDSB-197
> URL: https://issues.redhat.com/browse/TEIIDSB-197
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
>
> To simplify the logic in the operator each external source should be represented by a maven artifact - org.teiid:spring-data-x. Any dependency management would be handled in that module and not in the operator - to remove the need for a config file containing driver versions. Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months